Bitcoin Core merged a rule change on Oct. 22 that opens a faster lane for vulnerability fixes: a flaw judged easy for attackers to find again can now be patched across every maintained release line at once, with an advisory published as each fix lands. The change comes as a network snapshot from the Karlsruhe Institute of Technology (KIT) shows 43.6% of sampled public Bitcoin Core peers running versions that no longer receive patches.
Under the new rule, developers can classify a flaw at triage, judging how readily it can be turned up again, including with the help of large language models. Bitcoin Core developer Antoine Poinsot announced the change on the bitcoindev mailing list in the merged pull request updating the project’s security policy. He argued the old embargo achieves little while it delays the availability of a fixed release. The trade-off he flagged is that mitigations get less time to prove themselves on development branches. As of Oct. 23, the new category had not yet been applied publicly to any specific bug.
The change ends a policy that held medium- and high-severity bug details until two weeks past the end of life of the last affected release, a span that could stretch close to a year. Embargo, the period during which vulnerability details stay withheld until fixed releases are widely deployed, has relied on bugs being hard to rediscover. AI tools weaken that assumption, so long silences now delay fixes more than they protect operators.
How the old policy played out
The project’s practice is visible in the disclosure of CVE-2024-52911. The high-severity use-after-free in block validation, which affected versions later than 0.14.0 and earlier than 29.0 and let a crafted invalid block crash a node, was reported in November 2024, fixed in 29.0 in April 2025 and disclosed on May 5, 2026, about 388 days after the fix. The pattern continues: the 32.0 release notes state that three medium- or high-severity flaws corrected in version 30.0 stay under wraps until two weeks after the new version ships.
The unsupported share
Bitcoin Core maintains only its three newest major release lines, currently 29.x, 30.x and 31.x. The KIT snapshot from Oct. 18 counted 3,671 of 8,422 self-reported Bitcoin Core peers on lines already past end of life, with the rest on 31.x (3,243), 30.x (712) and 29.x (635). The count covers public IPv4 and IPv6 peers only, so Tor-only nodes, non-listening nodes and privately run exchange, custodian and miner infrastructure fall outside it. Readers who want the basics can start with what crypto nodes are and how they work.
The share is set to grow. When version 32.0 ships, 29.x leaves the maintenance window, and a projection from the snapshot puts 4,306 of the 8,422 peers, or 51.1%, on unsupported lines if the sample stayed unchanged. The project’s life cycle page still listed the 32.0 release date as TBA as of Oct. 24, with only release candidates in the download directory.
Core 32.0 also switches the default partially signed Bitcoin transaction format from version 0 to version 2, which matters for multisig setups mixing old and new nodes. Because Bitcoin has no central authority to force upgrades, network security depends on operators choosing to update.
Bitcoin Core merged a rule change on Oct. 22 that opens a faster lane for vulnerability fixes: a flaw judged easy for attackers to find again can now be patched across every maintained release line at once, with an advisory published as each fix lands. The change comes as a network snapshot from the Karlsruhe Institute of Technology (KIT) shows 43.6% of sampled public Bitcoin Core peers running versions that no longer receive patches.
Under the new rule, developers can classify a flaw at triage, judging how readily it can be turned up again, including with the help of large language models. Bitcoin Core developer Antoine Poinsot announced the change on the bitcoindev mailing list in the merged pull request updating the project’s security policy. He argued the old embargo achieves little while it delays the availability of a fixed release. The trade-off he flagged is that mitigations get less time to prove themselves on development branches. As of Oct. 23, the new category had not yet been applied publicly to any specific bug.
The change ends a policy that held medium- and high-severity bug details until two weeks past the end of life of the last affected release, a span that could stretch close to a year. Embargo, the period during which vulnerability details stay withheld until fixed releases are widely deployed, has relied on bugs being hard to rediscover. AI tools weaken that assumption, so long silences now delay fixes more than they protect operators.
How the old policy played out
The project’s practice is visible in the disclosure of CVE-2024-52911. The high-severity use-after-free in block validation, which affected versions later than 0.14.0 and earlier than 29.0 and let a crafted invalid block crash a node, was reported in November 2024, fixed in 29.0 in April 2025 and disclosed on May 5, 2026, about 388 days after the fix. The pattern continues: the 32.0 release notes state that three medium- or high-severity flaws corrected in version 30.0 stay under wraps until two weeks after the new version ships.
The unsupported share
Bitcoin Core maintains only its three newest major release lines, currently 29.x, 30.x and 31.x. The KIT snapshot from Oct. 18 counted 3,671 of 8,422 self-reported Bitcoin Core peers on lines already past end of life, with the rest on 31.x (3,243), 30.x (712) and 29.x (635). The count covers public IPv4 and IPv6 peers only, so Tor-only nodes, non-listening nodes and privately run exchange, custodian and miner infrastructure fall outside it. Readers who want the basics can start with what crypto nodes are and how they work.
The share is set to grow. When version 32.0 ships, 29.x leaves the maintenance window, and a projection from the snapshot puts 4,306 of the 8,422 peers, or 51.1%, on unsupported lines if the sample stayed unchanged. The project’s life cycle page still listed the 32.0 release date as TBA as of Oct. 24, with only release candidates in the download directory.
Core 32.0 also switches the default partially signed Bitcoin transaction format from version 0 to version 2, which matters for multisig setups mixing old and new nodes. Because Bitcoin has no central authority to force upgrades, network security depends on operators choosing to update.
