LDK-Review-CLub-1601.md

LDK Review Club 3rd Session

Jul 19, 2022, 6 PM UTC, #review-club on Discord

lightningdevkit/rust-lightning#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 ?

The last sentence of question 1 seems incomplete.