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

Mark legacy pre-0.3 inbound htlcs on persist

Public commit record

What the developer wrote

Authored by Valentine Wallace

80/100 · Strong
Mark legacy pre-0.3 inbound htlcs on persist

In 0.3+, we are taking steps to remove the requirement of regularly persisting
the ChannelManager and instead rebuild the set of HTLC forwards (and the
manager generally) from Channel{Monitor} data.

We previously merged support for reconstructing the
ChannelManager::decode_update_add_htlcs map from channel data, using a new
HTLC onion field that will be present for inbound HTLCs received on 0.3+ only.

However, we now want to add support for pruning this field once it's no longer
needed so it doesn't get persisted every time the manager gets persisted. At
the same time, in a future LDK version we need to detect whether the field was
ever present to begin with to prevent upgrading with legacy HTLCs present.

We accomplish both by converting the plain update_add option that was
previously serialized to an enum that can indicate whether the HTLC is from
0.2- versus 0.3+-with-onion-pruned (a variant for the latter is added in the
next commit).

Actual pruning of the new update_add field is added in the next commit.
✓ 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 is a data-format change inside the Lightning Dev Kit (LDK). It replaces a simple 'yes/no' storage field for incoming HTLCs with a three-way label: 'has full onion data', 'legacy pre-0.3 HTLC', or (in a later commit) 'onion was pruned'. The goal is to let future LDK versions know whether old HTLCs are still present so the node does not upgrade while carrying incompatible legacy state. There is no direct bug fix or exploit here; it is preparatory groundwork for safer upgrades and smaller persistence.

Recommended action

Treat as a normal refactor/forward-compatibility patch. Review the follow-up commit that adds the pruned-onion variant and actually removes onion persistence, since this commit only lays the enum groundwork. No immediate security action is required.

Security signals we found

01

Serialization format change for HTLC reconstruction state

02

New Legacy marker for pre-0.3 inbound HTLCs

03

TLV-upgradable enum to support future pruned-onion variant

04

Preparation for blocking upgrades with incompatible legacy HTLC state

Risk score

Why this scored 24/100

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