👍 dergoegge approved a pull request: "contrib: add bitcoin binary to gen-manpages"
(https://github.com/bitcoin/bitcoin/pull/33348#pullrequestreview-3200876564)
ACK 53e6db91ef59a80d9141f6bbc56dd547b6c1b46b

🚀 fanquake merged a pull request: "contrib: add bitcoin binary to gen-manpages"
(https://github.com/bitcoin/bitcoin/pull/33348)

💬 fanquake commented on pull request "contrib: add bitcoin binary to gen-manpages":
(https://github.com/bitcoin/bitcoin/pull/33348#issuecomment-3270141486)
Partial (f5887a8de4c8b3492aa8713c59c4e3819fd4e42b) backport to 30.x in #33349.

🤔 naiyoma reviewed a pull request: "net: Prevent node from binding to the same `CService`"
(https://github.com/bitcoin/bitcoin/pull/33231#pullrequestreview-3200967067)

Tested ACK 4d4789dffad55b96f1cb96b718cc6923f5344454

Manually tested with different duplicate bindings.
```
./build/bin/bitcoind -bind=0.0.0.0=onion -bind=0.0.0.0=onion
./build/bin/bitcoind -bind=0.0.0.0 -bind=0.0.0.0
./build/bin/bitcoind -whitebind=relay@127.0.0.1:8333 -whitebind=mempool@127.0.0.1:8333
```
On master, the error message is misleading
```
2025-09-09T10:59:38Z [net:error] Unable to bind to 0.0.0.0:8334 on this computer. Bitcoin Core is probably already running.
2025-09
...

👍 hebasto approved a pull request: "[30.x] v30.0rc1"
(https://github.com/bitcoin/bitcoin/pull/33349#pullrequestreview-3200973343)
ACK d00b82fc96e194a9826a76c9374f809ebbdc356a. On Ubuntu 25.04, I've got the same generated files.

👋 fanquake's pull request is ready for review: "[30.x] v30.0rc1"
(https://github.com/bitcoin/bitcoin/pull/33349)

🤔 janb84 reviewed a pull request: "[30.x] v30.0rc1"
(https://github.com/bitcoin/bitcoin/pull/33349#pullrequestreview-3201057744)
ACK d00b82fc96e194a9826a76c9374f809ebbdc356a

On Nix (on mac host):
- builds ✅
- tests ✅
- Generates the same files ✅ (except for the date in the generated manpages)

💬 Sjors commented on pull request "index: Fix coinstats overflow":
(https://github.com/bitcoin/bitcoin/pull/30469#issuecomment-3270333059)
I built the index with v29.1 as well as c76797481155754329ec6a6f58e8402569043944.

`getblockstats` gives the same result for both at height 913,859. The new `coinstatsindex` directory is 213 MB, so a bit bigger than the original `coinstats`, but small in any case.

👍 stickies-v approved a pull request: "[30.x] v30.0rc1"
(https://github.com/bitcoin/bitcoin/pull/33349#pullrequestreview-3201216362)
ACK d00b82fc96e194a9826a76c9374f809ebbdc356a - getting identical manpages and bitcoin.conf output. Other changes LGTM too.

🚀 fanquake merged a pull request: "[30.x] v30.0rc1"
(https://github.com/bitcoin/bitcoin/pull/33349)

💬 fanquake commented on issue "Release Schedule for 30.0":
(https://github.com/bitcoin/bitcoin/issues/32275#issuecomment-3270474209)
`v30.0rc1` has been tagged: https://github.com/bitcoin/bitcoin/releases/tag/v30.0rc1.

💬 vasild commented on pull request "net: Fix Discover() not running when using -bind=0.0.0.0:port":
(https://github.com/bitcoin/bitcoin/pull/32757#discussion_r2333538296)
If you retouch, this comment is also outdated and needs a tweak, for example:

```suggestion
# We need to bind to a routable address for this test to exercise the relevant code
# and also must have another routable address. Those addresses must be on an interface
# that is UP and is not a loopback interface (IFF_LOOPBACK).
```

⚠️ ziggie1984 opened an issue: "Difficulty in reliably mapping errors from Bitcoin Core due to unstable error codes and messages"
(https://github.com/bitcoin/bitcoin/issues/33350)
### Please describe the feature you'd like to see added.

It's becoming increasingly difficult to reliably map and handle errors originating from Bitcoin Core. The primary challenge stems from the frequent changes in both the error codes and the descriptive error text.

Problem Description
Our current error-handling logic relies on parsing the responses from Bitcoin Core. However, this approach is fragile for two main reasons:

Unstable Error Codes: The numerical error codes returned by Bitcoin
...

💬 sipa commented on pull request "net: Prevent node from binding to the same `CService`":
(https://github.com/bitcoin/bitcoin/pull/33231#issuecomment-3270763797)
utACK 4d4789dffad55b96f1cb96b718cc6923f5344454

💬 sipa commented on pull request "ci, iwyu: Treat warnings as errors for specific directories":
(https://github.com/bitcoin/bitcoin/pull/31308#issuecomment-3270768314)
Concept ACK

👍 ryanofsky approved a pull request: "ci, iwyu: Treat warnings as errors for specific directories"
(https://github.com/bitcoin/bitcoin/pull/31308#pullrequestreview-3201650940)
Code review ACK 02d2b5a11c921ef71c971ee80eb3dfbc75c8cb0d. Just rebased and update tidy patch comment again since last review

👍 ryanofsky approved a pull request: "ci: detect outbound internet traffic generated while running tests"
(https://github.com/bitcoin/bitcoin/pull/31349#pullrequestreview-3201679543)
Code review ACK 151edfaf78115402c29088dabc271c2b268102a5. Just rebased since last review and replaced node_init_tests fix CreateSock fix with natpmp=0 fix

💬 rkrux commented on pull request "wallet: Be able to receive and spend inputs involving MuSig2 aggregate keys":
(https://github.com/bitcoin/bitcoin/pull/29675#discussion_r2333720544)
In https://github.com/bitcoin/bitcoin/commit/d23116987d19587746d392895c06f5c426c1d0d2 "test: Test MuSig2 in the wallet"

With the addition of the case where musig is both in keypath and spendpath, I think it would be nice to assert which spending path is triggered.

<details open>
<summary>Diff</summary>

```diff
diff --git a/test/functional/wallet_musig.py b/test/functional/wallet_musig.py
index b7f3cc9d96..63276b1eb7 100755
--- a/test/functional/wallet_musig.py
+++ b/test/functional
...

💬 rkrux commented on pull request "wallet: Be able to receive and spend inputs involving MuSig2 aggregate keys":
(https://github.com/bitcoin/bitcoin/pull/29675#discussion_r2333473293)
In d23116987d19587746d392895c06f5c426c1d0d2 "test: Test MuSig2 in the wallet"

Can also add the below test case that works right away where the musig is in both the key path spend and the script path spend - KP has all 3 keys in the musig, SP scripts have 2 partial keys in their musig each.

```python
self.do_test("tr(musig/*,{pk(partial keys diff musig-1/*),pk(partial keys diff musig-2/*)})}", "tr(musig($0,$1,$2)/<3;4>/*,{pk(musig($0,$1)/<5;6>/*),pk(musig($1,$2)/7/*)})")
```

💬 instagibbs commented on issue "Difficulty in reliably mapping errors from Bitcoin Core due to unstable error codes and messages":
(https://github.com/bitcoin/bitcoin/issues/33350#issuecomment-3270872088)
Is there a easy to read table somewhere on how you are interpreting and using specific error codes / msgs and how your software is intended to respond to them? This seems like an twice a year issue, and as far as I know no one else is using the errors for non-debugging reasons, or they're too shy to complain about the breaks.