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

dualopend: fix next_funding reconnect: error if both set it, tx_abort if only peer

Public commit record

What the developer wrote

Authored by Níckolas Goline

91/100 · Strong
dualopend: fix next_funding reconnect: error if both set it, tx_abort if only peer

Per BOLT #2: when both nodes set next_funding in channel_reestablish but txids differ,
MUST send error and fail the channel; when only the peer sets next_funding, MUST send
tx_abort instead. Track we_set_next_funding before tlvs is overwritten by the received
channel_reestablish so the distinction survives the receive.
Includes a regression test: reconnect two nodes with a corrupted inflight txid so both
set next_funding with mismatched values, and verify both sides call open_err_fatal.

Changelog-None
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This commit fixes a bug in Core Lightning's channel reconnection handshake for v2 (dual-funded) channel opens. Before the fix, the code could not tell whether it had itself sent a 'next_funding' field in its own reconnection message, so it always responded to a peer's mismatched 'next_funding' with a gentler 'tx_abort'. The BOLT specification requires a stronger 'error' and channel failure when both sides sent 'next_funding' but disagree, and only a 'tx_abort' when only the peer sent it. The patch tracks that distinction correctly and adds a regression test that corrupts one side's stored funding transaction ID to force the mismatch.

Recommended action

Review and merge. The change is a targeted protocol-compliance fix with a regression test. Operators should upgrade to avoid incorrect handling of inconsistent next_funding during v2 dual-funded channel reconnects.

Security signals we found

01

Protocol-state mismatch on reconnect could previously be handled as a soft abort instead of a fatal error

02

BOLT #2 compliance fix: both-set mismatch now triggers error/channel failure

03

Only-peer-set case now correctly triggers tx_abort instead of error

04

Regression test corrupts stored funding txid to force disagreeing next_funding values

Risk score

Why this scored 57/100

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