Return `FEE_INSUFFICIENT` before checking balance for incoming low-fee HTLCs (htlcswitch)
https://github.com/lightningnetwork/lnd/pull/6417
Host: arshbot -
Notes
- Check andrewshvv: add “htlcswitch” package - https://github.com/lightningnetwork/lnd/pull/91
- Check Joost Jager: A proposal for upfront payments - https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-March/002585.html
Questions
- Can anyone provide a TLDR for this PR?
- What is 0 fee channel probing? How can it be abused? Are there any decent usecases for it (should this be allowable on the network)?
- How can an attacker use this information to their advantage? How much does channel probing fiscally cost the attacker? Why? What else might an attacker do with payments that never complete?
- What is channel jamming?
- This PR aims to patch data leakage wrt when
FEE_INSUFFICIENT
**returned.
Previously, if an incoming low fee HTLC’s value is too large for the channel to route with local balance, it would return TEMPORARY_CHANNEL_FAILURE
while if the channel is sufficient for the htlc, it would return FEE_INSUFFICIENT
. An attacker could use this disparity in error messages to probe the channel balance of another peer, even if the peer wishes to hide this information.
This PR modifies the HtlcSwitch module so the validation of the htlc fee is performed before moving forward, preventing 0 fee htlcs from moving ahead if the node has a higher fee set.
Does this effectively mitigate channel probing?
- What are some other ways that might effectively mitigate channel probing or jamming?
- Let’s talk about the
switch
for a moment (also known as thehtlcForwarder
). What is the switch within LND? What is it responsible for? - Concept ACK, NACK?