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

Prune inbound HTLC onions once forwarded

Public commit record

What the developer wrote

Authored by Valentine Wallace

68/100 · Adequate
Prune inbound HTLC onions once forwarded

We store inbound committed HTLCs' onions in Channels for use in reconstructing
the pending HTLC set on ChannelManager read. If an HTLC has been forwarded to
the outbound edge, we no longer need to persist the inbound edge's onion and
can prune it here.
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit is a memory/storage cleanup change in a Lightning Network node implementation. Once a payment (HTLC) has been securely forwarded to the next channel, the node now discards the detailed routing onion it received from the previous channel, because that onion is no longer needed after forwarding. It keeps only the small pieces of information required to handle failures or claims after a restart. The change includes tests confirming the onion is kept before forwarding and removed after forwarding.

Recommended action

No immediate action required. Treat as a routine hardening/cleanup change. Reviewers should verify that `HTLCPreviousHopData` and `outbound_amt_msat` are sufficient for all restart paths (failure, claim, `PaymentForwarded`) and that the new enum variant deserializes correctly from older persisted states.

Security signals we found

01

Reduction of persisted sensitive routing data (onion packets) after it is no longer needed

02

Preservation of minimal HTLC metadata needed for safe backward failure/claim and event generation after restart

03

New serialization variant for pruned inbound HTLC state with required TLV fields

04

Test coverage added for both pre-forward persistence and post-forward pruning across restarts

Risk score

Why this scored 25/100

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