💬 Sjors commented on pull request "miner: timelock the coinbase to the mined block's height":
(https://github.com/bitcoin/bitcoin/pull/32155#issuecomment-2761158943)
> Did a simple test with regtest

> so this PR only affects to test networks

Unfortunately regtest is not representative here. It's the only network for which Bitcoin Core will mine by itself. For all other networks, including testnet (3 and 4), you need to use external software.

💬 polespinasa commented on pull request "miner: timelock the coinbase to the mined block's height":
(https://github.com/bitcoin/bitcoin/pull/32155#issuecomment-2761190738)
> Unfortunately regtest is not representative here. It's the only network for which Bitcoin Core will mine by itself. For all other networks, including testnet (3 and 4), you need to use external software.

This is what I though. So how does this change "help" or "put pressure" to add this new rule to miners software? Wouldn't help more implement the code that will check if a block is following it? Obviously code that would never be ran without another change to add an activation date.

💬 hebasto commented on pull request "build: Switch to Qt 6":
(https://github.com/bitcoin/bitcoin/pull/30997#issuecomment-2761205057)
The last [feedback](https://github.com/bitcoin/bitcoin/pull/30997#discussion_r2017831104) from @fanquake has been addressed.

💬 hebasto commented on pull request "build: Switch to Qt 6":
(https://github.com/bitcoin/bitcoin/pull/30997#discussion_r2018562707)
Thanks! [Fixed](https://github.com/bitcoin/bitcoin/pull/30997#issuecomment-2761205057).

💬 RandyMcMillan commented on pull request "Feature: Use different datadirs for different signets":
(https://github.com/bitcoin/bitcoin/pull/29838#issuecomment-2761209767)
👀 going to revisit this PR today...

💬 hebasto commented on pull request "build: Switch to Qt 6":
(https://github.com/bitcoin/bitcoin/pull/30997#issuecomment-2761243794)
My Guix build:
```
aarch64
6ea4a76be3383337e57d6a12450bd589776ebb3fd0d9161347766ef845241e13 guix-build-c4861570e468/output/aarch64-linux-gnu/SHA256SUMS.part
3eb7656483dfe47fa6b7cf40bceb3decda73474c813edb224d42840adb8b49d6 guix-build-c4861570e468/output/aarch64-linux-gnu/bitcoin-c4861570e468-aarch64-linux-gnu-debug.tar.gz
0aa522010efd138d78eeac0a8ea15df469298c50afaa2451dece78c564546cac guix-build-c4861570e468/output/aarch64-linux-gnu/bitcoin-c4861570e468-aarch64-linux-gnu.tar.gz
5e1e8335
...

🤔 janb84 reviewed a pull request: "test: create assert_not_equal util"
(https://github.com/bitcoin/bitcoin/pull/29500#pullrequestreview-2725387180)
Concept ACK [be71af3](https://github.com/bitcoin/bitcoin/commit/be71af3cc0b0bcb7d917cc6f2e5fda119f1b1bd6)

- Code review ✅
- Build & tested ✅

I agree with @hodlinator on the import order NIT — let's keep it consistent and maintain clean, high-quality code.

💬 Sjors commented on pull request "miner: timelock the coinbase to the mined block's height":
(https://github.com/bitcoin/bitcoin/pull/32155#issuecomment-2761301569)
> Wouldn't help more implement the code that will check if a block is following it?

That's what activating the soft-fork does. But there's a chicken-egg problem, because one reason to delay activating a soft fork is because part of the ecosystem isn't ready.

> So how does this change "help" or "put pressure" to add this new rule to miners software?

As I explained in my first comment, for Stratum v2 this just works(tm). For Stratum v1 additional changes are needed in other software. Not
...

💬 furszy commented on pull request "wallet, migration: Fix empty wallet crash":
(https://github.com/bitcoin/bitcoin/pull/32149#discussion_r2018614237)
This leaves the db batch object alive and could conflict with the `Flush()` and `DeleteRecords()` internals, as both access the db.

Better to limit the scope of the db batch object only to this function call.

💬 instagibbs commented on pull request "tests: improves tapscript unit tests":
(https://github.com/bitcoin/bitcoin/pull/31640#issuecomment-2761340139)
could you squash commits?

💬 hodlinator commented on pull request "qa: Verify clean shutdown on startup failure":
(https://github.com/bitcoin/bitcoin/pull/30660#discussion_r2018664612)
Was able to easily reproduce the issue.

<details><summary>Log</summary>

C:\Users\hodlinator\bitcoin>py build\test\functional\feature_framework_startup_failures.py
2025-03-28T13:09:19.459000Z TestFramework (INFO): PRNG seed is: 4595347679033165165
2025-03-28T13:09:19.519000Z TestFramework (INFO): Initializing test directory C:\Users\HODLIN~1\AppData\Local\Temp\bitcoin_func_test_4hxul9x2
2025-03-28T13:09:19.519000Z TestFramework (INFO): Verifying timeout in connecting to bitcoind's RPC in
...

💬 darosior commented on issue "Enable PCP by default?":
(https://github.com/bitcoin/bitcoin/issues/31663#issuecomment-2761393363)
@Lagrang3 thanks for the testing. I assume like other Archer routers it was enabled by default?

📝 maflcko opened a pull request: "fuzz: Make partially_downloaded_block more deterministic"
(https://github.com/bitcoin/bitcoin/pull/32158)
This should make the `partially_downloaded_block` fuzz target even more deterministic.

Follow-up to https://github.com/bitcoin/bitcoin/pull/31841. Tracking issue: https://github.com/bitcoin/bitcoin/issues/29018.

This bundles several changes:

* First, speed up the `deterministic-fuzz-coverage` helper by introducing parallelism.
* Then, a fix to remove spawned test threads or spawn them deterministically. (While testing this, high parallelism and thread contention may be needed)

### T
...

💬 hodlinator commented on pull request "qa: Verify clean shutdown on startup failure":
(https://github.com/bitcoin/bitcoin/pull/30660#discussion_r2018729209)
Thread https://github.com/bitcoin/bitcoin/pull/30660/files#r2018221082:
Taken.

🤔 hodlinator reviewed a pull request: "qa: Verify clean shutdown on startup failure"
(https://github.com/bitcoin/bitcoin/pull/30660#pullrequestreview-2725634006)
Latest push:
* Removes `test_instant_rpc_timeout` which was artificially setting `rpc_timeout = 0`, which is not a supported case and which caused different behavior on Windows network stacks compared to Linux. That test was a rough subset of `test_wrong_rpc_port`. Removing `test_instant_rpc_timeout` allowed dropping the commit with the workaround for socket timeout with unset errno entirely. **Special thanks to @maflcko for [insisting](https://github.com/bitcoin/bitcoin/pull/30660#discussion_r
...

💬 hodlinator commented on pull request "qa: Verify clean shutdown on startup failure":
(https://github.com/bitcoin/bitcoin/pull/30660#discussion_r2018732697)
Dropped the test and workaround commit in latest push.

📝 willcl-ark opened a pull request: "net, pcp: handle multi-part responses and filter..."
(https://github.com/bitcoin/bitcoin/pull/32159)
...for default route in pcp pinholing.

Currently we only make a single recv call, which trucates results from large routing tables, or in the case the kernel may split the message into multiple responses (which may happen with `NLM_F_DUMP`).

We also do not filter on the default route. For IPv6, this led to selecting the first route with an `RTA_GATEWAY` attribute, often a non-default route instead of the actual default. This caused PCP port mapping failures because the wrong gateway was us
...

💬 willcl-ark commented on pull request "net, pcp: handle multi-part responses and filter...":
(https://github.com/bitcoin/bitcoin/pull/32159#issuecomment-2761490048)
cc @laanwj

This patch maintains the FreeBSD-style querying/filtering we have currently, but but increases the size of the response processed to a maximum of 1MB.

💬 maflcko commented on pull request "contrib: Make deterministic-coverage error messages more readable":
(https://github.com/bitcoin/bitcoin/pull/32074#discussion_r2018767731)
> If you want to implement some version of it I'm happy to review, or we can defer it, not sure when I'll be able to get it into good shape.

Done in https://github.com/bitcoin/bitcoin/pull/32158. I ended up only taking `thread::scope` and `VecDeque` and restructured the rest. Lmk if this sounds good, or if you want to be listed as co-author.

💬 martinus commented on pull request "Draft: CCoinMap Experiments":
(https://github.com/bitcoin/bitcoin/pull/32128#discussion_r2018784600)
@sipa thanks, you are of course right; I should have read a bit more about that before... Nevertheless I think it's at least interesting to see what difference a fast hash would make.