Bitcoin Core Bug Could Trigger Repeated 10-Minute Node Delays

By Nathan Brooks

Bitcoin Core disclosed CVE-2025-62859 on Nov. 10 as a medium-severity vulnerability that can repeatedly stall block processing on affected nodes. Each failed block request in the disclosed failure path produces a 10-minute wait, and fixes are included in Bitcoin Core 29.2 and 30.0, according to the project’s security disclosure.

How does the vulnerability work?

The flaw lies in compact-block processing, where a node uses peer-supplied information to reconstruct a candidate block. Bitcoin Core said a malicious peer could alter witness data in a compact block before the target node rebuilt it.

On a vulnerable node, the disclosure describes this sequence:

• The node rebuilds the block from the compact representation.
• It clears its download state before checking the witness data.
• If validation fails, it requests the full block from that same peer and waits for a timeout.

Bitcoin Core stated that the fallback request causes a 10-minute wait whenever validation fails. The ordering is central because validation failure does not terminate the sequence described above. The node has already cleared its download state, and its next action is a request to the same peer rather than a return to normal block processing.

Each timeout cycle adds 10 minutes. Two cycles consume 20 minutes, while six consume a full hour. Once the conditions for repetition are present, Bitcoin Core said the delay could continue indefinitely; the disclosure identifies no fixed ceiling on the resulting wait.

Under what conditions can the delay repeat?

Bitcoin Core identifies two sufficient conditions, either of which can sustain the repeated timeout:

• The attacker controls all three of the target node’s high-bandwidth peers.
• The target node runs with the -blocksonly option.

The disclosure treats these conditions as alternatives, not cumulative prerequisites. Under either condition, the same malicious compact-block failure can recur and generate successive 10-minute waits.

What is the operational consequence?

The disclosed consequence is a processing delay, not acceptance of the altered witness data. The target rebuilds the candidate block and then detects that validation fails. Its fallback request creates a wait, allowing a malicious peer to keep the affected node occupied in 10-minute increments.

Operationally, this is an availability issue for affected nodes: a peer can prevent timely progress by sending data that fails validation, then failing to satisfy the full-block request. Bitcoin Core’s description does not stop at one timeout. Under either recurrence condition, the affected node can keep waiting on the same peer for an open-ended period.

Which Bitcoin Core versions are affected?

Bitcoin Core 29.2 and 30.0 contain the fixes, while the flaw affected versions released before them. The disclosed remediation therefore requires a software upgrade rather than only a topology or configuration change.

Operators can address the vulnerability by moving to either Bitcoin Core 29.2 or 30.0. The two peer or configuration conditions describe routes through which the flaw can persist on an affected node; they do not replace the need to install the corrected software.

Who found and disclosed the issue?

Eugene Siegel discovered the flaw and responsibly disclosed it, according to Bitcoin Core. The project then published the vulnerability identifier, severity rating, affected mechanism and fixed versions in its Nov. 10 disclosure.

What does this change for node operators?

It changes the operational response. The first step is to identify the Bitcoin Core version in service and upgrade an affected node to 29.2 or 30.0. The second is to examine peer topology and configuration against the two recurrence conditions.

Operators should determine whether an attacker could control all three high-bandwidth peers and whether the node runs with -blocksonly. Those checks do not replace the software update; they identify the configurations in which one malicious compact-block response can become a sequence of 10-minute waits.

The practical distinction is between a node that rejects invalid witness data and continues processing, and a vulnerable node that can remain waiting on the same peer after rejection. Siegel’s disclosure and Bitcoin Core’s fix turn that distinction into a concrete upgrade and configuration review for operators.

Going forward, the relevant window is deployment of Bitcoin Core 29.2 or 30.0: until an affected node upgrades, the disclosed 10-minute failure path remains available under the stated peer or configuration conditions.