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

Store inbound committed update_adds in Channel

Public commit record

What the developer wrote

Authored by Valentine Wallace

80/100 · Strong
Store inbound committed update_adds in Channel

We have an overarching goal of (mostly) getting rid of ChannelManager
persistence and rebuilding the ChannelManager's state from existing
ChannelMonitors, due to issues when the two structs are out-of-sync on restart.
The main issue that can arise is channel force closure.

As part of this, we plan to store at least parts of Channels in
ChannelMonitors, and that Channel data will be used in rebuilding the manager.

Once we store update_adds in Channels, we can use them on restart when
reconstructing ChannelManager maps such as forward_htlcs and
pending_intercepted_htlcs. Upcoming commits will start doing this
reconstruction.
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
The short version

What changed, and why it matters

This commit changes how the Lightning Dev Kit stores information about incoming payment commitments inside a channel. It keeps a copy of the original 'update_add' message alongside committed inbound HTLCs so that, after a restart, the node can rebuild its internal payment-forwarding maps from Channel and ChannelMonitor data rather than relying on the separate ChannelManager persistence. The change is framed by the authors as a reliability improvement to avoid force-closure when ChannelManager and ChannelMonitor get out of sync on restart. It is not a direct security patch and does not appear to fix an active exploit, but it touches consensus-adjacent state and serialization, so mistakes here could affect funds safety.

Recommended action

Treat as a normal, well-documented refactor/state-improvement commit. Reviewers should verify that the new TLV field is read exactly once per Committed inbound HTLC, that the optional_vec length matches the number of Committed HTLCs, and that no duplicate or stale update_add data can be used during ChannelManager reconstruction in follow-up commits. No immediate security response is indicated by this commit alone.

Security signals we found

01

State-machine change for committed inbound HTLCs

02

New TLV serialization field (75) for inbound_committed_update_adds

03

Persistence format change with backward-compatible None default for old states

04

Explicit goal of reducing force-closure risk from out-of-sync ChannelManager/ChannelMonitor on restart

05

No direct bug fix or vulnerability disclosure language in commit message

Risk score

Why this scored 31/100

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