✅ maflcko closed a pull request: "cmake: Inherit WERROR setting for secp256k1 build"
(https://github.com/bitcoin/bitcoin/pull/33297)

📝 maflcko reopened a pull request: "cmake: Inherit WERROR setting for secp256k1 build"
(https://github.com/bitcoin/bitcoin/pull/33297)
This change prevents unexpected CLI output when compiling with -DWERROR=ON (treat warnings as errors). This setting is now properly propagated to the secp256k1 subproject build. Previously, secp256k1 would be built without the -Werror flag even when the main project was configured to treat warnings as errors, creating inconsistent build behavior.
https://github.com/bitcoin/bitcoin/issues/33284

💬 fanquake commented on issue "ci: windows-native-dll-vcpkg-* cache does not work?":
(https://github.com/bitcoin/bitcoin/issues/33685#issuecomment-3450952259)
> However, the following "Generate Build System" step takes more than 30 minutes:

Looks like it can take up to 51 minutes: https://github.com/bitcoin/bitcoin/actions/runs/18837851942/job/53742910238#step:8:200.

✅ ryanofsky closed an issue: "RFC: Multiprocess binaries and packaging options"
(https://github.com/bitcoin/bitcoin/issues/30983)

💬 ryanofsky commented on issue "RFC: Multiprocess binaries and packaging options":
(https://github.com/bitcoin/bitcoin/issues/30983#issuecomment-3451033643)
There will probably be more PRs implementing ideas discussed here, but they can be worked on in separate PR's and issues and this can be closed. Possible followups:

1. Adding `-ipcbind` option to `bitcoind` to make IPC features available without using `bitcoin` command and to reduce number of internal binaries that need to be built and installed [(comment)](https://github.com/bitcoin/bitcoin/issues/30983#issuecomment-3210296557).

2. Implementing `-ipcnode` and `-ipcwallet` options (probably as
...

💬 ryanofsky commented on issue "Stratum v2 via IPC Mining Interface tracking issue":
(https://github.com/bitcoin/bitcoin/issues/31098#issuecomment-3451047615)
Does it make sense to close this issue?

✅ ryanofsky closed an issue: "Mining Interface doesn't allow for Bitcoin Core to create blocks when it wants"
(https://github.com/bitcoin/bitcoin/issues/31109)

💬 ryanofsky commented on issue "Mining Interface doesn't allow for Bitcoin Core to create blocks when it wants":
(https://github.com/bitcoin/bitcoin/issues/31109#issuecomment-3451090702)
I think it makes sense to close this issue, since there is a working interface for mining clients to ask for new block templates and receive them when they are ready.

It's possible the implementation of this interface could be more efficient and avoid locking cs_main, or be more DoS-resistant, but I think those improvements would be only be implementation details, and there isn't a way i can see that changing the interface would be helpful or needed for them.

✅ ryanofsky closed an issue: "RFC: Adding bitcoin-{node,gui} binaries for IPC in 30.0 release"
(https://github.com/bitcoin/bitcoin/issues/31756)

💬 ryanofsky commented on issue "RFC: Adding bitcoin-{node,gui} binaries for IPC in 30.0 release":
(https://github.com/bitcoin/bitcoin/issues/31756#issuecomment-3451102216)
> Anything left to be done here?

There are some possible followups that can be done (listed in https://github.com/bitcoin/bitcoin/issues/30983#issuecomment-3451033643) but this issue can be closed

💬 fanquake commented on pull request "guix: build for Linux HOSTS with `-static-libgcc`":
(https://github.com/bitcoin/bitcoin/pull/33181#issuecomment-3451232152)
Guix Build (x86_64):
```bash
2f47825c394b4c4e9fe9495a2c0750ac34e78211391264d47ded7c676e78479a guix-build-c74705d81a88/output/aarch64-linux-gnu/SHA256SUMS.part
99a17c7dc93a17a344e53be8c1a19bb98f259a5387ff22f4f8e9af988a447128 guix-build-c74705d81a88/output/aarch64-linux-gnu/bitcoin-c74705d81a88-aarch64-linux-gnu-debug.tar.gz
b91f417b34b438db585c614780ae38bab35c3e313a1ac84ada8e090839cf6e63 guix-build-c74705d81a88/output/aarch64-linux-gnu/bitcoin-c74705d81a88-aarch64-linux-gnu.tar.gz
8e146b6
...

💬 ryanofsky commented on issue "How to backport libmultiprocess changes?":
(https://github.com/bitcoin/bitcoin/issues/33439#issuecomment-3451232704)
I think this issue can be closed and there's a pretty clear process for backporting changes now.

- For the `30.x` branch, since changes to the `src/ipc/libmultiprocess` subtree have been made to `master` after the `30.x` branch point, we need to have separate PR's like #33519 to update the subtree in `30.x`.
- For future releases (`31.x` and later) we could base new subtree updates on previous subtree updates instead of on newer master commits. This would allow a single subtree update PR to be
...

✅ ryanofsky closed an issue: "How to backport libmultiprocess changes?"
(https://github.com/bitcoin/bitcoin/issues/33439)

✅ sshivanshg closed a pull request: "serialize: Change GetSerializeSize return type to uint64_t"
(https://github.com/bitcoin/bitcoin/pull/33712)

🤔 maflcko reviewed a pull request: "wallet: Prepare for future upgrades by recording versions of last client to open and decrypt"
(https://github.com/bitcoin/bitcoin/pull/32895#pullrequestreview-3000196658)
(just the llm nits)

💬 maflcko commented on pull request "wallet: Prepare for future upgrades by recording versions of last client to open and decrypt":
(https://github.com/bitcoin/bitcoin/pull/32895#discussion_r2194162406)
nit in the first commit:

* “when a upgrade-downgrade-upgrade was performed” -> “when an upgrade-downgrade-upgrade was performed” [incorrect indefinite article before a vowel sound]

💬 maflcko commented on pull request "wallet: Prepare for future upgrades by recording versions of last client to open and decrypt":
(https://github.com/bitcoin/bitcoin/pull/32895#discussion_r2221675720)
LastClientFEatures -> LastClientFeatures [typo in capitalization of “Features”]

🤔 brunoerg reviewed a pull request: "fuzz: avoid returning non-conforming results from FuzzedSock::GetSockName()"
(https://github.com/bitcoin/bitcoin/pull/32109#pullrequestreview-3383591153)
Concept NACK

Not a strong NACK, I'm open to discuss and change my mind, but I don't see `It is ok to assume the OS functions conform to their specifications and our production code need not handle non-conforming behavior from OS functions.` (https://github.com/bitcoin/bitcoin/pull/32109#issuecomment-2801844948) as a strong motivation. I tend to agree with @darosior's points.

Obviously, it would only happen if there is any OS bug which is unlikely. However, I don't think it strongs affect
...

💬 Crypt-iQ commented on pull request "net: Provide block templates to peers on request":
(https://github.com/bitcoin/bitcoin/pull/33191#discussion_r2465769447)
Does `MAX_PROTOCOL_MESSAGE_LENGTH` need to change if a peer requests most txns in a > 4MB template?

💬 willcl-ark commented on issue "Think about tuning the script cache/sigcache ratios":
(https://github.com/bitcoin/bitcoin/issues/10754#issuecomment-3451493924)
I have started to look into this a little further to see whether it might be worth putting more work into, but so far I am not convinced.

I first added some logging to the cache lookups to get a better idea of how well the caches are performing currently, which yeilded these results when logging every minute, plus isolated block acceptance stats:

<details>
<summary>All</summary>

```
<snip>
2025-10-18T06:42:40Z Block 00000000000000000000fa029afeee99fbf4d9fbd1d968773895bcc375e9b453 cache stats:
...