lightning-dev

In-protocol liquidity probing and channel jamming mitigation

In-protocol liquidity probing and channel jamming mitigation

Original Postby Joost Jager

Posted on: October 14, 2021 07:48 UTC

Lightning wallets typically probe routes with an unknown payment hash to determine accurate routing fees before executing the actual payment, but this practice locks up liquidity for a short period of time.

To address this issue, a proposal was put forth for a liquidity probing protocol message similar to update_add_htlc that would skip channel update machinery and only be forwarded to the next hop if the link can carry the htlc. While nodes can reject these probes, senders will not use that route, and the routing node misses out on routing fees. Another problem in the lightning network is susceptibility to channel jamming, which several proposed solutions exist for, including deterring attackers by making them pay actual satoshis. However, this solution has received criticism that it deteriorates user experience for honest users when multiple payment routes are attempted, and each attempt has a cost. The combination of making probing free and requiring senders to pay for failed payment attempts after a successful probe could potentially fix the UX issue with upfront fees. Custodial wallets could swallow the cost for failures, but non-custodial nodes must map out good routing nodes themselves, incurring a cost.