AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Low 27 Bitcoin

mining: add cooldown argument to createNewBlock()

Public commit record

What the developer wrote

Authored by Sjors Provoost

98/100 · Strong
mining: add cooldown argument to createNewBlock()

At startup, if the needs to catch up, connected mining clients will
receive a flood of new templates as new blocks are connected.

Fix this by adding a cooldown argument to createNewBlock(). When set
to true, block template creation is briefly paused while the best
header chain is ahead of the tip.

This wait only happens when the best header extends the current tip,
to ignore competing branches.

Additionally, cooldown waits for isInitialBlockDownload() to latch to
false, which happens when there is less than a day of blocks left to sync.

When cooldown is false createNewBlock() returns immediately. The argument
is optional, because many tests are negatively impacted by this
mechanism, and single miner signets could end up stuck if no block
was mined for a day.

The getblocktemplate RPC also opts out, because it would add a delay
to each call.

Fixes #33994
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This change adds a short waiting period (cooldown) when Bitcoin Core creates a new block template while the node is still catching up to the network. The goal is to stop mining software from receiving a flood of rapidly changing templates during initial sync. It is a performance and robustness improvement, not a fix for a direct money-stealing or remote-code-execution bug. The patch itself is careful to avoid a known risk: if a malicious miner announced a far-ahead header but withheld the actual block, waiting forever could stall honest miners. The new code caps the wait and only waits while the best header extends the current tip, not a competing branch.

Recommended action

No urgent security action required. This is a defensive robustness improvement. Operators using external mining clients over the IPC or libbitcoinkernel interfaces should ensure they are running a version that includes this change so that template floods during sync are reduced. Review the default `cooldown=true` behavior for any custom mining integrations that cannot tolerate startup delays.

Security signals we found

01

Denial-of-service mitigation: prevents mining clients from being flooded with templates during sync

02

Avoids indefinite stall when a malicious miner announces a withheld header (explicitly noted in code comments)

03

Only extends the current tip, ignoring competing branches, reducing risk of being misled by side-chain headers

04

Adds bounds to the cooldown window (3–20 seconds)

05

Functional test exercises the header-ahead cooldown path

Risk score

Why this scored 27/100

Our methodology →
Potential impact 4/30
Exploitability 3/25
Stealth signal 5/15
Affected reach 5/15
Confidence 7/10
Evidence quality 3/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.