Clara Shikhelman [ARCHIVE] on Nostr: đź“… Original date posted:2022-11-10 đź“ť Original message: Hi all, We are planning a ...
đź“… Original date posted:2022-11-10
đź“ť Original message:
Hi all,
We are planning a call to discuss this proposal further. It will be on
Monday the 14th, at 7 pm UTC here:
https://meet.jit.si/UnjammingLN
Please let me know if this conflicts with any other Bitcoin event.
Hope to see you all there!
On Thu, Nov 3, 2022 at 1:25 PM Clara Shikhelman <clara.shikhelman at gmail.com>
wrote:
> 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 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/20221110/81c7cd16/attachment-0001.html>;
đź“ť Original message:
Hi all,
We are planning a call to discuss this proposal further. It will be on
Monday the 14th, at 7 pm UTC here:
https://meet.jit.si/UnjammingLN
Please let me know if this conflicts with any other Bitcoin event.
Hope to see you all there!
On Thu, Nov 3, 2022 at 1:25 PM Clara Shikhelman <clara.shikhelman at gmail.com>
wrote:
> 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 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/20221110/81c7cd16/attachment-0001.html>;