Re: [Lightning-dev] HTLC Endorsement for Jamming Mitigation

[Clara Shikhelman]

Hi,


> The lack of transitivity of the reputation acquisition cost (e.g based on
> historical fees earned from forwards originating from the peer) between the
> hops of the payment path still raises a vulnerability issue for the
> endorsement scheme, I think.
>
> Namely, let's say you have Alice, Bob and Caroll where endorsement has
> been obtained by Alice on the Bob incoming link by paying fees for an
> amount of 1000 sats for the last 100 blocks. Caroll offers a far higher
> pricing on her incoming link from Bob, 1 sats as `fee_base_msat` on her
> endorsed slots. It sounds to me there is nothing preventing Alice from
> sacrificing her earned reputation to inflict a loss of routing fees damage
> on Caroll incoming link ?
>

I think it's important to differentiate between fees a node charges and
*reputation_revenue*. Reputation is determined as a function of the latter.
If Caroll has a very high *reputation_revenue* and Bob has a very low one,
then Bob probably won't have a high reputation with Caroll, as the amount
of fees he forwards to Caroll is smaller than the damage he can create.
That is, if Caroll is a huge node and Bob is a raspberry pi, then Bob will
never have a good reputation with Caroll. If they have similar
*reputation_revenue*, then getting a good reputation with Bob is as
difficult as getting a good reputation with Caroll.

In your example (if I got it correctly) Bob's *reputation_revenue* = 1,000,
*reputation_window*=100 and *routing_window*=10. Could you explain what are
Caroll's parameters are in your example? The *fee_base_msat* does not
indicate Carolls *reputation_revenue* (unless Alice is the only one
transacting on the Bob-Caroll channel, and then she is the one paying for
Bob's reputation).

That being said, we use *reputation_revenue *to estimate the damage an
attacker can create. If there is a chain of nodes that have high reputation
with each other, and they are jammed, they would be compensated for the
revenue lost during the attack. If Bob finds that having a high reputation
with Caroll is crucial and 1,000 sats will not compensate him for loosing
it, then he should either never endorse anything on that channel, or at
least put a higher bar than *reputation_revenue*.

There is an independent new observation on the effect of dynamic reputation
> windows on payment reliability, as those windows are not announced to the
> rest of the network, sudden changes in the links throughput based on HTLC
> resolution might break the historical liquidity buckets of routing scoring
> algorithms (at least in the way we're doing it for LDK), I think ?
>

Not sure what you mean by that.

Best,
Clara

>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] HTLC Endorsement for Jamming Mitigation

[Antoine Riard]

Hi all,

> That is, one cannot gain reputation during low fee times and use it when
fees are high.

> Good reputation is also a function of the general environment, and so if
there is a fee spike, reputation will change. It is true that nodes can go
rogue, but this is why we aim > for the price of a good reputation to be
similar to the amount of damage they can create.

The lack of transitivity of the reputation acquisition cost (e.g based on
historical fees earned from forwards originating from the peer) between the
hops of the payment path still raises a vulnerability issue for the
endorsement scheme, I think.

Namely, let's say you have Alice, Bob and Caroll where endorsement has been
obtained by Alice on the Bob incoming link by paying fees for an amount of
1000 sats for the last 100 blocks. Caroll offers a far higher pricing on
her incoming link from Bob, 1 sats as `fee_base_msat` on her endorsed
slots. It sounds to me there is nothing preventing Alice from sacrificing
her earned reputation to inflict a loss of routing fees damage on Caroll
incoming link ?

Generally, I think the endorsement scheme assumes some synchronicity in the
setting of routing fees by the hops. In practice, it's expected there will
be variations based on their own pricing of liquidity, their accumulated
data sets (e.g historical view of LN gossips) and downstream link topology.
And this is the same between building a mitigation on concepts like
"peace/war" time, sophisticated attackers might be able to mask their
traffic as some spontaneous congestion.

There is an independent new observation on the effect of dynamic reputation
windows on payment reliability, as those windows are not announced to the
rest of the network, sudden changes in the links throughput based on HTLC
resolution might break the historical liquidity buckets of routing scoring
algorithms (at least in the way we're doing it for LDK), I think ?

Best,
Antoine


Le mer. 10 mai 2023 à 16:59, Clara Shikhelman 
a écrit :

> Hi Christian,
>
> Thanks for your comments! We will discuss this further in the upcoming
> call on the 15th, would be great to see you there!
>
>
>> this is an intrinsic issue with reputation systems, and the main
>> reason I'm sceptical w.r.t. their usefulness in lightning.
>> Fundamentally any reputation system bases their expectations for the
>> future on experiences they made in the past, and they are thus always
>> susceptible to sudden behavioral changes (going rogue from a prior
>> clean record) and whitewashing attacks (switching identity, abusing
>> any builtin bootstrapping method for new users to gain a good or
>> neutral reputation before turning rogue repeatedly).
>>
>
> In the Lightning Network, fees are a native way to put a price on having a
> good reputation (see details here [0]). In the design that we suggest, the
> reputation gained today cannot be used in the distant future, and funds
> need to be invested continuously to keep a good reputation. Good reputation
> is also a function of the general environment, and so if there is a fee
> spike, reputation will change. It is true that nodes can go rogue, but this
> is why we aim for the price of a good reputation to be similar to the
> amount of damage they can create.
>
>
>> This gets compounded as soon as we start gossiping about reputations,
>> since now our decisions are no longer based just on information we can
>> witness ourselves, or at least verify its correctness, and as such an
>> attacker can most likely "earn" a positive reputation in some other
>> part of the world, and then turn around and attack the nodes that
>> trusted the reputation shared from those other parts.
>>
>
> Notice that we are not gossiping about our peer's reputation. The only
> thing that a node communicates to its neighbor is whether they see an HTLC
> as endorsed or just neutral, that is, should this HTLC be granted access to
> all of the resources or just the restricted part.
>
>
>> I'd be very interested in how many repeat interactions nodes get from
>> individual senders, since that also tells us how much use we can get
>> out of local-only reputation based systems, and I wouldn't be
>> surprised if, for large routing nodes, we have sufficient data for
>> them to make an informed decision, while the edges may be more
>> vulnerable, but they'd also be used by way fewer senders, and the
>> impact of an attack would also be proportionally smaller.
>>
>
> This is something we hope to learn once we'll start collecting data from
> our brave volunteers :)
>
> Cheers,
> Clara
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev