v31.0 Testing #34840

1. 
   fanquake commented at 9:05 am on March 17, 2026: member

   Umbrella issue for 31.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 31.0 Release Notes Draft for a list of changes.

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

2. fanquake added this to the milestone 31.0 on Mar 17, 2026
3. fanquake pinned this on Mar 17, 2026
4. 
   fanquake commented at 9:06 am on March 17, 2026: member

   v31.0rc1 bins are availalble here: https://bitcoincore.org/bin/bitcoin-core-31.0/test.rc1/.
5. fanquake added the label Tracking Issue on Mar 19, 2026
6. 
   l0rinc commented at 11:37 am on March 19, 2026: contributor

   Tested private broadcast with the follow-up debug logging and RPC queue inspection across multiple transactions on mainnet.

   One of them completed in ~30s: requested 3 connections, one onion failed and retried, two peers connected (v2 + v1), both received the INV and PONGed back, then the tx was received back from the network via a regular peer - stopping private broadcast. A third connection that completed after the tx was already confirmed was correctly disconnected as “connected in vain”. RPC showed the tx in the queue after sendrawtransaction, present during retries, and cleared once received back from mempool.

7. 
   enirox001 commented at 9:51 am on March 22, 2026: contributor

   Tested on Fedora x86_64, compiled from source, v31.0rc1.

   All guide tests passed as expected. I went beyond the guide and tested cluster mempool with longer tx chains, mixed fee rates, and submission order, all behaved correctly, cluster rejected at tx 65 with too-large-cluster as expected.

   Private broadcast behaved correctly in all scenarios including getprivatebroadcastinfo and abortprivatebroadcast.

   For coinbase_tx I tested across all verbosity levels, confirmed the field matches the actual first transaction in the block, and verified the block height encoding in the coinbase hex. One thing worth flagging is that getblock returns coinbase_tx.witness as a string while getrawtransaction returns the same data via vin[0].txinwitness as an array. Same data, inconsistent types. May be intentional given the simplified nature of coinbase_tx but thought it was worth mentioning.

Contributors
fanquake l0rinc enirox001

Labels
Tracking Issue

Milestone
31.0