32.0 testing #36315

1. 
   sedited commented at 4:06 PM on September 22, 2026: contributor

   Umbrella issue for 32.0 testing. Please help testing on a wide variety of supported platforms, as well as interaction with different software.

   Let us know which version you tested on which operating system.

   If you find an issue, please search Github for known issues first and then open a new Github issue.

   This meta issue should not be used to report bugs, as a single thread makes it impossible to track more than one topic.

   See 32.0 Release Notes Draft for a list of changes.

   See here for the testing guide: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/32.0-Release-Candidate-Testing-Guide

2. fanquake added this to the milestone 32.0 on Sep 23, 2026
3. 
   willcl-ark commented at 7:10 AM on September 25, 2026: member

   Did some light testing on NixOS with various other software connected. Opened #36334 to discuss some new frequently-hit log lines with electrs.

   Have not run through the testing guide (yet).

4. 
   janb84 commented at 1:13 PM on September 25, 2026: contributor

   EDIT: never mind, had an old(er) node running that didn't properly stopped.

   ~While working on the testing guide I discovered that the getopenrpcinfo command returns the wrong version (in the info field) :~

   bcli32 --version
   Bitcoin Core RPC client version v32.0rc2
   Copyright (C) 2009-2026 The Bitcoin Core developers
   
   Please contribute if you find Bitcoin Core useful. Visit
   <https://bitcoincore.org/> for further information about the software.
   The source code is available from <https://github.com/bitcoin/bitcoin>.
   
   This is experimental software.
   Distributed under the MIT software license, see the accompanying file COPYING
   or <https://opensource.org/license/MIT>
   
   bcli32 getopenrpcinfo | jq .info
   {
     "title": "Bitcoin Core JSON-RPC",
     "version": "v32.0.0rc1",
     "description": "Autogenerated from Bitcoin Core RPC metadata."
   }
   

5. 
   sedited commented at 1:29 PM on September 25, 2026: contributor

   Seems correct for me running the release binaries on aarch64 linux:

   $ ./bitcoin-cli -version
   Bitcoin Core RPC client version v32.0.0rc2
   ...
   $ ./bitcoin-cli getopenrpcinfo | jq .info
   {
     "title": "Bitcoin Core JSON-RPC",
     "version": "v32.0.0rc2",
     "description": "Autogenerated from Bitcoin Core RPC metadata."
   }
   

   Is this running the release binaries? And on which platform?

6. 
   mercie-ux commented at 5:06 AM on September 28, 2026: contributor

   Tested on Ubuntu 22.04 LTS, using x86_64 linux precompiled binaries. the guide's tests passed, including the advanced REST test, which returned the curl exit code 56 as expected.

7. 
   yuvicc commented at 8:36 AM on September 30, 2026: contributor

   Tested on MacOS Darwin 27.0.1 (arm64). Went through every step of the testing guide and all of them passed as expected. No issues found.

