Hi Dave & Zeeman,
As the credentials tokens should be blinded during countersigning and then
wrapped inside HTLC onions, the routing hops cannot use them to assign
blame. Instead the jamming attack prevention efficiency relies on
misbehaving senders exhausting their supply of scarce and costly tokens. A
naive blinding should still enable delegation -- Bob can share his Ned's
tokens with Mallory, and she could consume them to waste Ned routing
liquidity. However Bob should have borne the acquisition cost.
This delegation could happen in a trampoline flow, where Bob attaches
on-the-flight his Ned tokens to Alice's HTLC. This naive attachment
shouldn't leak the delegation fact itself to the routing hops.
About the economic relationships between LSPs and their clients, it sounds
effectively possible the token harvesting to be done at the LSP-level,
where over-supply of tokens are resold to the LSP in exchange of other
advantages (e.g discount on JIT channels). This over-supply can be assigned
to newer clients, devoid of credentials token, at condition there is still
a costly bound enforced by the LSP, to avoid a jamming adversary exploiting
the cost asymmetry (e.g presence of channels). This asymmetry exploitation
would be detrimental to the _LSP zone_, not the tokens issuer routing hop,
as the original compensation must have been paid by the LSP.
It should be noted, a reasonable routing policy might be to additionally
reward HTLC on "favorable" incoming links, as a means to incentive the
maintenance of the open link. However this creates asymmetry if the
incoming link operator allows free credential tokens earned by its clients.
On the jamming vectors opened by an adversary having collected a large
stock of tokens, the routing hops should be still economically "safe", as
long as there is a strict equality between the credentials acquisition cost
and the routing fees. E.g wasting liquidity worth 1000 sats of routing fees
should have been compensated by credentials worth 1000 sats, therefore the
routing hops still earn an income. Note, one of the insights of
"staking/reputational" credentials is to pour the original HTLC forwarding
risk on the sender, while making this risk "fine-grained" and "flexible" in
its allocation.
While the routing fees would vary in function of multiple factors (e.g
network-wide channels congestion) the credentials token acquisition cost
should stay identical, otherwise you're offering exploitable asymmetries to
an attacker.
On the argument that jamming would be solved as the attacker has to
sacrifice opportunity costs of its own liquidity, I think such a position
forgets few elements. Such as the fact one channel can tied up liquidity
for many links, jammed channel might have higher return rate than attacker
liquidity due to routing algorithms historical data, the damage inflicted
might be merchant goods themselves far beyond the attacker opportunity
costs, the opportunity cost between attacker and victims might not be
symmetric because the attacker have large liquidity reserves (e.g an
attacker blocking new incumbents).
Best,
Antoine
Le lun. 28 nov. 2022 à 06:50, ZmnSCPxj <zmnsc...@protonmail.com> a écrit :
> 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
>
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
