📝 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:

💬 maflcko commented on pull request "cmake: Introduce `WITH_PYTHON` build option":
(https://github.com/bitcoin/bitcoin/pull/31669#issuecomment-2866998704)
> forcing builders to opt out of things they don't care about

I am not sure the current approach of silently skipping tests (with just a warning during configure, not when running the tests) is the right approach.

A third alternative would be to delay the error to when they run the tests.

A fourth alternative would be to just call the two python tests from the functional test runner somehow and remove all this code here?

💬 hebasto commented on pull request "cmake: Introduce `WITH_PYTHON` build option":
(https://github.com/bitcoin/bitcoin/pull/31669#issuecomment-2867005648)
> > forcing builders to opt out of things they don't care about
>
> I am not sure the current approach of silently skipping tests (with just a warning during configure, not when running the tests) is the right approach.
>
> A third alternative would be to delay the error to when they run the tests.

FWIW, something similar has been implemented in https://github.com/bitcoin/bitcoin/pull/31233.

💬 fanquake commented on pull request "test: Suppress Windows abort message in CI":
(https://github.com/bitcoin/bitcoin/pull/32409#discussion_r2081949565)
I think the commit message should still be fixed to say `When compiling with MSVC`, rather than `On Windows`?

> (I've added a note to the PR description)

Is it a bug in mingw-w64 that it doesn't match the MSVC behaviour? It would be good to an explanation of the difference in the PR description/commit message, as it isn't really clear from going to the link you've provided.

💬 fanquake commented on pull request "test: Suppress Windows abort message in CI":
(https://github.com/bitcoin/bitcoin/pull/32409#issuecomment-2867023954)
> It is documented, and it is pre-defined by CI itself:

It's not in our docs, or in our CI code, which means our CI would "work", because a third party is putting something into the environment, and the fact that this is even happening, is only discoverable if you happen to read a `.cpp` file.

Would someone running these binaries locally also need/want to set this env var to get the same behaviour? If so, how would they figure that out?

💬 hebasto commented on pull request "test: Suppress Windows abort message in CI":
(https://github.com/bitcoin/bitcoin/pull/32409#discussion_r2081956577)
> Is it a bug in mingw-w64 that it doesn't match the MSVC behaviour?

I don't think so, given the different runtime libraries used. I must admit I haven't tested cross-compiled binaries linked to UCRT.

⚠️ ismaelsadeeq opened an issue: "RFC: Should node Wallet Startup Options Apply to Individual Wallets?"
(https://github.com/bitcoin/bitcoin/issues/32462)
PR #29278 is going to introduces a `maxfeerate` wallet startup option.

There was some discussion between between @luke-jr , me, and @murchandamus in a thread https://github.com/bitcoin/bitcoin/pull/29278#discussion_r1468533274

> This still isn't a wallet option...

> I don't understand why you said it is not a wallet option.
> The `OptionsCategory` of this startup option is `WALLET`, and it's only used in the wallet.
> Can you please expand on your comment?
> Thanks.

> I’m also confused by t
...