Joost Jager [ARCHIVE] on Nostr: đź“… Original date posted:2022-12-02 đź“ť Original message: A simple but imperfect ...
đź“… Original date posted:2022-12-02
đź“ť Original message:
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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221202/9059931a/attachment.html>;
đź“ť Original message:
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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221202/9059931a/attachment.html>;