Hi Antoine, 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. >
Correct. > 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. > Indeed, the more nodes run it, the harder it becomes for attackers to attack. You'd only penalize your own routing node if you send back failures. If you hold the htlc, there is no penalty with the network as it is currently. > 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. > It is true that the limits make it easier to jam a channel, but the theory is that everyone does it, the attacker won't have much reach anymore. > 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. > The economic proportionality is that an attacker can't do much with a severely limited channel, and would need many more to achieve the same effect. I don't think it is possible to eliminate all bad behavior, and that the goal should just be to make it a lot harder than it currently is. Not sure how force-closes come into play. I don't think there needs to be any force-close? I just mentioned them in my original post because they can happen for independent reasons (bug, node offline), and then the size of the commitment tx and number of pending htlcs translates to a real cost. > 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. > Yes, so the main idea that I tried to present is that applying congestion control by holding htlcs may wake up everyone along the path back to the attacker and move them to apply congestion control too. > 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. > It connects to lnd's htlc interceptor and htlc events interfaces. Joost
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
