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

Set UpdateAddHTLC::hold_htlc for offline payees

Public commit record

What the developer wrote

Authored by Valentine Wallace

68/100 · Adequate
Set UpdateAddHTLC::hold_htlc for offline payees

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.

The prior commits laid groundwork to finally set the flag here in this commit.

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 finishes a feature that lets an often-offline Lightning payer ask the next node in the payment path to hold the payment (HTLC) until the offline recipient comes online and releases it. The change wires a previously unused flag through the payment-sending code so the 'hold_htlc' bit is actually set on outgoing HTLCs. It is a protocol feature implementation, not a fix for an active bug or exploit, but it touches payment logic and changes retry behavior for held HTLCs.

Recommended action

Review as part of normal feature merge. Verify that disabling retries (Retry::Attempts(0)) when hold_htlcs_at_next_hop is true cannot cause funds to become stuck if the next hop does not actually hold or release the HTLC, and confirm the fallback to enqueue_held_htlc_available is still safe when hold_htlc_channels() fails. No immediate security patch appears required.

Security signals we found

01

New protocol flag wired into outgoing HTLC messages

02

Retry disabled when HTLCs are intentionally held at the next hop

03

Payment path selection and fallback logic changed for static invoices

04

Feature tied to BOLTs PR 989 (offline/async payment support)

Risk score

Why this scored 27/100

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