Bitcoin Core Reveals Why Some Nodes Could Stop Mining

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.

Stablecoins vs Bank Wires – Speed Isn’t Where the Money Is

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.