✅ 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:
...

✅ fanquake closed an issue: "29.x Having qt(@6) breaks build for qt@5 on macOS 15.0 and 13.7"
(https://github.com/bitcoin/bitcoin/issues/31009)

💬 fanquake commented on issue "29.x Having qt(@6) breaks build for qt@5 on macOS 15.0 and 13.7":
(https://github.com/bitcoin/bitcoin/issues/31009#issuecomment-3451579595)
Was closed with #32810.

💬 hMsats commented on issue "Seemingly second (very long) validation at the same height":
(https://github.com/bitcoin/bitcoin/issues/33687#issuecomment-3451724835)
After more than 48 hours, not a single timeout for a division by 10 (based on 1 minute or 600/10=60 seconds) and a cold start. For height, verification time, time and date and peer see [here](https://bitcoinserver.nl/deltv_days.txt).

🤔 mzumsande reviewed a pull request: "net: option to disallow v1 connection on ipv4 and ipv6 peers"
(https://github.com/bitcoin/bitcoin/pull/30951#pullrequestreview-3384015944)
A year later, adoption is now almost at ~70% according to https://21.ninja/reachable-nodes/node-service-share/ - could update the OP with that info.

💬 hodlinator commented on pull request "qa: Avoid knock-on exception in assert_start_raises_init_error":
(https://github.com/bitcoin/bitcoin/pull/32929#issuecomment-3451806957)
> No objections, but in this case, it seems beneficial (or at least harmless) to list the init args, which could help debug why the init error was not raised?

Good point, that information from the initial exception was no longer included. Added back in latest push & updated PR description example output.

👍 pinheadmz approved a pull request: "test: add functional test for `TestShell` (matching doc example)"
(https://github.com/bitcoin/bitcoin/pull/33546#pullrequestreview-3384132863)
ACK 57f7c68821d96cc096db624cb06b7a252d038300

Modulo @stratospher comment about adding to `TEST_FRAMEWORK_UNIT_TESTS`.

Reviewed changes in both commits, followed the example from the doc manually and tried a variety of setup options and testshell commands. Confirmed the changes to the doc (wallet name and noshutdown). Built and ran test on macos/arm64

<details><summary>Show Signature</summary>

```
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

ACK 57f7c68821d96cc096db624cb06b7a2
...

💬 pinheadmz commented on pull request "test: add functional test for `TestShell` (matching doc example)":
(https://github.com/bitcoin/bitcoin/pull/33546#discussion_r2466128505)
I think this counts as unit test? Could just go in `TEST_FRAMEWORK_UNIT_TESTS` IMO

🤔 Eunovo reviewed a pull request: "interfaces: enable cancelling running `waitNext` calls"
(https://github.com/bitcoin/bitcoin/pull/33676#pullrequestreview-3384019091)
Concept ACK https://github.com/bitcoin/bitcoin/pull/33676/commits/f4e63cc807f8c34a780604bd3802739c37209b75

I took a first look and left some nits. I'll take a second look.