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

Store held htlcs in pending_intercepted_htlcs

Public commit record

What the developer wrote

Authored by Valentine Wallace

68/100 · Adequate
Store held htlcs in pending_intercepted_htlcs

As part of supporting sending payments as an often-offline sender, the sender's
always-online channel counterparty needs to hold onto the sender's HTLC until
they receive a release_held_htlc onion message from the often-offline
recipient.

Here we implement storing these held HTLCs in the existing
ChannelManager::pending_intercepted_htlcs map.

We want to move in the direction of obviating the need to persistence the
ChannelManager entirely, so it doesn't really make sense to add a whole new map
for these HTLCs.
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit adds a new way for the Lightning Dev Kit node to temporarily hold forwarded payments when the final recipient is offline. It reuses an existing internal storage map (pending_intercepted_htlcs) for these newly held HTLCs. The change is a feature implementation, not a fix for a known vulnerability, and the commit message does not describe any security issue.

Recommended action

Treat as a normal feature commit. Reviewers should verify that held HTLCs cannot collide with user-intercepted HTLCs in pending_intercepted_htlcs, that timeouts/failure paths correctly remove held entries, and that persistence and recovery of the new hold_htlc field is backward compatible. No immediate security response is indicated by the supplied materials.

Security signals we found

01

New state machine for holding HTLCs until an external trigger (ReleaseHeldHtlc onion message)

02

Reuses pending_intercepted_htlcs map for a second, semantically different category of HTLCs

03

Adds debug_assert guarding against duplicate held HTLCs, with fail_intercepted_htlc fallback

04

Serialization format change for PendingHTLCRouting::Forward (TLV field 4, hold_htlc, option)

05

No explicit security claim, CVE, or bug fix language in commit or supplied references

Risk score

Why this scored 27/100

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