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 vulnerability issues for the endorsement scheme. Reputation revenue is used to estimate the damage an attacker can create, and sudden changes in links throughput based on HTLC resolution might break the historical liquidity buckets of routing scoring algorithms.
📝 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 vulnerability issues for the endorsement scheme. Reputation revenue is used to estimate the damage an attacker can create, and sudden changes in links throughput based on HTLC resolution might break the historical liquidity buckets of routing scoring algorithms.
📝 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>;