Clara Shikhelman [ARCHIVE] on Nostr: đź“… Original date posted:2022-11-03 đź“ť Original message: Hi list, We would like to ...
đź“… Original date posted:2022-11-03
đź“ť Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221103/9ca4e3af/attachment-0001.html>;
đź“ť Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221103/9ca4e3af/attachment-0001.html>;