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

Persist hold_htlc flags in Channel

Public commit record

What the developer wrote

Authored by Valentine Wallace

68/100 · Adequate
Persist hold_htlc flags in Channel

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 Channel serialization.

See-also BOLTs PR 989
✓ 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 'hold_htlc' flag to Lightning channel data structures and makes sure it gets saved to and loaded from disk. The flag is not yet used to actually change any network behavior; it is only groundwork for a future feature that lets an often-offline sender ask the next node to hold an HTLC until a release message arrives. Because the flag is always set to None and never read for protocol decisions, it does not introduce a currently exploitable vulnerability.

Recommended action

No immediate security action required. Treat as normal feature groundwork. When the follow-up commits begin setting hold_htlc to Some(()), review the protocol logic that releases held HTLCs for correctness, DoS resistance, and timeout handling.

Security signals we found

01

New serialization field added with TLV optional vectors (tags 67 and 69)

02

Deserialization validates vector length matches HTLC count, returning DecodeError::InvalidValue on mismatch

03

Feature flag is never set to a non-None value in production code paths

04

No protocol logic currently branches on hold_htlc value

05

Commit message explicitly states groundwork only: 'We don't yet ever set this flag'

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.