Intercept htlcs (ChannelManager)

https://github.com/lightningdevkit/rust-lightning/pull/1601

Host: ariard  -  PR author: johncantrell97

The PR branch HEAD was 28870ff at the time of this review club meeting.

Notes

  • Currently, the main HTLC forward mechanism of LDK is handled by ChannelManager the process_forward_htlcs() / ChannelHolder::forward_htlcs
  • 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.

Questions

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 optional ? 5) What’s the flow of on-demand channels ? How fail_intercepted_payment() and 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 ?