ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2022-11-28 📝 Original message: Good morning David, > On ...

📅 Original date posted:2022-11-28
📝 Original message:
Good morning David,

> On 2022-11-25 13:12, ZmnSCPxj via Lightning-dev wrote:
>
> > If I am an LSP, and I know my competitor LSP distributes their
> > credentials, then I can simply apply to be a spoke on my competitor
> > and then make several payments to my node, which I then jam up.
> > This reduces the reputation of my competitor LSP.
>
>
> I don't think this how Riard's credentials work. The credential tokens
> are blinded, so forwarding nodes can't use them to determine the origin
> of the payment---thus they can't assign blame.
>
> As I understand them, credential tokens prevent DoS by each token only
> allowing the one-time creation of a single HTLC, so any failed payment
> reduces the sender's supply of tokens. That means, if Mallory becomes a
> client of Bob's and Bob lets Mallory use some of his tokens, Mallory can
> destroy those tokens. Although that's bad for Bob, he can easily limit
> the damage by not giving Mallory more tokens after too many failures.
> If Bob obtained his tokens at a low cost (e.g. by sending many payments
> that were successful and receiving back >100% of the tokens he used to
>
> make those payments) and if Alice has to pay a similar or greater cost
> to become a client of Bob's (e.g. onchain channel open costs), then the
> attack should not be economically rational.

The usual response is to subsequently attack the mitigation, this is a general technique that works on pretty much anything.

Mallory can run multiple nodes.
Mallory can then initially buy a small number of tokens.
Then Mallory sends payments back and forth ensuring success, receiving back >100% tokens used.
This gives Mallory a large number of tokens.

Finally, Mallory launches a wide attack on the network by using its harvested tokens (from the >100% token return from successful payment resolution), trading off reputation for whatever they might gain by attacking the LN.

Unless forwarding nodes charge a large fee on successful resolution of payments, such that the >100% return on tokens is equal to the cost of buying the extra tokens "fresh", then this makes launching the attack cheaper.


> > Thus all reputation still rests with ultimate senders, who have to
> > convince LSPs to sell their reputation to them, because they might
> > secretly be competitor LSPs who have incentive to drain their
> > reputation.
> >
> > If the price of sold reputation is too high, then it is no different
> > from upfront fees.
> >
> > If the price of sold reputation is too low, then I can drain the
> > reputation of competitor LSPs.
>
>
> I think the statement at the top about reputation resting with ultimate
> senders is true but two conditionals below it are not quite right. If
> an LSP helps many clients make successful payments, those clients may
> (at no additional cost to them beyond the forwarding fees they already
> paid) receive more credential tokens than they'll ever need. By
> allowing the LSP to instead use those tokens for other clients
> ("harvesting" them), it's possible for those later clients to avoid
> paying for credential tokens---this is equivalent to free upfront fees.
> As long as the LSP can prevent a client from using too many tokens, and
> requires the client pay other inescapable costs, then it shouldn't be
> possible for a competitor to substantially drain the token capital of a
> LSP without losing a substantial amount of its own money.

It is helpful to consider that jamming attacks require that jamming attackers tie up their funds on Lightning too.
So while a jamming attacker can impose opportunity costs on the rest of the network, it also sacrifices opportunity to instead use the same funds in forwarding.
Thus a jamming attacker can impose costs on others by also losing a substantial amount (in terms of lost opportunity to instead use the same locked funds to earn forwarding fees), meaning that if you are going to make that argument, then the original problem was already solved by its own structure.

Regards,
ZmnSCPxj