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

lightningd: watch a dual-funded channel's funding outputs before lock-in

Public commit record

What the developer wrote

Authored by Níckolas Goline

73/100 · Adequate
lightningd: watch a dual-funded channel's funding outputs before lock-in

A dual-funded channel armed its funding-output spend watch only at
lock-in. Until then we watched whether the funding tx had confirmed and
how deep it was, neither of which fires when the output is spent. With
funding-confirms at 3 the opener can confirm the funding and close on it
in the next block: we never see the spend, lock in anyway, keep routing
over a channel with no funding output, and never notice the cheat once
the peer's commitment is revoked. The single-funded path has always
watched from channel creation.

Arm channel_watch_inflight_outs() as soon as a candidate is recorded,
before our commitment_signed goes out, since that is the moment the peer
can broadcast it; the restart path already re-arms for every channel
with inflights. When a spend arrives while we are still awaiting
lock-in, the spent candidate is by definition the one that got mined:
adopt it as the channel's funding, as opening_depth_cb would have,
before onchaind is started, so onchaind is not handed the latest
attempt's commitment for an outpoint that may never exist. The
candidate watch that fired becomes the channel's funding_spend_watch,
so drop_to_chain() does not add a second watch on the same outpoint
while the block scanner is still iterating it. At lock-in, drop the
candidate watches again: the outpoint is the channel's own from then on,
and a surviving candidate watch would fire funding_spent() twice on
every later close.

Changelog-Fixed: dual-funding: a channel whose funding output is spent before lock-in is now handed to onchaind instead of being locked in and used.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
(cherry picked from commit e44cf3401eccb9e6306aaa5ede8f9d52ead44b57)
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This fix closes a serious bug in Core Lightning's dual-funded channel opening. Before the patch, the node only started watching for a spend of the new channel's funding output after the channel had 'locked in.' A malicious or careless peer could confirm the funding transaction and immediately spend the funding output in a close transaction before lock-in. The node would miss the spend, still lock in the channel, continue routing payments over a channel whose funding no longer existed, and fail to detect a later cheating attempt. The patch arms the spend watch as soon as the funding candidate is recorded, and correctly hands the channel to onchaind if a spend is seen before lock-in.

Recommended action

Treat this as a security fix and include it in the next maintenance release. Operators running dual-funded channels should upgrade promptly. Review whether any node that opened dual-funded channels while running affected versions shows channels locked in without a matching unspent funding UTXO, and consider closing or monitoring those peers closely.

Security signals we found

01

Missing spend watch before lock-in allowed channel to lock in despite spent funding output

02

Peer could broadcast commitment immediately after minimum_depth confirmation, before local node arms funding_spent watch

03

Channel state could advance to CHANNELD_NORMAL with no UTXO backing it

04

Later revoked commitment would not be detected as a cheat because the funding spend was missed

05

Fix arms txo watch at candidate creation and routes pre-lock-in spend to onchaind

06

Regression test demonstrates exploit scenario: confirm funding, spend output next block, node must enter ONCHAIN

Risk score

Why this scored 79/100

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