Bitcoin Core discloses a bug that could stop a mining node making block templates
Source report: 2026-11-10 · Editorial analysis published: 2026-11-12
The November 10 advisory explains why some older nodes could stop preparing Bitcoin mining jobs after a chain reorganization. Fixed releases have been available since October 2025.
A new disclosure about older nodes
Bitcoin Core published details on November 10 of a high-severity flaw that could stop an affected node from preparing new blocks for miners. It is tracked as CVE-2025-62861. The code fix shipped in October 2025; the new event is the public explanation of when the failure could happen and which versions were affected.
Bitcoin Core lists 28.0 through 28.2 and 29.0 through 29.1 as affected. It lists 30.0, 29.2 and 28.3 as the releases that fixed the issue in their respective branches. Those numbers help identify exposure, while the official download page is the place to check for a current supported release.
How the work could stop
A mining node builds a block template, a draft of the next block, before an ASIC can search for a valid solution. The draft draws on the node’s mempool, its local list of unconfirmed transactions. A pool can send mining jobs based on that draft to machines it manages or to miners connected over the internet.
A reorganization occurs when the node accepts a better chain and replaces some recent blocks. It can put transactions from the displaced blocks back in the waiting list. In the affected code, a transaction replacement rule could run during that restoration and leave an entry that depended on a transaction the list no longer contained. The draft block then failed its validity check.
The advisory says the affected node could remain unable to produce valid templates until a restart reloaded the list in a consistent state. That describes a local failure. The notice does not report a network-wide mining stoppage. Restarting addresses that instance; using fixed software removes the described cause.
The underlying rule concerns a particular kind of version 3 transaction. A node can limit which unconfirmed transactions it relays even when a block containing those transactions is valid. Applying that waiting-list rule while restoring transactions from a block caused the inconsistency.
What to check if you mine with your own node
Check the version on the host that prepares jobs. If you also run a wallet node on a different machine, its version tells you nothing about the one sending work to your ASICs. Record which pool or mining server uses which node, including a backup if you have one.
Use the official download and verification instructions when updating. Once the node has caught up with the chain, check that the mining server is receiving fresh templates and that the ASIC receives and returns work. Chain synchronization and job creation are separate checks. A node can be reachable while one part of the mining setup has stopped working.
If several mining servers depend on the same node, they may stop together. Record the upstream node for each endpoint when planning maintenance, so a backup test checks a separate path rather than two addresses leading back to the same service.
If you use somebody else’s pool
For a hosted pool, the operator maintains the node that builds blocks. If jobs stop arriving, check whether the interruption affects just your machine or other workers at the same endpoint. Look at the last accepted share and the time of the last new job. Those two readings can help the operator decide where to investigate.
An ASIC can still show a local hashrate when it has no useful new work from its pool. Conversely, a quiet payout screen may simply reflect the pool’s payout schedule. If you have a backup endpoint, test that it accepts shares before you depend on it. The advisory concerns the node software; an ASIC firmware change alone cannot fix it.
Two other issues were disclosed
Bitcoin Core also described a compact-block processing stall in older versions and a separate bug in how some setups assigned trust to incoming Tor connections. Each advisory lists its own conditions and patched releases. Neither should be confused with the high-severity bug in assembling mining templates.
The disclosure is a good reason to verify the versions actually running behind each mining endpoint. A machine’s speed and its ability to get fresh work are different things. You need both to keep contributing useful hashrate.
Source: Bitcoin Core ↗ · Bitcoin Core — compact block advisory ↗ · Bitcoin Core — inbound Tor advisory ↗ · Bitcoin Core — official downloads and verification ↗
Mining calculator ↗
