Precise threat model, mitigation, add sources (#4)

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
+It is not possible today to fully prevent this type of attacks, but we can make the attacker's job
-can help partially mitigate them:
+harder by properly configuring channels:
 
-* use a reasonable value for `htlc_minimum_msat` (1 sat is **not** a reasonable value for channels
+* the attacker needs to lock at least `htlc_minimum_msat * max_accepted_htlcs` of his own funds to
-  with a big capacity; it may be ok for small channels though)
+  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 as routing node
-* minimal (reasonable) barrier to entry
 * 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]