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

Support async fetching of commitment point during channel reestablish

Public commit record

What the developer wrote

Authored by Wilmer Paulino

73/100 · Adequate
Support async fetching of commitment point during channel reestablish

`HolderCommitmentPoint` currently tracks the current and next point used
on counterparty commitments, which are unrevoked. When we reestablish a
channel, the counterparty sends us the commitment height, along with the
corresponding secret, for the state they believe to be the latest. We
compare said secret to the derived point we fetch from the signer to
know if the peer is being honest.

Since the protocol does not allow peers (assuming no data loss) to be
behind the current state by more than one update, we can cache the two
latest revoked commitment points alongside `HolderCommitmentPoint`, such
that we no longer need to reach the signer asynchronously when handling
`channel_reestablish` messages throughout the happy path. By doing so,
we avoid complexity in needing to pause the state machine (which may
also result in needing to stash any update messages from the
counterparty) while the signer response is pending.

The only remaining case left to handle is when the counterparty presents
a `channel_reestablish` with a state later than what we know. This can
only result in two terminal cases: either they provided a valid
commitment secret proving we are behind and we need to panic, or they
lied and we force close the channel. This is the only case we choose to
handle asynchronously as it's relatively trivial to handle.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit improves how the Lightning node handles reconnections after a network interruption. Previously, when re-establishing a channel, the node sometimes had to ask an external signer for a cryptographic proof point and could not proceed until the signer responded. The change keeps the two most recent revoked proof points cached locally so the common case no longer needs to wait for the signer. It only defers to the signer asynchronously in the rare 'stale state' case, where the peer claims our node is behind. That stale case either proves data loss (causing a protective panic) or proves the peer is lying (causing a force-close). The commit is a defensive hardening/feature change, not a fix for an active exploit.

Recommended action

Review as a normal defensive improvement. No urgent security patch is indicated by the commit itself. Users relying on async signers should ensure they upgrade to avoid the previous TODO limitation and potential incorrect handling during reestablish.

Security signals we found

01

Adds async signer support for stale-state verification during channel reestablish

02

Caches two latest revoked commitment points to avoid async signer round-trip on happy path

03

Introduces signer_pending_stale_state_verification for deferred verification

04

Adds panic_on_stale_state helper for data-loss detection

05

Changes signer_maybe_unblocked return type to Result to allow error propagation

06

Adds regression/unit tests for async stale-state panic and invalid-secret force-close

Risk score

Why this scored 42/100

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