Clara Shikhelman [ARCHIVE] on Nostr: đź“… Original date posted:2022-11-15 đź“ť Original message: Thanks to everyone that ...
đź“… Original date posted:2022-11-15
đź“ť Original message:
Thanks to everyone that came to the meeting, it was a great conversation
and gave us a lot to think about!
Matt – I don't know that I agree with "... upfront payments kinda kill the
lightning UX ...". I think that upfront fees are almost essential, even
outside the context of jamming. This also helps with probing, general spam,
and other aspects. Furthermore, I think that the UX is very explainable,
and in general nodes shouldn't be motivated to send a lot of failed
payments, and should adopt better routing strategies.
About Rusty's suggestions, I plan to look at it again, but if I
remember correctly, there are privacy issues there.
I agree that we should tread carefully and not rush into things, let's keep
discussing this. I'll try to set up another meeting sometime soon.
On Mon, Nov 14, 2022 at 4:39 PM Matt Corallo <lf-lists at mattcorallo.com>
wrote:
> Thanks for committing all the time today. I’m much happier with (binary,
> not-so-)local reputation than I was in the past, at least as better than
> other reputation systems.
>
> I believe you’ve stated a few times that local reputation by itself is far
> from sufficient and that’s why we need upfront payments. Intuitively this
> makes sense to me but I’m sure you have more data to back that up. It’s
> come up a few times that upfront payments kinda kill the lightning UX if
> they’re at all nontrivial. Just restating here to make sure we’re on the
> same page.
>
> One thing I think we need to research more is how this compares to Rusty’s
> old proof-of-channel-closure idea. Philosophically it’s quite nice to
> punish the one holding an HTLC over punishing the sender, especially in a
> world where people are getting options in USD<->BTC through HTLCs or
> sending to mobile nodes that sit on payments. Practically I’m not sure if
> there’s a strong need to worry about a large hub sitting on HTLCs to jam
> instead of a sender being involved, but having zero mitigation against it
> also seems wrong.
>
> As always I’m a bit dubious of doing something, especially that required
> network-wide upgrade, until we’re confident it’s the right direction. Even
> binary HTLC reputation flags, I think, carry a very large privacy cost so
> it’s strongly worth exploring every alternative before we commit.
>
> Matt
>
> On Nov 10, 2022, at 10:35, Clara Shikhelman <clara.shikhelman at gmail.com>
> wrote:
>
> 
> 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
>>
> _______________________________________________
> 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/20221115/e71ebd57/attachment-0001.html>;
đź“ť Original message:
Thanks to everyone that came to the meeting, it was a great conversation
and gave us a lot to think about!
Matt – I don't know that I agree with "... upfront payments kinda kill the
lightning UX ...". I think that upfront fees are almost essential, even
outside the context of jamming. This also helps with probing, general spam,
and other aspects. Furthermore, I think that the UX is very explainable,
and in general nodes shouldn't be motivated to send a lot of failed
payments, and should adopt better routing strategies.
About Rusty's suggestions, I plan to look at it again, but if I
remember correctly, there are privacy issues there.
I agree that we should tread carefully and not rush into things, let's keep
discussing this. I'll try to set up another meeting sometime soon.
On Mon, Nov 14, 2022 at 4:39 PM Matt Corallo <lf-lists at mattcorallo.com>
wrote:
> Thanks for committing all the time today. I’m much happier with (binary,
> not-so-)local reputation than I was in the past, at least as better than
> other reputation systems.
>
> I believe you’ve stated a few times that local reputation by itself is far
> from sufficient and that’s why we need upfront payments. Intuitively this
> makes sense to me but I’m sure you have more data to back that up. It’s
> come up a few times that upfront payments kinda kill the lightning UX if
> they’re at all nontrivial. Just restating here to make sure we’re on the
> same page.
>
> One thing I think we need to research more is how this compares to Rusty’s
> old proof-of-channel-closure idea. Philosophically it’s quite nice to
> punish the one holding an HTLC over punishing the sender, especially in a
> world where people are getting options in USD<->BTC through HTLCs or
> sending to mobile nodes that sit on payments. Practically I’m not sure if
> there’s a strong need to worry about a large hub sitting on HTLCs to jam
> instead of a sender being involved, but having zero mitigation against it
> also seems wrong.
>
> As always I’m a bit dubious of doing something, especially that required
> network-wide upgrade, until we’re confident it’s the right direction. Even
> binary HTLC reputation flags, I think, carry a very large privacy cost so
> it’s strongly worth exploring every alternative before we commit.
>
> Matt
>
> On Nov 10, 2022, at 10:35, Clara Shikhelman <clara.shikhelman at gmail.com>
> wrote:
>
> 
> 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
>>
> _______________________________________________
> 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/20221115/e71ebd57/attachment-0001.html>;