Antoine Riard [ARCHIVE] on Nostr: đź“… Original date posted:2022-12-02 đź“ť Original message: Hi Joost, If I understand ...
đź“… Original date posted:2022-12-02
đź“ť Original message:
Hi Joost,
If I understand correctly circuitbreaker, it adds new "dynamic" HTLC slot
limits, in opposition to the "static" ones declared to your counterparty
during channel opening (within the protocol-limit of 483). On top, you can
rate-limit the HTLCs forwards based on the incoming source.
Effectively, this scheme would penalize your own routing hop as HTLC
senders routing algorithms would likely cause the hop, in the lack of a new
gossip message advertising the limits/rates. Further, it sounds for the
measure to be robust, a circuitbreaking policy should be applied
recursively by your counterparty on their network topologies. Otherwise,
you're opening I think you'll have the non-constrained links being targeted
as entry points in the rate-limited, "jamming-safe" subset of the graph.
The limits could be based on HTLC values, e.g the Xth slots for HTLCs of
value <1k sats, the Yth slots for HTLC of value <100k sats, the remaining
Zth slots for HTLC of value <200k sats. IIRC, this jamming countermeasure
has been implemented by Eclair [0] and discussed more in detail here [1].
While it increases the liquidity cost for an attacker to launch jamming
attacks against the high-value slots, it comes at the major downside of
lowering the cost for jamming low-value slots. Betting on an increasing
bitcoin price, all other things equals, we'll make simple payments from
lambda users more and more vulnerable.
Beyond that, I think this solution would classify in the reputation-based
family of solutions, where reputation is local and enforced through
rate-limiting (from my understanding), I would say there is no economic
proportionality enforced between the rate-limiting and the cost for an
attacker. A jamming attacker could open new channels during period of
low-fees in the edges of the graph, and still launch attacks against
distant hops by splitting the jamming traffic between many sources,
therefore avoiding force-closures (e.g 230 HTLCs from channel Mallory, 253
HTLCs from channel Malicia). Even force-closure in case of observed jamming
isn't that evident, as the economic traffic could still be opportunistic
locally but only a jam on a distant hop. So I think the economic
equilibrium and risk structure of this scheme is still uncertain.
However, I think the mode of queuing HTLCs is still valuable itself,
independently of jamming, either a) to increase routed privacy of HTLC (e.g
"delay my HTLC" option [2]), maybe with double opt-in of both senders/hops
or b) as a congestion control mechanism where you have >100% of honest
incoming HTLC traffic and you would like to earn routing fees on all of
them, in the limit of what the outgoing CLTV allow you. An advanced idea
could be based on statistics collection, sending back-pressure messages or
HTLC sending scheduling information to the upstream hops. Let's say in the
future we have more periodic payments, those ones could be scheduled in
periods of low-congestions.
So I wonder if we don't have two (or even more) problems when we think
about jamming, the first one, the HTLC forward "counterparty risk" (the
real jamming) and the other one, congestion and scheduling of efficient
HTLC traffic, with some interdependencies between them of course.
On experimenting with circuitbreaker, I don't know which HTLC intercepting
interface it does expect, we still have a rudimentary one on the LDK-side
only supporting JIT channels use-case.
Best,
Antoine
[0] https://github.com/ACINQ/eclair/pull/2330
[1] https://jamming-dev.github.io/book/about.html
[2] https://github.com/lightning/bolts/issues/1008
[3] https://github.com/lightningdevkit/rust-lightning/pull/1835
Le ven. 2 déc. 2022 à 13:00, Joost Jager <joost.jager at gmail.com> a écrit :
> 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
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221202/5cdcb76a/attachment-0001.html>;
đź“ť Original message:
Hi Joost,
If I understand correctly circuitbreaker, it adds new "dynamic" HTLC slot
limits, in opposition to the "static" ones declared to your counterparty
during channel opening (within the protocol-limit of 483). On top, you can
rate-limit the HTLCs forwards based on the incoming source.
Effectively, this scheme would penalize your own routing hop as HTLC
senders routing algorithms would likely cause the hop, in the lack of a new
gossip message advertising the limits/rates. Further, it sounds for the
measure to be robust, a circuitbreaking policy should be applied
recursively by your counterparty on their network topologies. Otherwise,
you're opening I think you'll have the non-constrained links being targeted
as entry points in the rate-limited, "jamming-safe" subset of the graph.
The limits could be based on HTLC values, e.g the Xth slots for HTLCs of
value <1k sats, the Yth slots for HTLC of value <100k sats, the remaining
Zth slots for HTLC of value <200k sats. IIRC, this jamming countermeasure
has been implemented by Eclair [0] and discussed more in detail here [1].
While it increases the liquidity cost for an attacker to launch jamming
attacks against the high-value slots, it comes at the major downside of
lowering the cost for jamming low-value slots. Betting on an increasing
bitcoin price, all other things equals, we'll make simple payments from
lambda users more and more vulnerable.
Beyond that, I think this solution would classify in the reputation-based
family of solutions, where reputation is local and enforced through
rate-limiting (from my understanding), I would say there is no economic
proportionality enforced between the rate-limiting and the cost for an
attacker. A jamming attacker could open new channels during period of
low-fees in the edges of the graph, and still launch attacks against
distant hops by splitting the jamming traffic between many sources,
therefore avoiding force-closures (e.g 230 HTLCs from channel Mallory, 253
HTLCs from channel Malicia). Even force-closure in case of observed jamming
isn't that evident, as the economic traffic could still be opportunistic
locally but only a jam on a distant hop. So I think the economic
equilibrium and risk structure of this scheme is still uncertain.
However, I think the mode of queuing HTLCs is still valuable itself,
independently of jamming, either a) to increase routed privacy of HTLC (e.g
"delay my HTLC" option [2]), maybe with double opt-in of both senders/hops
or b) as a congestion control mechanism where you have >100% of honest
incoming HTLC traffic and you would like to earn routing fees on all of
them, in the limit of what the outgoing CLTV allow you. An advanced idea
could be based on statistics collection, sending back-pressure messages or
HTLC sending scheduling information to the upstream hops. Let's say in the
future we have more periodic payments, those ones could be scheduled in
periods of low-congestions.
So I wonder if we don't have two (or even more) problems when we think
about jamming, the first one, the HTLC forward "counterparty risk" (the
real jamming) and the other one, congestion and scheduling of efficient
HTLC traffic, with some interdependencies between them of course.
On experimenting with circuitbreaker, I don't know which HTLC intercepting
interface it does expect, we still have a rudimentary one on the LDK-side
only supporting JIT channels use-case.
Best,
Antoine
[0] https://github.com/ACINQ/eclair/pull/2330
[1] https://jamming-dev.github.io/book/about.html
[2] https://github.com/lightning/bolts/issues/1008
[3] https://github.com/lightningdevkit/rust-lightning/pull/1835
Le ven. 2 déc. 2022 à 13:00, Joost Jager <joost.jager at gmail.com> a écrit :
> 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
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221202/5cdcb76a/attachment-0001.html>;