Intercept htlcs (ChannelManager)
Host: ariard -
The PR branch HEAD was 28870ff at the time of this review club meeting.
- Currently, the main HTLC forward mechanism of LDK is handled by
- The routing policy checks as mandated by BOLT4 is implemented in
decode_update_add_htlc_onion(). While mandatory checks are required to avoid DoSy/weird HTLCs paralyzing liquidity or failing-quickly, our current interface does not allow to interrupt relay.
- #1601 introduces a new event to allow LDK users to catchup events on the fly. The main-use serviced is on-demand channel operated by Lightning Service Providers.
1) What’s the current HTLC flow from receiving an
update_add_htlc() to outbound
send_htlc() ? What actions do
process_pending_htlc_forward() ? Why HTLCs are not currently processed from
2) How the current flow for inbound payment works from the point where the payment is detected as final ?
3) What’s a
fake_scid and how the scid namespaces works ? Do you see any issue with this privacy-preserving scheme ?
4) The PR introduces a new
PendingInterceptedHTLC, the serialization method
impl_writeable_tlv_based() requires all the fields to be
required why not
5) What’s the flow of on-demand channels ? How
forward_intercepted_payment() would work in that context ? Why an intercepted payment might fail ?
6) What other use-cases could be implemented with #1601 (e.g trampoline or
delay_my_htlc option ?
7) Can you think about any probing or jamming vector we could introduce with this PR ?