Clara Shikhelman [ARCHIVE] on Nostr: 📅 Original date posted:2023-05-17 🗒️ Summary of this message: The lack of ...
📅 Original date posted:2023-05-17
🗒️ Summary of this message: The lack of transitivity of reputation acquisition cost between hops in a payment path raises a vulnerability issue for the endorsement scheme. Reputation revenue is used to estimate the damage an attacker can create. Dynamic reputation windows may affect payment reliability.
📝 Original message:
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, 10000 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230517/d00db6ae/attachment.html>;
🗒️ Summary of this message: The lack of transitivity of reputation acquisition cost between hops in a payment path raises a vulnerability issue for the endorsement scheme. Reputation revenue is used to estimate the damage an attacker can create. Dynamic reputation windows may affect payment reliability.
📝 Original message:
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, 10000 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230517/d00db6ae/attachment.html>;