Testing Bitcoin Core 31.0 Release Candidates (tests )
Apr 8, 2026
Host:
svanstaa
PR author: svanstaa
Notes
Major versions of Bitcoin Core are released every 6-8 months. See the Life
Cycle documentation for full details.
When all of the PRs for a release have been merged, Release Candidate 1
(rc1) is tagged. The rc is then tested. If any issues are found, fixes are
merged into the branch and a new rc is tagged. This continues until no major
issues are found in an rc, and that rc is then considered to be the final
release version.
To ensure that users don’t experience issues with the new software, it’s
essential that the rcs are thoroughly tested. This special review club
meeting is for people who want to help with that vital review process.
This Bitcoin Core Release Candidate Testing
Guide provides guidance for testing the release candidate.
The guide is just to get you started on testing, so feel free to read the Release Notes
and bring ideas of other things you’d like to test!
Meeting Log
1 17:00 <svanstaa> #startmeeting
2 17:00 <corebot`> svanstaa: Meeting started at 2026-04-08T17:00+0000
3 17:00 <corebot`> svanstaa: Current chairs: svanstaa
4 17:00 <corebot`> svanstaa: Useful commands: #action #info #idea #link #topic #motion #vote #close #endmeeting
6 17:00 <corebot`> svanstaa: Participants should now identify themselves with '#here' or with an alias like '#here FirstLast'
8 17:00 <svanstaa> Hi everyone, and welcome to the Bitcoin Core Review Club, today about the 31.0 Release Testing Guide!
9 17:00 <svanstaa> Thanks you for joining. Even if you are here for the first time, feel free to say hi!
10 17:00 <itamar30> Hi, first time ever...
12 17:00 <marcofleon> woo!
13 17:00 <sdmg15> Hi, first time :)
14 17:01 <carloantinarella> Hello everyone!
15 17:01 <svanstaa> Great!
16 17:01 <svanstaa> Also, do not ask for permission to speak, just speak up :)
19 17:03 <svanstaa> @sdmg15 that is an innovative way to go about it
20 17:04 <svanstaa> Lets go through this chapter by chapter
22 17:05 <svanstaa> Who had issus or comments on building the client, and setting up the test environment?
23 17:05 <svanstaa> *issues
24 17:06 <marcofleon> The steps were laid out clearly for me, nicely done svanstaa
25 17:07 <carloantinarella> I only tried compiling from source, no issues whatsoever
26 17:07 <svanstaa> Great! Ok, lets look at 1. Mempool
27 17:08 <svanstaa> Who did the test? Any issues or peculiar observations?
28 17:09 <sdmg15> I think the 1.3 Cluster mempool: Cluster Limits Enforcement is the one I struggled testing
29 17:09 <svanstaa> Why did we set up the child txn with a higher fee than the parent?
30 17:09 <svanstaa> @sdmg15. where did you get stuck?
31 17:10 <svanstaa> (this was the tricky one, I admit)
32 17:10 <sdmg15> The issue was just that I created a script.sh and then had to export the aliase commands :)
33 17:10 <janb84> sdmg15: didn't a simple copy and paste didn't work ?
34 17:11 <sdmg15> Haven't tried copy-pasting, since the script was long I just thought I should put it in a file
35 17:12 <svanstaa> Did it show expected behaviour then?
36 17:13 <sdmg15> Yes I saw the expected behavior, in my recording too. thanks for the instructions.
37 17:13 <carloantinarella> I also had similar issue with aliases. Aliases are lost if you execute as a separate script. I sourced it instead and it worked fine
38 17:13 <itamar30> I first tried copy and paste, but the program stopped and my terminal closed
39 17:14 <janb84> ok lessens learned for the next guide :) tnx all
41 17:14 <marcofleon> Child txn had a higher fee than the parent to ensure they were merged as a single chunk
42 17:15 <svanstaa> @marcofleon correct!
43 17:15 <marcofleon> Hoping my terminology is correct...
44 17:15 <svanstaa> @janb84 yes we will keep the test cases simpler next time
45 17:16 <svanstaa> on to the next one: 2. private broadcast
46 17:16 <svanstaa> What was this about?
47 17:17 <svanstaa> Quick summary, and observed behaviour?
48 17:18 <sdmg15> From my understanding it's help people broadcast transaction over secured networks like Tor and I2P
49 17:19 <sdmg15> And you could enforce that to your client by enabling the option
50 17:20 <svanstaa> Correct. How did we test this? It was not the straightforward way
51 17:21 <svanstaa> That would have been to install and sent out a private transaction on testnet, but we deemed that out of scope for this tutorial
52 17:22 <svanstaa> Cheap solution: just test that the client refuses to sent out any transaction when TOR/I2P is not present while -privatebroadcast is set :)
53 17:23 <svanstaa> Next topic Updated RPCs
54 17:23 <marcofleon> Good call for the private broadcast test
55 17:23 <marcofleon> Is it even a thing to connect over tor for regtest? Not sure if i've ever tried that
56 17:24 <marcofleon> Just a local chain, so wouldn't really make sense
57 17:24 <svanstaa> @marcofleon yes, it would have needed running testnet as well
58 17:25 <svanstaa> AFAIK, that wouldnt work on regtest
59 17:25 <svanstaa> that's why we left that out
60 17:26 <svanstaa> who ran the test of the updated getblock RPC?
62 17:28 <marcofleon> I've given it a try on mainnet
63 17:29 <svanstaa> Nice. Bonus question: why was output of the coinbase_tx object added at logging verbosity level 1?
64 17:31 <janb84> Miners ?
65 17:31 <sdmg15> I don't know what BIP54 is all about, but from the PR it helps making the scan faster?
66 17:31 <marcofleon> at higher verbosities you would just see the full coinbase tx right?
67 17:31 <marcofleon> so it made sense to add at level 1 I think
68 17:32 <svanstaa> It said so in the linked PR#34512: making it easier to check for BIP54 compliance, without an overhead of logging messages
69 17:32 <corebot`> svanstaa: Error: That URL raised <HTTP Error 404: Not Found>
70 17:32 <marcofleon> ah nice
71 17:32 <marcofleon> #34512
73 17:32 <svanstaa> @marcofleon yes correct, at level 2 too much output of stuff you don'T need for that use case
74 17:33 <svanstaa> @sdmg15 BIP54 is also known as The Great consensus Cleanup. It is a soft fork that solves 4 known bugs
75 17:35 <svanstaa> Looking at the coinbase transaction can identify if the block is BIP54 compliant
76 17:35 <svanstaa> Next chapter 4. txospenderindex
77 17:35 <marcofleon> Last I heard it's just Consensus Cleanup these days. But still great to me at least
78 17:36 <svanstaa> @marcofleon haha, was it renamed? Didnt notice. I thinnk Consensus cleanup works just as well :)
79 17:37 <svanstaa> Who tried activating -txospenderindex? What is it good for?
80 17:38 <carloantinarella> -txospenderindex should be good for second layer protocols. Also in this case motivation is clearly explained in the PR introducing it
81 17:38 <sdmg15> The PR is from 2022 wow
82 17:39 <svanstaa> @carloantir . yes, correct. As it should be in any good PR :)
83 17:39 <marcofleon> only took four years 😅
84 17:40 <svanstaa> move slow and don't break things :)
85 17:41 <marcofleon> The index keeps track of which txs spent which outpoints yes?
86 17:41 <svanstaa> yes, correct
87 17:42 <marcofleon> I've been syncing it for the last couple hours on my node :)
88 17:42 <marcofleon> only 300k blocks to go
89 17:42 <svanstaa> Nice, it can take a few hours
90 17:43 <svanstaa> who has it synced completely already?
91 17:43 <carloantinarella> Is it independent from -txindex?
92 17:44 <svanstaa> @carloantir yes, that is a different index. You can both on and off independently from each other
93 17:44 <svanstaa> *turn both
94 17:45 <svanstaa> (ok, this was a trick question, as syncing the txospenderindex is a prerequisite for running the tests)
95 17:45 <svanstaa> should have warned earlier that this is best run overnight :)
96 17:46 <svanstaa> ok, on to section 5: Settings
97 17:46 <svanstaa> who fiddled with the dbcache settings? What is it for anyway?
98 17:48 <carloantinarella> I think this is an update due to the fact that more than 4096 MiB of RAM is now very common
99 17:49 <janb84> carloantinarella: that has been quite a debate, if having more ram is common ;)
100 17:49 <svanstaa> @carloantir Yes, correct. The 450MB size has been around for many years, hardware has advanced
101 17:49 <carloantinarella> I love debates, but I lost this one '=D
102 17:50 <svanstaa> Any unusual or unexpected behaviour observed here?
103 17:51 <marcofleon> the new default is 1024?
104 17:51 <svanstaa> yes, correct
106 17:52 <marcofleon> I'm not sure what's optimal, but I'll usually set dbcache to half my ram for ibd, and then set it to 1024 (even before this update)
107 17:52 <corebot`> svanstaa: Error: That URL raised <HTTP Error 404: Not Found>
108 17:53 <svanstaa> @marcofleon those look like sensible values
109 17:54 <svanstaa> who tried the -asmap option in 5.2? What does it change?
110 17:55 <sdmg15> I struggle understanding what are asmaps useful for but yeah I did run the tests
111 17:55 <svanstaa> The main reason in too make eclipse attacks more difficult
112 17:57 <svanstaa> If you chose your peers wisely (from all different corner of the web), it will become impossible for an attacker to eclipse you by spinning up hundreds of malicious nodes on e.g. AWS
113 17:57 <sdmg15> Oh I see interesting
114 17:58 <sipa> sdmg15: it's basically a "map of the internet", with information about what organizations (ISPs, hosting providers, companies, ...) control which ranges of IP addresses. By being aware of this information, Bitcoin Core can bias its connection making in a way such that the connections are to diverse sets of organizations, making it harder for a single one or a small number from dominating all
115 17:58 <sipa> information you see
116 17:58 <svanstaa> It has now become a more permanent feature, with the ASMAP data collected for that release baked into the binaries
117 17:59 <sdmg15> It's clear now thanks.
118 17:59 <carloantinarella> Does it also speed up txs propagation over the network because of geographical diversity?
119 18:00 <svanstaa> @carloantir that also seems possible, but not completely sure
120 18:00 <svanstaa> maybe @fjahr can chime in later
121 18:01 <sipa> carloantinarella: unlikely, i think; propagation speed is dominated by the few fastest connections you have
122 18:01 <svanstaa> @sipa thanks for clarification!
123 18:01 <sipa> and in general, eclipse resistance is in conflict with propagation speed - for fast propagation you ideally want few connections to the fastest nodes possible, rather than many diverse ones
124 18:02 <svanstaa> That's it for today. Thaks you all for joining. Of course you can continue to discuss here, I will come back later to check for open questions
125 18:02 <svanstaa> #endmeeting