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

Add UpdateAddHTLC::hold_htlc

Public commit record

What the developer wrote

Authored by Valentine Wallace

66/100 · Adequate
Add UpdateAddHTLC::hold_htlc

As part of supporting sending payments as an often-offline sender, the sender
needs to be able to set a flag in their update_add_htlc message indicating that
the HTLC should be held until receipt of a release_held_htlc onion message from
the often-offline payment recipient.

We don't yet ever set this flag, but lay the groundwork by including the field
in the update_add struct.

See-also <https://github.com/lightning/bolts/pull/989>
✓ Descriptive subject✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This commit adds a new placeholder field called hold_htlc to the Lightning update_add_htlc message structure. The field is never actually set to a value anywhere in the code; it is always initialized to None. It prepares the codebase for a future feature that lets an often-offline sender ask a forwarding node to hold an HTLC until the recipient comes back online. Because the flag is never enabled, this change by itself does not create a practical security vulnerability.

Recommended action

No immediate security action required. Treat as a protocol groundwork commit. Monitor the follow-up work that actually sets hold_htlc and implements ReleaseHeldHtlc handling, since that will be the point at which safety properties (e.g., timeout handling, preimage release, channel reserve accounting) need careful review.

Security signals we found

01

New optional TLV field added to a core Lightning protocol message (update_add_htlc)

02

Field is currently always None and no code path sets it

03

Temporary TLV type (75537) chosen instead of the final BOLTs PR 989 type due to downgrade-read concerns

04

Comment explicitly states potential failure to read ChannelManager after downgrade if a new even TLV is written

Risk score

Why this scored 19/100

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