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

lnpeer: channel_reestablish: split "they_are_ahead" into ctn vs revnum

Public commit record

What the developer wrote

Authored by SomberNight

50/100 · Thin
lnpeer: channel_reestablish: split "they_are_ahead" into ctn vs revnum
✓ Specific, descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
The short version

What changed, and why it matters

This commit tightens how Electrum's Lightning node handles a peer that reconnects after a disconnect and claims to be ahead on channel state. Previously, a single 'they_are_ahead' flag was used for two different counters, which could let a peer claim it was ahead on one counter without providing cryptographic proof on the other. The patch splits that into 'ahead with proof' (which triggers a safe data-loss-recovery path) and 'ahead without proof' (which now force-closes the channel instead of trusting the claim). It also schedules a force-close when data-loss-protect fields are invalid. In short, it reduces the chance a malicious or buggy peer can trick your node into a state where funds could be lost.

Recommended action

Reviewers should confirm that schedule_force_closing() is safe to call from inside channel_reestablish (no double-close or race with the outgoing channel_reestablish reply), and that the new test cases cover the main BOLT-2 misbehavior scenarios. Users running Lightning nodes should upgrade to a release containing this commit to reduce exposure to forged channel_reestablish messages.

Security signals we found

01

Split ambiguous 'they_are_ahead' flag into proof-verified vs unverified cases

02

Added force-close on invalid data-loss-protect fields

03

Added force-close when peer is ahead on commitment number without cryptographic proof

04

Added regression tests simulating a peer sending forged channel_reestablish values

05

Commented FIXME about unimplemented BOLT-02 'error' messages for misbehavior cases

Risk score

Why this scored 58/100

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