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

ipc mining: Prevent ``Assertion `m_node.chainman' failed`` errors on early startup

Public commit record

What the developer wrote

Authored by Ryan Ofsky

81/100 · Strong
ipc mining: Prevent ``Assertion `m_node.chainman' failed`` errors on early startup

This fixes ``Assertion `m_node.chainman' failed`` errors first reported
https://github.com/bitcoin/bitcoin/issues/33994#issuecomment-3602551596 when
IPC mining methods are called before ChainstateManager is loaded.

The fix works by making the `Init.makeMining` method block until chainstate
data is loaded.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This commit fixes a crash in Bitcoin Core that could happen when external programs talk to the node over the IPC mining interface while the node is still starting up. Before the fix, calling mining methods too early could trigger an internal assertion failure and crash the node. The fix makes external mining clients wait until the node's chain data is fully loaded before they can proceed.

Recommended action

Treat this as a security-hardening fix with denial-of-service relevance. Backport to maintained branches that expose the IPC mining interface. Verify that the new functional test `run_early_startup_test` passes and that no other early-startup IPC interfaces have similar uninitialized-pointer assumptions.

Security signals we found

01

Denial-of-service vector: unauthenticated or early IPC mining client could crash the node via assertion failure

02

Race condition between IPC mining interface availability and ChainstateManager initialization

03

Fix introduces blocking wait on chainstate_loaded condition variable for external mining interface creation

04

Internal mining interface explicitly opts out of waiting to preserve startup ordering

Risk score

Why this scored 57/100

Our methodology →
Potential impact 18/30
Exploitability 12/25
Stealth signal 8/15
Affected reach 7/15
Confidence 8/10
Evidence quality 4/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.