From joost.jager at gmail.com Fri Dec 2 17:59:23 2022 From: joost.jager at gmail.com (Joost Jager) Date: Fri, 2 Dec 2022 18:59:23 +0100 Subject: [Lightning-dev] Jamming against Channel Jamming Message-ID: A simple but imperfect way to deal with channel jamming and spamming is to install a lightning firewall such as circuitbreaker [1]. It allows you to set limits like a maximum number of pending htlcs (fight jamming) and/or a rate limit (fight spamming). Incoming htlcs that exceed one of the limits are failed back. Unfortunately there are problems with this approach. Failures probably lead to extra retries which increases the load on the network as a whole. Senders are also taking note of the failure, penalizing you and favoring other nodes that do not apply limits. With a large part of the network applying limits, it will probably work better because misbehaving nodes have fewer opportunities to affect distant nodes. Then it also becomes less likely that limits are applied to traffic coming from well-behaving nodes, and the reputation of routing nodes isn?t degraded as much. But how to get to the point where restrictions are applied generally? Currently there isn?t too much of a reason for routing nodes to constrain their peers, and as explained above it may even be bad for business. Instead of failing, an alternative course of action for htlcs that exceed a limit is to hold and queue them. For example, if htlcs come in at a high rate, they?ll just be stacking up on the incoming side and are gradually forwarded when their time has come. An advantage of this is that a routing node?s reputation isn?t affected because there are no failures. This however may change in the future with fat errors [2]. It will then become possible for senders to identify slow nodes, and the no-penalty advantage may go away. A more important effect of holding is that the upstream nodes are punished for the bad traffic that they facilitate. They see their htlc slots occupied and funds frozen. They can?t coop close, and a force-close may be expensive depending on the number of htlcs that materialize on the commitment transaction. This could be a reason for them to take a careful look at the source of that traffic, and also start applying limits. Limits propagating recursively across the network and pushing bad senders into corners where they can?t do much harm anymore. It?s sort of paradoxical: jamming channels to stop jamming. One thing to note is that routing nodes employing the hold strategy are potentially punishing themselves too. If they are the initiator of a channel with many pending htlcs, the commit fee for them to pay can be high in the case of a force-close. They do not need to sweep the htlcs that were extended by their peer, but still. One way around this is to only use the hold strategy for channels that the routing node did not initiate, and use the fail action or no limit at all for self-initiated channels. Interested to hear opinions on the idea. I?ve also updated circuitbreaker with a queue mode for anyone willing to experiment with it [3]. [1] https://github.com/lightningequipment/circuitbreaker [2] https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-October/003723.html [3] https://github.com/lightningequipment/circuitbreaker/pull/14 -------------- next part -------------- An HTML attachment was scrubbed... URL: