Return `FEE_INSUFFICIENT` before checking balance for incoming low-fee HTLCs (htlcswitch)
Host: arshbot -
- 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
- 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
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
switchfor a moment (also known as the
htlcForwarder). What is the switch within LND? What is it responsible for?
- Concept ACK, NACK?