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

Send held_htlc_available with counterparty reply path

Public commit record

What the developer wrote

Authored by Valentine Wallace

73/100 · Adequate
Send held_htlc_available with counterparty reply path

As part of supporting sending payments as an often-offline sender, the sender
needs to send held_htlc_available onion messages such that the reply path to
the message terminates at their always-online channel counterparty that is
holding the HTLC. That way when the recipient responds with release_held_htlc,
the sender's counterparty will receive that message.

After laying groundwork over some past commits, here we as an async sender send
held_htlc_available messages using reply paths created by our always-online
channel counterparty.
✓ Specific, 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 feature for asynchronous Lightning payments where an often-offline sender can ask their always-online channel counterparty to hold a payment. The change ensures that when the counterparty confirms a channel state update (via revoke_and_ack), the sender extracts reply paths provided by the counterparty and uses them to send 'held_htlc_available' onion messages. The reply paths ensure the recipient's release response returns to the sender's online counterparty. The commit also includes a defensive check to ignore reply paths for HTLCs that were not actually configured as async payments, which limits a potential privacy leak where a counterparty could otherwise learn which payments are async.

Recommended action

Review as normal feature work with a security-relevant validation. Verify that the static_invoice/hold_htlc guard is sufficient and that no other code paths accept release_htlc_message_paths without equivalent checks. Consider whether a malicious counterparty can still infer async-payment status through timing, ordering, or error responses. No immediate patch or incident response is indicated by the diff alone.

Security signals we found

01

New defensive validation: counterparty-provided release_htlc_message_paths are only accepted for HTLCs that have a static invoice and hold_htlc configured, mitigating a potential information-disclosure side channel.

02

Async payment reply paths are now routed through the always-online channel counterparty rather than the offline sender, which is a protocol correctness change for BOLT 12 async payments.

03

debug_assert! guards the assumption that enqueue_held_htlc_available only fails for non-async senders; this is an internal invariant, not runtime error handling.

Risk score

Why this scored 26/100

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