Bitcoin Core has disclosed a repaired flaw that let a mining node keep running, keep its peers and keep syncing while quietly losing the ability to build new blocks.
Key Takeaways
- Chain reorganizations could corrupt the mempool on affected nodes.
- Affected: Bitcoin Core 28.0-28.2 and 29.0-29.1.
- Fix shipped October 2025; details published November 2026.
- Restart cleared the state; upgrading removed the bug.
The official disclosure of CVE-2025-62861 rates the issue high severity, credits Niklas Goegge with reporting it, and traces it to a transaction-relay rule that fired at the wrong moment: during a chain reorganization, when it should have stayed silent.
The advisory names no outage and no affected operator; the exposure is historical. Mining hardware pointed at a node in this state would have kept hashing, but on the last template it received, so new transactions and their fees would have gone unclaimed until someone noticed. What follows is how a node reached that state, what the operator would have seen, and why the full explanation arrived only now.
How a reorganization can orphan a transaction
A reorganization happens when a node abandons its current chain tip for a competing, heavier branch. The transactions in the blocks it just disconnected are still valid, so Bitcoin Core puts them back into its mempool, the holding area for unconfirmed transactions. Because those transactions were already confirmed in a valid block, the node re-adds them with a flag called bypass_limits that switches off the usual anti-spam and topology checks. The point is to restore the pool faithfully, not to re-judge transactions that have already passed consensus.
One of the checks that should have been switched off concerns version-three, or TRUC, transactions. Under BIP 431, a TRUC transaction may have at most one unconfirmed parent and one unconfirmed child. That is a relay policy, not a consensus rule: a block can legitimately contain a TRUC parent with several children, even though no node would accept that shape into its mempool from the network.
Since version 28.0, Bitcoin Core has enforced the one-child limit with a mechanism called sibling eviction. When a new transaction would give a TRUC parent a second unconfirmed child, the node treats the existing child as a replacement candidate and, if the newcomer pays enough, evicts it under replace-by-fee rules.
The bug was that sibling eviction ran even when bypass_limits was set. A reorg that restored a TRUC parent with multiple children, perfectly valid in the disconnected block, could trigger eviction of one restored transaction while leaving transactions that spent its outputs in the pool. The mempool now held children whose parent no longer existed anywhere: not in the chain, not in the pool.
Greg Sanders’ fix gated the TRUC checks on bypass_limits, so eviction no longer runs during reorg restoration. The pull request also added the test scenario the original code lacked: transactions arriving from disconnected blocks rather than from peers.
What a stalled template looks like from the mining side
A node hands work to mining software through getblocktemplate, which assembles a candidate block, runs it through the node’s own validity check and returns the previous block hash, the chosen transactions and the next height. With a parentless transaction in the pool, the assembled candidate failed that check, so the call could not return fresh work.
Reported as healthy
Process running
Peer connections open
Chain tip advancing
Mempool accepting new transactions
Actually broken
Template request returns an error
Hashers keep working on stale work
No block can be found on the current tip
Persists until the node is restarted
Everything a generic monitoring dashboard watches would have stayed green. The one thing a miner needs from the node, a current template, was the one thing it had stopped producing.
Restart, patch and end of life
Restarting the node reloads the mempool from disk in a consistent state, which clears the symptom. It does nothing about the cause: the next reorg with the same transaction shape could stall the node again.
The cause was removed in three releases. Version 30.0 shipped with the fix on October 10, 2025, and backports followed in 29.2 and 28.3. From the private report to the last of those releases took three weeks.
26 Sept 2025
Niklas Goegge reports the bug to the Bitcoin Core security list
29 Sept
Greg Sanders opens PR #33504
2 Oct
Fix merged into master
3–7 Oct
Backported to the 29.x, 30.x and 28.x branches
14 Oct
29.2 released
17 Oct
28.3 released, closing the last affected branch
Both backport branches have since left support. Bitcoin Core’s maintenance policy covers the three most recent major versions, currently 30.x, 31.x and 32.x, and 29.x reached end of life on October 27, 2026. An operator who answered the original failure with a restart and nothing more is now running unsupported code, with a public description of exactly which transaction shape triggers it.
Why the advisory waited 396 days
From the first fixed release to the detailed advisory took 396 days, and the advisory landed exactly two weeks after 29.x went end of life. Neither number is a coincidence. Bitcoin Core’s disclosure policy holds medium- and high-severity details until two weeks after the last affected release is no longer supported, with a pre-announcement two weeks before that, timed to coincide with a new major release.
The embargo covered the explanation, not the code. The pull request has been public since September 29, 2025, and the 28.3 and 29.2 release notes listed a mempool fix at the time. What stayed private for a year was the write-up that connects the patch to a reproducible mining stall.
The policy does provide a faster route. Bugs classified as easily discoverable, which the project defines as findable with minimal effort, get an immediate point release and advisory with no embargo. This one went through the standard timetable, so the maintainers did not consider it trivial to find. It was published alongside two other high- and medium-severity advisories the same day, covering a block-processing stall and a Tor permissions error, all three fixed in the same October 2025 release cycle.
Coindoo has previously covered why Bitcoin Core adopted the easily-discoverable fast track. This advisory shows the slower track working as designed, and the assumption underneath it: that operators upgrade inside the year-long window, so that by the time the trigger is described in public, nobody vulnerable is still listening.
What to monitor instead of uptime
For a mining operation, the useful check is not whether the node is alive but how old its most recent successful template is. A process that is running, connected and synced can still have stopped delivering work, and this bug was one way for that to happen silently. Build version belongs in the same check, because a node that is current on templates today can be a node that is out of support tomorrow.
Backup template sources need the same question asked of them. A failover node on the same release and the same mempool policy would have hit the same reorg and the same stall; two running processes are not two independent sources of work. Only a node on a different, patched build would have kept the operation mining, and only an operator who tested that under a simulated reorg would have known it in advance.
Reporter at Coindoo
Alex is Editor-in-Chief of Coindoo and co-founder of Millennial Media Group, with nearly a decade of experience covering financial markets - crypto first, then everything else. It started in 2016 with Bitcoin. Like most people at the time, he didn't fully understand it - so he kept digging. Blockchain, tokenomics, the projects, the cycles. That curiosity never stopped, and eventually pulled him into traditional markets too: equities, commodities, macro. Not because he left crypto behind, but because you can't properly understand one without the other. What drives him is straightforward: he wants to know why something is happening, not just that it's happening. Most market coverage stops at the headline - price up, price down, here's a chart. Alex finds that kind of reporting actively unhelpful. If you walk away from an article without understanding the mechanism behind the move, what did you actually learn? He holds a degree in Tourism from New Bulgarian University - not the most obvious path into financial markets, but markets have a way of pulling in people who are simply too curious to stay out. He has authored over 200 in-depth analyses and more than 10,000 articles across crypto and traditional finance. He still thinks every day in markets teaches him something new. That's probably why he hasn't stopped.
Related stories
Advertisement
Up to 11100 usdt bonus for new users.
Low trading fee.
Best Crypto Portfolio Trackers in 2026: Wallets, DeFi & Bridges
That role has become more useful as bridging and onchain lending have become routine.…
What Is Solana (SOL) and How Does Its Blockchain Work?
Solana is a public blockchain built to process transactions at a pace and cost…
Best Web3 Social Media Platforms of 2026
Key takeaways Bluesky leads decentralized social on scale, without using a blockchain. Farcaster changed…
5 Things You Should Know Before Trading Crypto
Crypto trading can look simple until a fast market, thin order book or leveraged…
