Bitcoin Core v30: a deeper look
What is in Bitcoin Core v30? One way to answer this is to review the release notes and discuss features. A few contributors have already done this already and I'll point to their summaries. But another angle is to look at all of the PRs and categorize them based on their labels…
As I mentioned, @Murch already did about 40 minutes describing at a high level Bitcoin v30 changes in Bitcoin Optech Podcast #372 (bitcoinops.org/en/podcast/202) and again with @The Bitcoin Historian (youtube.com/watch?v=EUHc5Q)
You can also review the v30 release notes here: github.com/bitcoin/bitcoi
We will take a closer look at the Bitcoin Core Github activity associated with those changes…
My analysis (methodology outlined below) shows 577 PRs merged for Bitcoin Core v30.
Why are there so many ongoing changes to Bitcoin Core?
Even a conservative, security-focused project like Bitcoin Core has maintenance work and testing that needs to be done. Looking at the Github PR labels, a way of categorizing the type of change being proposed, we see these top 10 labels and the number of PRs in v30 of that type.
Tests: 181
Build system: 70
Docs: 70
Wallet: 41
Refactoring: 27
P2P: 18
Utils/log/libs: 18
RPC/REST/ZMQ: 17
Windows: 16
GUI: 14
…
Here is a selection of code changes from the ‘Tests’ label that update existing tests or add further tests that dominate the PR counts in v30.
In addition to a generally better tested node software, many of these changes specifically enhance Bitcoin Core’s fuzz testing coverage in order to proactively find bugs in the software.
See: brink.dev/blog/2023/07/1
Build systems updates that ensure the software can be built on a variety of platforms as well as be built deterministically are the second most common PR in v30.
Several of these updates around Bitcoin Core’s move to CMake, a more modern build system. See: bitcoinops.org/en/newsletters
Other of these PRs helped enable a multi-process Bitcoin Core, which for v30, means Stratum v2 and the mining decentralization benefits that brings, is more easily supported in Bitcoin Core.
See: bitcoinops.org/en/newsletters
Also of note are the changes around the project’s dependencies. Managing and minimizing dependencies in Bitcoin Core is critical from a security perspective. See: brink.dev/blog/2025/09/1
Documenting the software for end users, RPC users, and developers was the third most popular PR.
Policy-related PRs were the 17th most common type of PR in v30. These include the OP_RETURN default limit change PR but also changes around minimum relay fee rates to adapt to changing Bitcoin network activity with sub 1 sat/vbyte transactions being regularly mined.
Bitcoin Core #32521 makes legacy transactions with more than 2500 signature operations (sigops) non-standard, helping mitigate known problems in the validation of legacy (pre-segwit) transactions
See: bitcoinops.org/en/newsletters
Bitcoin Core #31385 (and Bitcoin Core #31829 from the “p2p” label and others) improves 1P1C package relay usage, part of broader initiatives to significantly increase the security of the Lightning Network.
See: bitcoinops.org/en/bitcoin-cor
See: github.com/bitcoin/bitcoi
Bitcoin Core v30 also celebrates the completion of the wallet migration project. This 5 year project modernizes Bitcoin Core’s wallet to use descriptor wallets and support all of the end user benefits that come along with that.
See all of the PRs over the past 5 years to achieve this milestone: github.com/bitcoin/bitcoi
Something that didn't make the v30 release notes were the improvements to IBD. v30 is 20% faster than v29. v30 is also 2x faster than Bitcoin Core v25 and 2.5x faster than Bitcoin Core v23.
x.com/l0rinc/status/
l0rinc@L0RINC
Sep 24 25
View on Twitter
I exported the list of Bitcoin Core v30 PRs for readers to take a look. docs.google.com/spreadsheets/d
Code review stats around Bitcoin Core v30:
16,353 total review comments on v30-related code changes.
The above PRs averaged 28 review comments each.
497 review comments for a single PR was on the high end (for #31829 - p2p: improve TxOrphanage denial of service bounds)
How long was a Bitcoin Core v30 PR open, on average, before being merged?
About 41 days.
When accounting for trivial PRs (like CI fixes or small documentation changes), that number jumps to nearly 60 days.
Of course Bitcoiners will argue about policy defaults, and we should. There has been much conversation about Bitcoin Core changing of the OP_RETURN default value in PR #32406.
Whether you disagree with that change or are supportive of it, these other changes are additive. You can disagree with the OP_RETURN change AND still recognize these changes, which will likely be made in Bitcoin Core derived node implementations like Knots, Libre Relay, and others, and thus be present on most of the nodes on the network eventually.
There is a lot more work going on in Bitcoin Core than OP_RETURN. Work that will benefit node runners whether you’re running Bitcoin Core or Knots or Libre Relay. Work to harden testing of the software, work to improve IBD, wallet improvements, improvements to support Lightning, and work to make sure we can even build the software to begin with. Long review cycles with lots of review comments.
Congratulations to all contributors that helped make this release possible.
Methodology:
I got a list of all the merges different between Bitcoin Core v29.1 and Bitcoin Core v30.0 release candidate 2:
git log v29.1..v30.0 --first-parent --merges --pretty='%s' | sed -nE 's/.*#([0-9]+)[^:]*: (.*)$/\1,"\2"/p'
With that list of PR numbers, I used @b10c’s Bitcoin/Bitcoin metadata repository to supplement with Github information in a python script:
github.com/bitcoin-data/g
Feedback welcome.
Schmidty
@bitschmidty
Funding Bitcoin node security, testing, and maintenance @bitcoinbrink
Blocking and tackling at @bitcoinoptech
Missing some tweets in this thread? Or failed to load images or videos? You can try to .