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

funding: fix race in itest for zero-conf funding

Public commit record

What the developer wrote

Authored by ziggie

90/100 · Strong
funding: fix race in itest for zero-conf funding

Fix a race condition where forwarding through a public zero-conf channel
could fail with UnknownNextPeer when using the confirmed SCID. The issue
occurred because ReportShortChanID (which updates the switch's baseIndex
to handle the confirmed SCID) was called AFTER addToGraph (which announces
the confirmed SCID to the network).

With slow backends like postgres, addToGraph takes significant time,
creating a window where other nodes learn about the confirmed SCID from
gossip and attempt to route through it, but the receiving node's switch
hasn't been updated yet to handle forwards using the confirmed SCID.

The fix reorders operations to call ReportShortChanID before addToGraph,
ensuring the switch is ready to handle the confirmed SCID before it's
announced to the network. Forwards using either the alias or confirmed
SCID will work since getLinkByMapping uses baseIndex to map both to the
same link in forwardingIndex.

Fixes flaky test: zero_conf-channel_policy_update_public_zero_conf
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification
The short version

What changed, and why it matters

This commit fixes a timing bug in the LND Lightning node software that affected zero-confirmation channels. When a channel became publicly announced after six confirmations, the node would tell the network about the new channel ID before its own internal payment forwarding switch was ready to use that ID. On slow database backends, this created a brief window where payments routed through that channel could fail with an 'UnknownNextPeer' error. The fix simply reorders two internal steps so the switch is updated before the channel is announced to the network. It is a reliability fix rather than a vulnerability that allows theft or loss of funds.

Recommended action

Treat as a normal reliability/bug-fix patch. Users running nodes with zero-conf public channels and slow backends (e.g., Postgres) benefit most from upgrading. No emergency action is required; there is no evidence of fund loss or remote exploitation.

Security signals we found

01

Race condition between local switch state update and network gossip announcement

02

Payment forwarding failure (UnknownNextPeer) for confirmed SCID of public zero-conf channels

03

Timing-dependent behavior amplified by slow database backends (e.g., Postgres)

04

Fix is a reordering of existing operations, not a logic change

05

Test updated to enforce ReportShortChanID before channel announcement

Risk score

Why this scored 37/100

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