8. 
   kravens commented at 4:07 PM on September 30, 2026: none

   Tested v32.0rc2 on Arch Linux x86_64 (kernel 7.2, GCC 16.2.1, Python 3.14), focusing on the privacy features (Tor, I2P, private broadcast, silent payments). No regressions found.

   Verification and build

   • SHA256SUMS.asc: 10 good builder signatures, 0 bad; source and x86_64-linux-gnu tarball hashes match.
   • Built from source with depends (NO_QT=1). The only compiler warnings were 18 instances of a known GCC -Wstringop-overflow false positive in Boost multi_index headers.

   Test suites

   • ctest: 377/377 passed (script_assets_tests skipped: no assets file), including i2p_tests, torcontrol_tests, private_broadcast_tests, bip324_tests and the libsecp256k1 silentpayments BIP352 vectors. The release test_bitcoin also passes.
   • Functional --extended: all 304 scripts pass on the source build. I reran the previously skipped ones (previous releases, IPC, bench, chainstate) and they pass. feature_bind_port_* and rpc_bind.py --ipv4/--ipv6/--nonloopback also pass in a network namespace with 1.1.1.5 / 1111:1111::5 assigned.
   • Ran the full functional suite again against the release binaries (BITCOIND=...): all pass. The single failure on that run (rpc_getblockfrompeer.py) was caused by a port collision with a local i2pd SAM listener; it passes 3/3 on rerun.
   • Privacy subset (31 scripts: feature_proxy, feature_torcontrol, p2p_i2p_*, p2p_private_broadcast*, p2p_v2_*, addr relay, p2p_tx_privacy, rpc_net, ...) run 10 times: 310/310 passed, no intermittent failures.
   • Not run: USDT tests (need root), feature_utxo_abort_on_error (plyvel), GUI, fuzz.

   Live tests with release binaries (Tor 0.4.9.11, i2pd 2.61.0)

   • Mainnet node with -onlynet=onion -onlynet=i2p -listenonion -i2psam -i2pacceptincoming -privatebroadcast: 10 outbound peers (5 onion, 5 I2P), all using v2 transport. ADD_ONION successful (PoW defenses enabled) (#33414). A persistent I2P destination was created, and the onion service could be reached from outside. I sampled the node's TCP/UDP sockets every second for the whole run and saw only loopback connections to Tor SOCKS, the Tor control port and I2P SAM. No clearnet connections and no DNS.
   • Private broadcast end to end over the real networks: I ran two isolated regtest nodes. The receiver was reachable only through its .onion / .b32.i2p address, and I synced its chain with submitblock. sendrawtransaction on the sender delivered the tx over I2P, and in a second run over Tor (~9 s). The tx was not in the sender's mempool until it was received back. attempts_remaining went from 1000 to 999 (#35680). With -privatebroadcast disabled, getprivatebroadcastinfo returns -32601 (#35267).
   • I2P sessions still request i2cp.leaseSetEncType=4,0, consistent with the ElGamal sunset note (#35696).

   Observations (all already known or tracked)

   1. A transaction that is still in the private broadcast queue is silently dropped when the node restarts: it is in neither the mempool nor the queue afterwards. This is tracked in #34322, but neither the sendrawtransaction help text nor the release notes mention it. That may be worth a line in the notes, since the feature is new.
   2. #36312 (don't discourage private broadcast peers) and #36309 (clarify claims, mark as experimental) are milestoned for 32.0 but are not in rc2. They are pending in #36300, so I assume they will be in rc3.
   3. Release notes draft: the -privatebroadcast IP-leak fix entry cites #35319, which was closed unmerged. The fix was merged as #35410.
   4. Minor: when the only candidate address in addrman belongs to a peer the node already has a long-lived connection to, private broadcast refuses it (correct behavior) and retries about 10 times per second, logging a "Failed to connect" line each time. This only shows up in tiny test setups.
9. 
   jaonoctus commented at 9:00 AM on October 4, 2026: none

   Tested v32.0rc2 on macOS 26.6.2 arm64, built from source. Ran through the whole testing guide (1.1 to 4.1) and everything passed as expected, except the advanced rpcallowip test in 4.1, which I couldn't complete in my environment.

10. 
    danieldzansi commented at 11:53 PM on October 7, 2026: none

    Tested on Ubuntu 24.04.4 LTS, x86_64 (Linux 7.0.0-34-generic), built from source with GCC 13.3.0 and -DENABLE_IPC=OFF All functionality passed as expected . The official interface_http.py test passed . CTest :373 passed ,0 failed ,1 skipped (script_assets_tests due to DIR_UNIT_TEST_DATA being unset ). GUI, IPC, ZeroMq, USDT, QR, and DBus were not tested. no Bitcoin Core bug was found .

11. 
    l0rinc commented at 1:46 AM on October 10, 2026: contributor

    Ran a debug-build (runs more checks and is a lot slower) pruned IBD on rc2 (bc795e60dbb2c6e9c9556949731912429290626a) with full validation (assumevalid=0) - finished successfully in 3.5 days.

12. 
    ViniciusCestarii commented at 12:10 AM on October 15, 2026: contributor

    With #33671 anything that treats trusted as the spendable amount now overstates funds while a non-mempool tx exists.

    So I believe it is good to explicitly state that behavior change to the release note too, something like:

    "As a result, coins spent by such transactions are now counted in trusted, untrusted_pending, immature and used (previously they were excluded), so these fields can be higher than in previous versions for the same wallet state. Use getbalance for the currently spendable amount."

    Unrelated but: what's the right way to propose a change to the 32.0 release notes draft? The wiki isn't editable without permission, and doc/developer-notes.md#release-notes doesn't describe that case.

    cc @ajtowns

13. 
    kravens commented at 2:27 PM on October 17, 2026: none

    Tested v32.0rc4 on Arch Linux x86_64 (kernel 7.2, GCC 16.2.1, Python 3.14), repeating my rc2 run above with the same privacy focus (Tor, I2P, private broadcast, silent payments). No regressions found. The rc3/rc4 private broadcast changes (#36277, #36312, #36309) behave as described; two of my rc2 observations still apply.

    Verification and build

    • SHA256SUMS.asc: 10 good builder signatures, 0 bad; source and x86_64-linux-gnu tarball hashes match.
    • Built from source with depends (NO_QT=1, same depends recipes as rc2). Same 18 instances of the known GCC -Wstringop-overflow false positive in Boost multi_index headers, nothing else.

    Test suites

    • ctest: 377/377 passed (script_assets_tests skipped), including i2p_tests, torcontrol_tests, private_broadcast_tests, denialofservice_tests (covers #36312), bip324_tests and the libsecp256k1 silentpayments BIP352 vectors.
    • Functional --extended on the source build: 487 passed, 9 skipped (USDT, plyvel, GUI, bind tests), 1 failed. The failure, feature_anchors.py, is a test artifact of the non-default TEST_RUNNER_PORT_MIN=1100 I used to avoid colliding with the local Tor/I2P ports: the test builds the expected anchors.dat substring with hex(port)[2:], which is not zero-padded for ports below 4096. It passes at the default port range.
    • Functional --extended against the release binaries (BITCOIND=...): 486 passed, 2 failed on port collisions with unrelated local listeners (rpc_bind.py --ipv4: "Unable to start HTTP server"; p2p_i2p_ports.py: its placeholder proxy port was in use). Both pass on rerun, together with rpc_bind.py --ipv6/--nonloopback, p2p_i2p_sessions.py and rpc_getblockfrompeer.py.
    • feature_bind_port_externalip, feature_bind_port_discover and rpc_bind.py --ipv4/--ipv6/--nonloopback pass in a network namespace with 1.1.1.5 / 1111:1111::5 assigned.
    • Privacy subset (32 scripts: feature_proxy, feature_torcontrol, p2p_i2p_*, p2p_private_broadcast* including the new p2p_private_broadcast_completion.py, p2p_v2_*, addr relay, p2p_tx_privacy, rpc_net, ...) run 10 times: 330/330 passed, no intermittent failures.
    • Fuzz (clang 22, libFuzzer + ASan/UBSan, BUILD_FOR_FUZZING=ON): replayed the qa-assets corpora for 15 network/privacy targets (i2p, torcontrol, socks5, private_broadcast, p2p_private_broadcast, p2p_transport_*, bip324_*, netaddress, netaddr_deserialize, addrman, p2p_handshake) without errors, then ran each for 8 minutes: no crashes or sanitizer reports.
    • Not run: USDT tests (need root), feature_utxo_abort_on_error (plyvel), GUI.

    Live tests with release binaries (Tor 0.4.9.11, i2pd 2.61.0)

    • Mainnet node with -onlynet=onion -onlynet=i2p -listenonion -i2psam -i2pacceptincoming -privatebroadcast, reusing the rc2 datadir: the same onion address and persistent I2P destination came back, ADD_ONION successful (PoW defenses enabled), and the onion service was reachable through Tor. 10 outbound peers (8 I2P, 2 onion), all v2 transport. Sampling the node's TCP/UDP sockets every second for 41 minutes showed only loopback connections to Tor SOCKS, the Tor control port and I2P SAM. No clearnet connections, no DNS.
    • Private broadcast end to end over the real networks, two isolated regtest nodes as in rc2 (receiver reachable only via .onion / .b32.i2p, chain synced with submitblock): delivered over I2P in 72 s and, in a Tor-only run, over Tor in 10 s. The tx is not in the sender's mempool until it is received back; attempts_remaining 1000 -> 999; the sender's only sockets were loopback to Tor SOCKS / I2P SAM. -privatebroadcast and sendrawtransaction help now say EXPERIMENTAL (#36309); getprivatebroadcastinfo still returns -32601 when the option is off.
    • I2P sessions still request i2cp.leaseSetEncType=4,0 (ElGamal sunset note, #35696).

    Observations

    1. Still true in rc4: a transaction that is still in the private broadcast queue is silently dropped on restart (queue and mempool are both empty afterwards; mempool.dat import reports 0). Tracked in #34322, still not mentioned in the sendrawtransaction help or the release notes draft.
    2. New with #36277: after the transaction has been received back (it disappears from getprivatebroadcastinfo), the node keeps trying to open the remaining initial connections, as intended. When every candidate address already has a long-lived connection, that becomes a tight loop with no end condition: ~600 "Failed to connect ... will retry to a different address" log lines per minute (10/s), no SOCKS/SAM attempts, ~2% CPU, for as long as I watched (5 min, both in the one-address and in the two-address setup). rc2 stopped the loop once the tx came back. This only matters for tiny setups or -onlynet nodes with very few usable addresses, but a backoff would avoid the log spam.
    3. Release notes draft: the -privatebroadcast IP-leak fix entry still cites #35319 (closed unmerged); the fix was merged as #35410. The draft also does not say that private broadcast is experimental, although -help and the sendrawtransaction help do since #36309.
    4. Harness note for other testers: the onion service's virtual port is the chain's default port (Params().GetDefaultPort(), 18444 on regtest), not -port. Connecting to <onion>:<-port> fails with "No virtual port mapping exists" in Tor's log.

Milestone
32.0