Hi Clara, Sergei Congrats for the paper!
Here are a few in-flight thoughts browsing the paper. On introducing a general framework for evaluating attack mitigations, I think this is relevant as scarce resources wastes, of which jamming is a subcase is echoed multiple times not only in Lightning, but in multiple other L2 protocols. For Lightning: at channel peer selection, or for any multi-party operation like a dual-funded or splicing, the timevalue of the UTXOs committed can be wasted by a lazy or malicious counterparty. For Coinjoin/Swaps: again UTXO opportunity cost can be wasted, or a swap HTLC holded for nothing. I hold the hope that any solution we can nurture for jamming could be reused and refined in other Bitcoin "decentralized financial networks". On the framework for mitigation evaluation, there are few other dimensions we have considered in the past with Gleb for our research that could be relevant to integrate. One is "centralization", the solution shouldn't centralize sensibly the LN ecosystem around any of its actors: LSP, Lightning Wallet Providers (e.g watchtower or Greenlight-style infra) or routing node, where centralization could be defined in terms of "market entry cost" for new incumbents. "Protocol evolvability" could be another one, as we don't want a solution rendering the design and operations of things like offline-receive, trampoline, negative fees, etc harder. "Ecosystem impacts" was one more category we thought about, e.g introducing a mass mempool congestion vector (one of the versions of Stakes Certificates did it...). For the dimensions of your evaluation framework, the "effectiveness" sounds to be understood as attacker-centric. However few times after in the paper, the viewpoint of the routing nodes sounds to be adopted ("compensating them for the financial damage of jamming", "breakeven point n"). If this distinction is real, the first way would be more searching for a game-theory equilibrium whereas much damage is inflicted to the attacker. The second one would be more to ensure a compensation for the loss income for the routing nodes. I believe the first approach is limited as the attacker's resources could overwhelm the victim's economic sustainability, and rationality might be uneconomic. Maybe those two approaches could be combined, in the sense that loss income compensation should only be borne by "identified" attackers, however this doesn't sound the direction taken by unconditional fees. About "incentive compatibility", one element valuable to integrate is how much the existence of scoring algorithms allows the routing nodes to adopt "honest behaviors" and high-level of service availability. I don't know if a jamming solution can be devised without considerations of the inner workings of routing/scoring algorithms, and so far every LN implementation has its own cooking. On the structure of the monetary strategy, I think there could be a solution to implement a proof-of-burn, where the fee is captured in a commitment output sending to a provably unspendable output. Theoretically, it's interesting as "unburning" the fee is dependent on counterparty cooperation, the one potentially encumbering the jamming risk. Proof-of-work "fee" has been discussed in the past by LN devs, however it was quickly dismissed, as it would give an edge to the attacker who is able to gather ASICs farms while completely burning the batteries of LN mobile clients. It has also been widely discussed to make the fees conditional on either outgoing HTLC CLTV value or effective duration. For effective duration, an upfront fee shard could be paid after each clock tick (either epoch or block-based). On the structure of reputation strategy, I think one interesting missing point to me is the blurring of the local/global reputation definition in Lightning. At least maybe in a way traditionally defined in P2P litterature. Reputation could be enforced on the HTLC sender, as we've aimed with Stakes Certificates. The upstream peer reputation is not accounted for at all. I think it's an open question if the reputation score of a routing node could be exported across nodes (a behavior that one could expect if you assume web-of-trust, as the current LN network topology is heavily based on). On the statement, that attaching reputation to payment contradicts the LN's privacy-focused goal, I would say it's a light one in regards to the state of cryptography tools like blinded signature, known since the 80s. On the analysis of the unconditional fee, I think my main objection would be the lack of integration of the time uncertainty of the honest use-cases, making it hard to classify between quick and slow jamming. As you say "The borderline between quick and slow jamming depends on a subjective definition of the maximal honest payment resolution delay" An attacker should hold all its HTLC jamming for a duration of "maximal honest payment resolution delay" minus 1. Without even scoping L2s protocol like swaps or hold-invoice where the effective duration might hold for a few blocks, modern flows like offline receive where the user has to take manual actions to settle the HTLC could far extend beyond a few seconds. To develop my point, fair compensation could aim for the most optimistic flow of short-held 0.1s payment, however a routing policy could qualify as honest payment resolution delay duration of as much as a few minutes. This discrepancy could be exploited by an attacker to inflict an asymmetric damage to the routing nodes. Of course, one fix could be to scale up the unconditional fee amount in function of the maximal honest payment resolution delay accepted by the routing node policy". I wonder if it would be suitable in terms of UX. For a routing node, there is the uncertainty of downstream payment path hops, responsible for some failures, I don't know if it's currently accounted for in the evaluation of the unconditional fee. If the unconditional fee paid downstream is too high, there is a moral hazard for the routing node, they can pocket the fee, depending how much they're penalized by the sender scoring algorithm. On the analysis of the reputation mechanism, there is one recursive issue: you might constrain the incoming HTLC traffic of your peers, even if they're all honest. Let's say you assign K slots and L satoshis of liquidity to your upstream peer Carioll, Caroll must know divide by (K, L) by two to Alice and Bob, even if Alice and Bob each can offer (K, L) of honest HTLC traffic. Further, there is also the attack timing asymmetries, in the sense that a high-reputation score might have been earned in period of low-congestion, and consumed during period of high-congestion, so it sounds to me reputation should be quantitative rather to introduce a low-risk/high-risk binary framework, to account for proportionality. This proportionality issue is a hard thing, especially if I would like concretely to address payments with intentionally delayed resolutions in a non-cooperative-only way. Lastly, I wonder if there is not some conceptual issue with the chaining of unconditional fee and local reputation. As I understand the distinction between quick/slow jamming is based on this idea of maximal honest payment resolution delay. However, the bypass of this upper bound is only known _after_ the HTLC forward, and as such it sounds to me the strategie regime (unconditional fee/local reputation) under which a HTLC forward should be evaluated is dependent on the knowledge of a future event. Best, Antoine Le jeu. 3 nov. 2022 à 13:25, Clara Shikhelman <clara.shikhel...@gmail.com> a écrit : > Hi list, > > We would like to share with you our recent research on jamming in > Lightning. We propose a combination of unconditional (~ upfront) fees and > local reputation to fight jamming. We believe this can be a basis for an > efficient and practical solution that can be implemented in the foreseeable > future. > > The full paper is available [1]. > > We classify jams into quick (resolve in seconds, mimicking honest > payments) and slow (remain in-flight for hours or days). Fees > disincentivize an attack where quick jams are constantly resolved and sent > again. Reputation, in turn, allows nodes to deprioritize peers who > consistently forward slow jams. > > We believe that our proposal is practical and efficient. In particular, we > have shown that the additional (unconditional) fees can be relatively low > (as low as 2% of the total fee) to fully compensate jamming victims for the > lost routing revenue. Moreover, the total unconditional fee paid for all > failed attempts stays low even if the failure rate is reasonably high. This > means that the UX burden of paying for failed attempts is also low. A > straightforward PoC implementation [2] demonstrates one approach to > implementing the fee-related aspect of our proposal. > > Further sections provide more details on our approach and results. > > # Jamming > > As a reminder, jamming is a DoS attack where a malicious sender initiates > payments (jams) but delays finalizing them, blocking channels along the > route until the jams are resolved. Jamming may target liquidity or payment > slots. > > We distinguish between quick and slow jamming. Quick jamming implies that > jams are failed and re-sent every few seconds, making them hardly > distinguishable from honest failing payments. In slow jamming, jams remain > in-flight for hours. > > # Unconditional fees > > We propose unconditional fees to discourage quick jamming. Currently, jams > are free because routing nodes don’t charge for failed payment attempts. > With unconditional fees, however, jamming is no longer free. > > Our simulations indicate that unconditional fees don’t have to be too > high. Under certain assumptions about the honest payment flow, a fee > increase by just 2% (paid upfront) fully compensates a routing node under > attack. Our simulator is open-source [3]. A PoC implementation demonstrates > one approach to implementing unconditional fees and only requires minor > changes [2]. > > We have also considered the UX implications of paying for failed attempts. > We have concluded that this should not be a deal-breaker, as the total > unconditional fee paid stays low even if the failure rate is reasonably > high (even as high as 50%). Privacy and incentives are also discussed in > the paper. > > # Reputation > > Fees are not very effective in preventing slow jamming: this type of > attack requires only a few jams, therefore, fees would have to be too high > to be effective. Instead, we address slow jamming using local reputation. > > As per our proposal, nodes keep track of their peers’ past behavior. A > routing node considers its peer “good” if it only forwards honest payments > that resolve quickly and bring sufficient fee revenue. A peer that forwards > jams, in contrast, loses reputation. Payments endorsed by a high-reputation > peer are forwarded on the best efforts basis, while other (“high-risk”) > payments can only use a predefined quota of liquidity and slots. Unless the > attacker has built up a reputation in advance, it cannot fully jam a > channel with at least some liquidity allocated exclusively to low-risk > payments. Nodes parameterize their channels according to their risk > tolerance. > > # Alternatives and Future Work > > In this work, we strive for a systematic approach. First, we list five > properties a potential mitigation strategy should have: effectiveness, > incentive compatibility, user experience, privacy and security, and ease of > implementation. Then, we go over the design decisions to be made when > constructing a countermeasure against jamming. Based on the desired > criteria and the available options, we converge on a solution. > > Multiple approaches to jamming mitigation have been discussed on this list > and elsewhere. Many of them may well be worth exploring, such as > resolution-time-dependent fee amounts or stake certificates for reputation > building. However, we believe that our solution strikes a good balance: it > addresses the problem in question and is relatively straightforward to > implement. > > We would love to bring this idea closer to implementation, and we plan to > discuss it over the next spec meeting [4] (Monday, 2022-11-07). We’d > greatly appreciate your feedback! > > Kind regards, > > Sergei and Clara > > [1] - > https://github.com/s-tikhomirov/ln-jamming-simulator/blob/master/unjamming-lightning.pdf > > > [2] - https://github.com/sr-gi/rust-lightning/commit/ce606) > > [3] - https://github.com/s-tikhomirov/ln-jamming-simulator > [4] - https://github.com/lightning/bolts/issues/1038 > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev