diff --git a/spam-prevention.md b/spam-prevention.md index 78b732a..d100b36 100644 --- a/spam-prevention.md +++ b/spam-prevention.md @@ -66,15 +66,21 @@ network with a constant stream of such HTLCs to disrupt legitimate payments. We' ## Mitigation strategies available today -It is not possible today to fully prevent this type of attacks, but properly configuring channels -can help partially mitigate them: +It is not possible today to fully prevent this type of attacks, but we can make the attacker's job +harder by properly configuring channels: -* use a reasonable value for `htlc_minimum_msat` (1 sat is **not** a reasonable value for channels - with a big capacity; it may be ok for small channels though) +* the attacker needs to lock at least `htlc_minimum_msat * max_accepted_htlcs` of his own funds to + completely fill a channel, so you should use a reasonable value for `htlc_minimum_msat` (1 sat is + **not** a reasonable value for channels with a big capacity; it may be ok for smaller channels + though) * open redundant unannounced channels to your most profitable peers * implement relaying policies to avoid filling up channels: always keep X% of your HTLC slots available, reserved for high-value HTLCs +Long-lived controlled spams might also be mitigated by a relay policy rejecting too far in the +future CLTV locktime or requiring a lower `cltv_expiry_delta`. This later mitigation may downgrade +relay node security. + ## Threat model We want to defend against attackers that have the following capabilities: @@ -84,25 +90,52 @@ We want to defend against attackers that have the following capabilities: * they are running modified (malicious) versions of LN node implementations * they are able to quickly create many seemingly unrelated nodes * they may already have long-lived channels (good reputation) +* they might probe in real-time channel balances to adjust their spams +* they might send long-held HTLCs, those ones unobservable from the set of honest long-held HTLCs There are important properties of Lightning that we must absolutely preserve: * payer and payee's anonymity * trustless payments -* decentralization -* minimal (reasonable) barrier to entry +* minimal (reasonable) barrier to entry as routing node * minimal overhead/cost for legitimate payments +* minimal overhead to declare public paths to the network +* incentive to successfully relay payments And we must avoid creating opportunities for attackers to: * penalize an honest node's relationship with its own honest peers * make routing nodes lose non-negligible funds +* steal money (even tiny amounts) from honest senders +* more easily discover their position in a payment path +* introduce third-party channel closure vectors (e.g Alice closing a channel between Bob and Caroll) ## Proposals Many ideas have been proposed over the years, exploring different trade-offs. We summarize them here with their pros and cons to help future research progress. +## Provable Blaming + +The oldest [proposal](https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-August/000135.html) discusses +to provide proof of channel closures in case of misbehaving peers not failing/succeeding HTLC +quickly. E.g with Alice sending a HTLC to Caroll through Bob, if Caroll doesn't respond within a +short amount of time, Bob should have close his channel with her and present the closing transaction +as a proof to Alice to clear himself from the routing failure. + +This scheme introduces a diverse set of concernes : requirement to understand channel types across +links, privacy breakage, channel frailty, ... + +## Local Reputation Tracking + +This [proposal](https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-May/001232.html) discusses +a reputation system for nodes. A node will keep a real-time accounting of its routing fees earned +thanks to the relayed HTLCs from or to its neighboring peers. After every routing failure, faultive +peer reputation is downgraded until reaching some threshold triggering a channel closure. + +This scheme doesn't prevent reputation contamination. From a node viewpoint, failure of your direct +peer or from upstream peer can't be dissociated. + ### Naive upfront payment The most obvious proposal is to require nodes to unconditionally pay a *fixed* tiny amount to the @@ -281,3 +314,45 @@ Drawbacks: * Small griefing is possible: peers have an incentive to hold HTLCs longer to collect more fees: this is true of all proposals that are based on pay-per-time held where the sender pays the fees * "Exit scam" type of attacks: malicious nodes behave correctly long enough, then launch an attack + +# Adjacent Issues + +Solving channel spamming might help in other corner cases of LN. + +## Costless channel probing + +A node continuously probing channels across the network may discover the payment traffic of routing +nodes and thus globally track LN payment traffic. + +## Watchtower Credit Exhaustion + +Considering the upcoming deployment of public watchtowers, a LN node may have to pay a cost +per-channel update to avoid a watchtower ressource DoS. A malicious counterparty continously +updating a channel may force the victim to exhaust its watchtower credit, thus knocking-out +victim revocation protection. + +If a malicious HTLC sender/relayer have to pay a fixed fee to the victim, it creates a higher +bound on victim watchtower budget. Additional watchtower coverage beyond what this fixed fee +afford has to be paid from victim pocket. + +Eltoo is likely to solve this issue by restraining watchtower per-update resource cost to a +bandwidth one only. + +# Sources + +## Mailing List (chronological order) + +* [https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-August/000135.html Loop attack +* [https://lists.linuxfoundation.org/pipermail/lightning-dev/2016-November/000648.html Analysis: alternative DoS prevention concept] +* [https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-May/001232.html Mitigations for loop attacks] +* [https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-November/002275.html A proposal for upfront payment] +* [https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-February/002547.html A proposal for upfront payment (reverse upfront)] +* [https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002608.html Proof-of-closure as griefing attack mitigation] +* [https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-October/002826.html Hold fees: 402 Payment Required for Lightning itself] + +## Papers + +* [https://arxiv.org/pdf/1904.10253.pdf Discharged Payment Channels: Quantifying the Lightning Network's Resilience to Topology-Based Attacks] +* [https://eprint.iacr.org/2019/1149.pdf LockDown: Balance Availability Attack Against Lightning Network Channels] +* [https://arxiv.org/pdf/2002.06564.pdf Congestion Attacks in Payment Channel Networks] +* [https://arxiv.org/pdf/2004.00333.pdf Probing Channel Balances in the Lightning Network]