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.
It is recommended to go through the “Preparation” steps ahead of the meeting, especially if you want to compile from source. Verify and confirm the successful installation of v27rc1, as well as v25.1 and v26 (older versions are used in some of the tests). BDB support is required in one of the tests.
The testing guide relies on the tools jq which are not installed by default on each platform. For example on macOS, you can install these ahead of time using brew install. Alternatively, you can also modify the instructions to avoid using these tools as they are not strictly necessary and/or can be replaced by other tools.
For some of the tests, you might want to have the signet chain fully synced beforehand, so that you can just copy the signet directory into /tmp/27-rc-test/ every time you run a test in a fresh environment.
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!
<cbergqvist> For newcomers (and just as a reminder), its encouraged to just blurt out questions! No need to ask for permission first or worry about if you're interrupting another question.
<cbergqvist> First though, could you please share which OS you're using and whether you have/are compiling from source using tags/v27.0rc1 or only using pre-compiled binaries?
<cbergqvist> Most of the individual changes are well tested during the review phase, when the code is introduced to the codebase. What's more complicated to test is how changes behave together on different configurations and user patterns. Therefore it's encouraged to do your own testing and experiments. Testing on Mainnet is encouraged when possible.
<cbergqvist> This change makes it less likely for antivirus software to quarantine your mempool.dat file if a malicious transaction containing byte patterns classified as a virus enters your mempool.
<stickies-v> FYI when chaining commands after starting bitcoind, you can use `-daemonwait` instead of `-daemon` so the command doesn't return until the node is ready to be used, which is useful e.g. in the mempool v1/v2 tests
<stickies-v> Guest86: this is about dumping your mempool to disk, so it would only affect stuff that's in your mempool, and not the stuff you're filtering out through policy, because it doesn't get into your mempool
<cbergqvist> Guest86: if you reject OP_RETURN data it will probably not get into your mempool.dat to be XORed, no. But there may be other ways of inscribing data..
<dzxzg> The v2 seednode won't necessarily gossip v2 peers to you, but you can inspect debug.log to see that the `addrfetch` connection was made over v2
<cbergqvist> v26 nodes do support v2, but it's not enabled by default as I understand it. Will they reject v2 attempt by default, or is it just that they will try v1 first when initiating?
<lightlike> cbergqvist: v26 nodes only support v2 connections if they are started with the -v2transport option. If that option isn't used, they will reject v2 connections.
<cbergqvist> just tested with what dzxzg suggested + rm ~/.bitcoin/peers.dat + anchors.dat, started bitcoind, then used bitcoin-cli addnode bitcoin.achow101.com add