đź“… 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>;
Antoine Riard [ARCHIVE] /
npub1vj…4x8dd
2023-06-09 13:07:33
in reply to nevent1q…cppy
Author Public Key
npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8ddPublished at
2023-06-09 13:07:33Event JSON
{
"id": "07a0367b0e5ca6aef5e479f8d6f38f6979dd3b778e2c28b41a19b2f99d962ff0",
"pubkey": "6485bc56963b51c9043d0855cca9f78fcbd0ce135a195c3f969e18ca54a0d551",
"created_at": 1686316053,
"kind": 1,
"tags": [
[
"e",
"bf82ea7129b2b27d7e2e9d859ce624a9787a0808534ffd3bb42bfdbb7dcf962d",
"",
"root"
],
[
"e",
"95a7f6329907dfd76e863dd5149434288adba0cb067e8a6f37b9ac0b3ff36985",
"",
"reply"
],
[
"p",
"ec3fb08b335b94aace30d13181f2ad0280df9bc34f1a99832c4e2da8fb125eb3"
]
],
"content": "📅 Original date posted:2022-12-02\n📝 Original message:\nHi Joost,\n\nIf I understand correctly circuitbreaker, it adds new \"dynamic\" HTLC slot\nlimits, in opposition to the \"static\" ones declared to your counterparty\nduring channel opening (within the protocol-limit of 483). On top, you can\nrate-limit the HTLCs forwards based on the incoming source.\n\nEffectively, this scheme would penalize your own routing hop as HTLC\nsenders routing algorithms would likely cause the hop, in the lack of a new\ngossip message advertising the limits/rates. Further, it sounds for the\nmeasure to be robust, a circuitbreaking policy should be applied\nrecursively by your counterparty on their network topologies. Otherwise,\nyou're opening I think you'll have the non-constrained links being targeted\nas entry points in the rate-limited, \"jamming-safe\" subset of the graph.\n\nThe limits could be based on HTLC values, e.g the Xth slots for HTLCs of\nvalue \u003c1k sats, the Yth slots for HTLC of value \u003c100k sats, the remaining\nZth slots for HTLC of value \u003c200k sats. IIRC, this jamming countermeasure\nhas been implemented by Eclair [0] and discussed more in detail here [1].\nWhile it increases the liquidity cost for an attacker to launch jamming\nattacks against the high-value slots, it comes at the major downside of\nlowering the cost for jamming low-value slots. Betting on an increasing\nbitcoin price, all other things equals, we'll make simple payments from\nlambda users more and more vulnerable.\n\nBeyond that, I think this solution would classify in the reputation-based\nfamily of solutions, where reputation is local and enforced through\nrate-limiting (from my understanding), I would say there is no economic\nproportionality enforced between the rate-limiting and the cost for an\nattacker. A jamming attacker could open new channels during period of\nlow-fees in the edges of the graph, and still launch attacks against\ndistant hops by splitting the jamming traffic between many sources,\ntherefore avoiding force-closures (e.g 230 HTLCs from channel Mallory, 253\nHTLCs from channel Malicia). Even force-closure in case of observed jamming\nisn't that evident, as the economic traffic could still be opportunistic\nlocally but only a jam on a distant hop. So I think the economic\nequilibrium and risk structure of this scheme is still uncertain.\n\nHowever, I think the mode of queuing HTLCs is still valuable itself,\nindependently of jamming, either a) to increase routed privacy of HTLC (e.g\n\"delay my HTLC\" option [2]), maybe with double opt-in of both senders/hops\nor b) as a congestion control mechanism where you have \u003e100% of honest\nincoming HTLC traffic and you would like to earn routing fees on all of\nthem, in the limit of what the outgoing CLTV allow you. An advanced idea\ncould be based on statistics collection, sending back-pressure messages or\nHTLC sending scheduling information to the upstream hops. Let's say in the\nfuture we have more periodic payments, those ones could be scheduled in\nperiods of low-congestions.\n\nSo I wonder if we don't have two (or even more) problems when we think\nabout jamming, the first one, the HTLC forward \"counterparty risk\" (the\nreal jamming) and the other one, congestion and scheduling of efficient\nHTLC traffic, with some interdependencies between them of course.\n\nOn experimenting with circuitbreaker, I don't know which HTLC intercepting\ninterface it does expect, we still have a rudimentary one on the LDK-side\nonly supporting JIT channels use-case.\n\nBest,\nAntoine\n\n[0] https://github.com/ACINQ/eclair/pull/2330\n[1] https://jamming-dev.github.io/book/about.html\n[2] https://github.com/lightning/bolts/issues/1008\n[3] https://github.com/lightningdevkit/rust-lightning/pull/1835\n\nLe ven. 2 déc. 2022 à 13:00, Joost Jager \u003cjoost.jager at gmail.com\u003e a écrit :\n\n\u003e A simple but imperfect way to deal with channel jamming and spamming is to\n\u003e install a lightning firewall such as circuitbreaker [1]. It allows you to\n\u003e set limits like a maximum number of pending htlcs (fight jamming) and/or a\n\u003e rate limit (fight spamming). Incoming htlcs that exceed one of the limits\n\u003e are failed back.\n\u003e\n\u003e Unfortunately there are problems with this approach. Failures probably\n\u003e lead to extra retries which increases the load on the network as a whole.\n\u003e Senders are also taking note of the failure, penalizing you and favoring\n\u003e other nodes that do not apply limits. With a large part of the network\n\u003e applying limits, it will probably work better because misbehaving nodes\n\u003e have fewer opportunities to affect distant nodes. Then it also becomes less\n\u003e likely that limits are applied to traffic coming from well-behaving nodes,\n\u003e and the reputation of routing nodes isn’t degraded as much.\n\u003e\n\u003e But how to get to the point where restrictions are applied generally?\n\u003e Currently there isn’t too much of a reason for routing nodes to constrain\n\u003e their peers, and as explained above it may even be bad for business.\n\u003e\n\u003e Instead of failing, an alternative course of action for htlcs that exceed\n\u003e a limit is to hold and queue them. For example, if htlcs come in at a high\n\u003e rate, they’ll just be stacking up on the incoming side and are gradually\n\u003e forwarded when their time has come.\n\u003e\n\u003e An advantage of this is that a routing node’s reputation isn’t affected\n\u003e because there are no failures. This however may change in the future with\n\u003e fat errors [2]. It will then become possible for senders to identify slow\n\u003e nodes, and the no-penalty advantage may go away.\n\u003e\n\u003e A more important effect of holding is that the upstream nodes are punished\n\u003e for the bad traffic that they facilitate. They see their htlc slots\n\u003e occupied and funds frozen. They can’t coop close, and a force-close may be\n\u003e expensive depending on the number of htlcs that materialize on the\n\u003e commitment transaction. This could be a reason for them to take a careful\n\u003e look at the source of that traffic, and also start applying limits. Limits\n\u003e propagating recursively across the network and pushing bad senders into\n\u003e corners where they can’t do much harm anymore. It’s sort of paradoxical:\n\u003e jamming channels to stop jamming.\n\u003e\n\u003e One thing to note is that routing nodes employing the hold strategy are\n\u003e potentially punishing themselves too. If they are the initiator of a\n\u003e channel with many pending htlcs, the commit fee for them to pay can be high\n\u003e in the case of a force-close. They do not need to sweep the htlcs that were\n\u003e extended by their peer, but still. One way around this is to only use the\n\u003e hold strategy for channels that the routing node did not initiate, and use\n\u003e the fail action or no limit at all for self-initiated channels.\n\u003e\n\u003e Interested to hear opinions on the idea. I’ve also updated circuitbreaker\n\u003e with a queue mode for anyone willing to experiment with it [3].\n\u003e\n\u003e [1] https://github.com/lightningequipment/circuitbreaker\n\u003e [2]\n\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-October/003723.html\n\u003e [3] https://github.com/lightningequipment/circuitbreaker/pull/14\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221202/5cdcb76a/attachment-0001.html\u003e",
"sig": "a43f444d392db1d5ba6abc59aa8f670f52722f45905c97f7c1c8dd72748134256ad1a91089018109ddac942f318da3b2da51f9050c72a3f7d8d5304b3415ed6b"
}