👍 theStack approved a pull request: "Reintroduce external signer support for Windows"
(https://github.com/bitcoin/bitcoin/pull/29868#pullrequestreview-2828598770)
Light ACK 3a18075aedd7cff6f06b5fe10966d618b6378701

Cross-compiled for Windows from a Linux machine [using mingw-w64](https://github.com/bitcoin/bitcoin/blob/b070ce16966fe18eb68f886ab9ca02d1d05a2f2a/doc/build-windows.md?plain=1#L48-L52) and ran the involved unit and functional tests on a Windows 10 machine (needed to adapt the paths `./test/config.ini` manually on the target system, like also [done in the CI job](https://github.com/bitcoin/bitcoin/blob/b070ce16966fe18eb68f886ab9ca02d1d05a2f2a/
...

💬 maflcko commented on pull request "qt: drop unused watch-only functionality":
(https://github.com/bitcoin/bitcoin/pull/32459#discussion_r2081826786)
this should probably be a separate commit, just updating the whole file, or nothing in the file?

💬 laanwj commented on pull request "rpc: Undeprecate rpcuser/rpcpassword, store all credentials hashed in memory":
(https://github.com/bitcoin/bitcoin/pull/32423#discussion_r2081831829)
Anyhow, i'll cherry-pick this, thanks, hope i won't get the opposite comment now that this is changing too much 😓

💬 hebasto commented on pull request "qt: drop unused watch-only functionality":
(https://github.com/bitcoin/bitcoin/pull/32459#discussion_r2081841029)
https://github.com/bitcoin/bitcoin/blob/b070ce16966fe18eb68f886ab9ca02d1d05a2f2a/src/qt/bitcoinstrings.cpp#L5

💬 instagibbs commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#discussion_r2081860464)
added a comment and bumped the value

💬 rkrux commented on pull request "Wallet: Fix Non-Ranged Descriptors with Range [0,0] Trigger Unexpected Wallet Errors in AddWalletDescriptor":
(https://github.com/bitcoin/bitcoin/pull/32344#issuecomment-2866886845)
> Then how can the user trigger the error being solved here? If it can't be triggered by the user, we're talking about an extra guard rather than a fix — which is fine as well, but it would be better to label the PR differently, since it won't need to be backported.

Agree that the PR can be labeled differently.

> When attempting to add a non-ranged descriptor with a start/end range of [0,0] via AddWalletDescriptor, an error may appear

The issue #31728 description states that it is trigg
...

📝 fanquake opened a pull request: "fs: remove `_POSIX_C_SOURCE` defining"
(https://github.com/bitcoin/bitcoin/pull/32460)
From what I can tell, compilers on Linux systems, will be defining `_GNU_SOURCE`, which results in `glibc` defining `_POSIX_C_SOURCE` to `200809L`; so undefining it, and setting it to an earlier value does not seem like the correct behaviour for us, or even required, to check that this function is usable on Linux. I think there's also the chance that this could have adverse effects, by essentially trying to opt out of more mordern POSIX behaviour?

I think if anything, the project should be se
...

✅ fanquake closed an issue: "cmake inconsistently overriding `-O3` (sometimes)"
(https://github.com/bitcoin/bitcoin/issues/31491)

💬 fanquake commented on issue "cmake inconsistently overriding `-O3` (sometimes)":
(https://github.com/bitcoin/bitcoin/issues/31491#issuecomment-2866893762)
Given the amount of discussion here, we can re-open new issues.

⚠️ l0rinc opened an issue: "test: `acceptstalefeeestimates` failure in `feature_fee_estimation` after duplicate coinbase tx weight reservation fix"
(https://github.com/bitcoin/bitcoin/issues/32461)
### Summary
First encountered in https://github.com/bitcoin/bitcoin/actions/runs/14929268797/job/41941137828?pr=31144

Doing a git bisect reveals the likely culprit is [mining: bugfix: Fix duplicate coinbase tx weight reservation](https://github.com/bitcoin/bitcoin/pull/31384)

---

### Reproducer

> git checkout 6b165f5906fc53bd10bedff85a6ef26e0aabdc5c

```bash
HEAD is now at 6b165f5906 Merge bitcoin/bitcoin#31384: mining: bugfix: Fix duplicate coinbase tx weight reservation
```

> cmake -B bui
...

💬 l0rinc commented on pull request "[IBD] multi-byte block obfuscation":
(https://github.com/bitcoin/bitcoin/pull/31144#issuecomment-2866907838)
Rebased, opened issue for [unrelated test failure](https://github.com/bitcoin/bitcoin/issues/32461)

💬 hebasto commented on pull request "cmake: Introduce `WITH_PYTHON` build option":
(https://github.com/bitcoin/bitcoin/pull/31669#discussion_r2081895682)
@maflcko
> Another alternative would be to just require python3, without a way to disable it. Thus, the option `WITH_PYTHON` can be removed.

Here is some historical context: treating the `Python3` package as optional was introduced in the staging [branch](https://github.com/hebasto/bitcoin/pull/15#discussion_r1192711084). In particular, @theuni noted:
> This makes us dependent on python, even if we're not running tests/bench, no? I wouldn't expect python to be a hard requirement for buildi
...

💬 l0rinc commented on pull request "bench: replace benchmark block with more representative one (413567 → 784588)":
(https://github.com/bitcoin/bitcoin/pull/32457#discussion_r2081901172)
Yes, this one definitely, but in the other cases I'm worried about introducing a strong bias.
It's not like we're changing these very often - but I'll investigate anyway, let's see how close we can get without adding 1.5 Mb to the repo.

💬 hebasto commented on pull request "cmake: Introduce `WITH_PYTHON` build option":
(https://github.com/bitcoin/bitcoin/pull/31669#discussion_r2081903398)
> I see. I guess I wanted to say the opposite: Can't this be removed, because it seems a bit odd to print a warning that something is disabled, when the users explicitly asked it to be disabled? There is also no warning when a user sets `BUILD_TESTS=OFF`.

Thanks! Implemented.

👋 hebasto's pull request is ready for review: "cmake: Introduce `WITH_PYTHON` build option"
(https://github.com/bitcoin/bitcoin/pull/31669)

💬 brunoerg commented on pull request "test: added fuzz coverage for consensus/merkle.cpp":
(https://github.com/bitcoin/bitcoin/pull/32243#discussion_r2081903903)
`ConsumeTransaction` is fine.

💬 hebasto commented on pull request "cmake: Introduce `WITH_PYTHON` build option":
(https://github.com/bitcoin/bitcoin/pull/31669#issuecomment-2866948636)
The [feedback](https://github.com/bitcoin/bitcoin/pull/31669#discussion_r2081903398) from @maflcko has been addressed.

Also rebased.

🤔 fanquake requested changes to a pull request: "cmake: Introduce `WITH_PYTHON` build option"
(https://github.com/bitcoin/bitcoin/pull/31669#pullrequestreview-2828742547)
As I mentioned above, adding more build options/compexity, and forcing builders to opt out of things they don't care about, does not seem like a good, nor generic approach to fixing #31476. Especailly given this is essentially a CI fix, to work around the fact that CMake doesn't have a way to turn warnings into errors?

💬 fanquake commented on pull request "cmake: Introduce `WITH_PYTHON` build option":
(https://github.com/bitcoin/bitcoin/pull/31669#discussion_r2081908186)
> That concern still appears to be relevant.

Yea. This is also essentially reintroducing the previous Autotools behaviour of having opt-out dependencies (i.e bdb for a long time), rather than opt-in, which is what we started doing with CMake.

💬 laanwj commented on pull request "bench: replace benchmark block with more representative one (413567 → 784588)":
(https://github.com/bitcoin/bitcoin/pull/32457#discussion_r2081925616)
it's not just the amount of data, we're still scared from the xz backdoor incident :smile: