Joost Jager [ARCHIVE] on Nostr: 📅 Original date posted:2020-10-23 📝 Original message: > > It is interesting ...

📅 Original date posted:2020-10-23
📝 Original message:
>
> It is interesting that the forward and backward payments are relatively
>> independent of each other
>
>
> To explain this further, I think it's important to highlight that the
> forward fee is meant to fight
> `uncontrolled spam` (where the recipient is an honest node) while the
> backward fee is meant to fight
> `controlled spam` (where the recipient also belongs to the attacker).
>

Yes, that was clear. I just meant to say that we could choose to first only
implement the easier uncontrolled spam protection via the forward payment.
Not that any type of protocol upgrade is easy...

What I'd really like to explore is whether there is a type of spam that I
> missed or griefing attacks
> that appear because of the mechanisms I introduce. TBH I think the
> implementation details (amounts,
> grace periods and their deltas, when to start counting, etc) are things
> we'll be able to figure out
> collectively later.
>

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. If that is the case, we don't need to look for other
potential weaknesses. It is just a different order to explore the
feasibility of the proposal.

The forward payment can indeed be small, because uncontrolled spam can only
be in-flight for a short time. To get to that annual return of 5% on a 1
BTC / 483 slot channel, it needs to be approx 1 sat/hour (if I calculated
that correctly). Let's say the spam payment is in-flight on average 30
seconds on a 20 route hop (60 sec at the start, 0 sec at the end). The
total "damage" would then be 600 hop-seconds, requiring a forward payment
of 150 msat to cover that. Still seems acceptable to me. If an honest
user makes a payment and needs 10 attempts, they will pay an additional 1.5
sats for that. Might be a ux-challenge to communicate that cost to a normal
user for a failed payment though.

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?

For the backward payment the pricing is different. The max expiry of the
htlc is 2000 blocks, 1000 blocks on average along the route. 1000 blocks is
about 160 hours. So ideally the attacker at the far end of the route should
pay 20 * 160 * 1sat/hr = 3200 sat. This will also be the cost for a hold
invoice then, but not everybody liked them anyway. The net cost for a
regular (fast) payment will be nothing as you described.

- Joost

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201023/ebe76cd3/attachment.html>;