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
