Joost Jager [ARCHIVE] on Nostr: 📅 Original date posted:2020-10-24 📝 Original message: Hi Bastien, I brought up ...
📅 Original date posted:2020-10-24
📝 Original message:
Hi Bastien,
I brought up the question about the amounts because it could be that
>> amounts high enough to thwart attacks are too high for honest users or
>> certain uses.
>
>
> I don't think this is a concern for this proposal, unless there's an
> attack vector I missed.
> The reason I claim that is that the backwards upfront payment can be made
> somewhat big without any
> negative impact on honest nodes.
>
Yes, that makes sense.
> But what happens if the attacker is also on the other end of the
>> uncontrolled spam payment? Not holding the payment, but still collecting
>> the forward payments?
>
>
> That's what I call short-lived `controlled spam`. In that case the
> attacker pays the forward fee at
> the beginning of the route but has it refunded at the end of the route. If
> the attacker doesn't
> want to lose any money, he has to release the HTLC before the grace period
> ends (which is going to
> be short-lived - at least compared to block times). This gives an
> opportunity for legitimate payments
> to use the HTLC slots (but it's a race between the attacker and the
> legitimate users).
>
I think indeed that this short-lived controlled spam also needs to be
brought under control. Otherwise it is still easy to jam a channel,
although it would need a continuous process to do it rather than sending a
bunch of 2000-block expiry htlcs. For the short-lived controlled spam there
is still a multiplier possible by making loops in the route. It is a race
with legitimate users, but if the spammer is efficient the probability of a
legitimate payment coming through is low. Similar to DDoS attacks where a
legitimate web request could make it to the server but probably doesn't.
> It's not ideal, because the attacker isn't penalized...the only way I
> think we can penalize this
> kind of attack is if the forward fee decrements at each hop, but in that
> case it needs to be in the
> onion (to avoid probing) and the delta needs to be high enough to actually
> penalize the attacker.
> Time to bikeshed some numbers!
>
So in your proposal, an htlc that is received by a routing node has the
following properties:
* htlc amount
* forward up-front payment (anti-spam)
* backward up-front payment (anti-hold)
* grace period
The routing node forwards this to the next hop with
* lower htlc amount (to earn routing fees when the htlc settles)
* lower forward up-front payment (to make sure that an attacker at the
other end loses money when failing quickly)
* higher backward up-front payment (to make sure that an attacker at the
other end loses money when holding)
* shorter grace period (so that there is time to fail back and not lose the
backward up-front payment)
On a high level, it seems to me that this can actually work.
- Joost
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201024/2d303022/attachment.html>;
📝 Original message:
Hi Bastien,
I brought up the question about the amounts because it could be that
>> amounts high enough to thwart attacks are too high for honest users or
>> certain uses.
>
>
> I don't think this is a concern for this proposal, unless there's an
> attack vector I missed.
> The reason I claim that is that the backwards upfront payment can be made
> somewhat big without any
> negative impact on honest nodes.
>
Yes, that makes sense.
> But what happens if the attacker is also on the other end of the
>> uncontrolled spam payment? Not holding the payment, but still collecting
>> the forward payments?
>
>
> That's what I call short-lived `controlled spam`. In that case the
> attacker pays the forward fee at
> the beginning of the route but has it refunded at the end of the route. If
> the attacker doesn't
> want to lose any money, he has to release the HTLC before the grace period
> ends (which is going to
> be short-lived - at least compared to block times). This gives an
> opportunity for legitimate payments
> to use the HTLC slots (but it's a race between the attacker and the
> legitimate users).
>
I think indeed that this short-lived controlled spam also needs to be
brought under control. Otherwise it is still easy to jam a channel,
although it would need a continuous process to do it rather than sending a
bunch of 2000-block expiry htlcs. For the short-lived controlled spam there
is still a multiplier possible by making loops in the route. It is a race
with legitimate users, but if the spammer is efficient the probability of a
legitimate payment coming through is low. Similar to DDoS attacks where a
legitimate web request could make it to the server but probably doesn't.
> It's not ideal, because the attacker isn't penalized...the only way I
> think we can penalize this
> kind of attack is if the forward fee decrements at each hop, but in that
> case it needs to be in the
> onion (to avoid probing) and the delta needs to be high enough to actually
> penalize the attacker.
> Time to bikeshed some numbers!
>
So in your proposal, an htlc that is received by a routing node has the
following properties:
* htlc amount
* forward up-front payment (anti-spam)
* backward up-front payment (anti-hold)
* grace period
The routing node forwards this to the next hop with
* lower htlc amount (to earn routing fees when the htlc settles)
* lower forward up-front payment (to make sure that an attacker at the
other end loses money when failing quickly)
* higher backward up-front payment (to make sure that an attacker at the
other end loses money when holding)
* shorter grace period (so that there is time to fail back and not lose the
backward up-front payment)
On a high level, it seems to me that this can actually work.
- Joost
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201024/2d303022/attachment.html>;