💬 maflcko commented on issue "intermittent timeout in wallet_signer.py : 'createwallet' RPC took longer than 1200.000000 seconds":
(https://github.com/bitcoin/bitcoin/issues/32855#issuecomment-3032857821)
You can just follow the links to "Open full logs" to get to https://api.cirrus-ci.com/v1/task/5704849158832128/logs/ci.log, but I don't think there are any details in the log that give more hints, on a quick skim.

💬 glozow commented on pull request "test: fix an incorrect `feature_fee_estimation.py` subtest":
(https://github.com/bitcoin/bitcoin/pull/32463#discussion_r2183220585)
I'm suggesting linking both, or explaining it directly. Currently it requires clicking on the issue comment, then on the commit linked in that comment, then the PR linked in that commit to understand where the 4000 comes from

🚀 fanquake merged a pull request: "[28.x] Backports"
(https://github.com/bitcoin/bitcoin/pull/32811)

💬 sr-gi commented on pull request "Fix tiebreak when loading blocks from disk (and add tests for comparing chain ties)":
(https://github.com/bitcoin/bitcoin/pull/29640#discussion_r2183229775)
IIRC, the rationale here was that `nSequenceId` is supposed to be monotonically increasing, so having a chain of blocks where the previous blocks all have nSequenceId = `x-1` and the tip has `x` was weird. Since this is something that should only happen on restarts, the extra fraction of a second was not that relevant.

I'm happy to change it so only the tip has 0 if you think the time savings are more relevant than the inconsistency with the design. Comments will also need to be updated.

💬 fanquake commented on pull request "test: Fix list index out of range error in feature_bip68_sequence.py":
(https://github.com/bitcoin/bitcoin/pull/32765#issuecomment-3032896037)
Backported to 28.x in #32811.

💬 fanquake commented on pull request "doc: taproot became always active in v24.0 (doc/bips.md)":
(https://github.com/bitcoin/bitcoin/pull/32776#issuecomment-3032896451)
Backported to 28.x in #32811.

💬 fanquake commented on pull request "doc: fix Transifex 404s":
(https://github.com/bitcoin/bitcoin/pull/32777#issuecomment-3032896761)
Backported to 28.x in #32811.

💬 fanquake commented on pull request "doc: Add workaround for vcpkg issue with paths with embedded spaces":
(https://github.com/bitcoin/bitcoin/pull/32858#issuecomment-3032900614)
Backported to 29.x in #32863.

💬 fanquake commented on pull request "build: Make config warnings fatal if -DWCONFIGURE_ERROR=ON":
(https://github.com/bitcoin/bitcoin/pull/31665#issuecomment-3032903677)
@davidgumberg FYI I've implemented something using `AUTHOR_WARNING`, as discussed above, in #32865.

💬 fanquake commented on pull request "doc: clarify that the "-j N" goes after the "--build build" part":
(https://github.com/bitcoin/bitcoin/pull/32846#issuecomment-3032913817)
Backported to 29.x in #32863.

💬 ismaelsadeeq commented on pull request "test: fix an incorrect `feature_fee_estimation.py` subtest":
(https://github.com/bitcoin/bitcoin/pull/32463#discussion_r2183250651)
Yeah, I think that will be clearer. I will fix when retouching.

💬 sr-gi commented on pull request "Fix tiebreak when loading blocks from disk (and add tests for comparing chain ties)":
(https://github.com/bitcoin/bitcoin/pull/29640#discussion_r2183252361)
Fixed in [8d73371](https://github.com/bitcoin/bitcoin/pull/29640/commits/8d7337189a1b7024a40933bf082b7b574fd007e1)

💬 davidgumberg commented on pull request "build: Make config warnings fatal if -DWCONFIGURE_ERROR=ON":
(https://github.com/bitcoin/bitcoin/pull/31665#issuecomment-3033009863)
OK, closing this in favor of #32865.

✅ davidgumberg closed a pull request: "build: Make config warnings fatal if -DWCONFIGURE_ERROR=ON"
(https://github.com/bitcoin/bitcoin/pull/31665)

💬 davidgumberg commented on pull request "build: Make config warnings fatal if -DWCONFIGURE_ERROR=ON":
(https://github.com/bitcoin/bitcoin/pull/31665#discussion_r2183332678)
Thanks for catching this, I've fixed this for the sake of posterity, but I've closed this PR in favor of #32865.

💬 davidgumberg commented on pull request "build: Make config warnings fatal if -DWCONFIGURE_ERROR=ON":
(https://github.com/bitcoin/bitcoin/pull/31665#discussion_r2183339114)
OK, looks like the PR won't update with my branch now that it's closed, but it's here: https://github.com/davidgumberg/bitcoin/tree/1-15-24-configure_warnings

💬 mzumsande commented on pull request "Fix tiebreak when loading blocks from disk (and add tests for comparing chain ties)":
(https://github.com/bitcoin/bitcoin/pull/29640#discussion_r2183379788)
If the situation "previous blocks all have nSequenceId = x-1 and the tip has x" is weird, wouldn't that exact same situation occur anyway when the next block arrives via p2p (which would get `nSequenceId=2`, where all predecessors have `nSequenceId=1`)?

And if `nSequenceId` is supposed to be monotonically increasing (which I think would mean that no connectable block should have a lower `nSequenceId` than its predecessor), wouldn't that be an argument **for** only setting the tip rather than
...

💬 KATHI160 commented on issue "intermittent timeout in wallet_signer.py : 'createwallet' RPC took longer than 1200.000000 seconds":
(https://github.com/bitcoin/bitcoin/issues/32855#issuecomment-3033399551)
> in the `multiprocess, i686, DEBUG` task in `self.nodes[1].createwallet(wallet_name='hww_disconnect', disable_private_keys=True, external_signer=True)`,
>
> https://cirrus-ci.com/task/5704849158832128?logs=ci#L2967:
>
> ```
> node1 2025-06-26T14:05:40.072184Z [msghand] [net_processing.cpp:3452] [ProcessMessage] [net] received: pong (8 bytes) peer=0
> test 2025-06-26T14:05:43.222938Z TestFramework (ERROR): JSONRPC error
> Traceback (most recent call last
...

💬 sr-gi commented on pull request "Fix tiebreak when loading blocks from disk (and add tests for comparing chain ties)":
(https://github.com/bitcoin/bitcoin/pull/29640#discussion_r2183627680)
> so having a chain of blocks where the previous blocks all have nSequenceId = x-1 and the tip has x

Sorry, I wrote that wrong. `:s/x-1/x+1/g`

In the case were we only change the tip, the rest of blocks will have `nSequenceId=1`, so we will end up with a chain like:

`1 -> 1 -> 1 -> 0 (tip)` that will evolve to `1 -> 1 -> 1 -> 0 -> 2 (tip)`

All other chains will have `nSequenceId=1` from start to end.

In the case proposed here, we'll have

`0 -> 0 -> 0 -> 0 (tip)` evolving to `
...

💬 mzumsande commented on pull request "Fix tiebreak when loading blocks from disk (and add tests for comparing chain ties)":
(https://github.com/bitcoin/bitcoin/pull/29640#discussion_r2183651193)
oh right, I got confused in my earlier post, you are right. Still, maybe others could chime in if they think that this monotonicity is worth the added work or not.