Antoine Riard [ARCHIVE] on Nostr: 📅 Original date posted:2023-05-31 🗒️ Summary of this message: The distinction ...
📅 Original date posted:2023-05-31
🗒️ Summary of this message: The distinction between routing fees and reputation revenue is important in the HTLC endorsement model. Compensation for revenue lost during an attack is given to nodes with high reputation. However, there may be issues with the coupling effect between routing scoring algorithms and the introduction of endorsement schemes.
📝 Original message:
> 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*.
I think the distinction you're proposing between routing fees and
reputation revenue matters in the HTLC endorsement model. For the
example I'm using let's say Caroll and Bob share the same exact
parameters, *reputation_revenue* = 1,000, *routing_window*=100 and
*routing_window*=10, where the reputation revenue of Bob towards
Caroll is made from multiple incoming links.
For each HTLC forwarding request issued from Alice, Bob has to make
the decision between refusing Alice HTLC forward over the Caroll
incoming link, and lose an opportunity of fee income, or accept the
HTLC and suffers from a damage if Alice reveals a posteriori as a
jamming attacker.
This is unclear to me how the compensation mechanism works in the
chain of nodes that have high reputation with each other, and I still
think the HTLC endorsement mitigation suffers from the classic issues
of reputation systems (i.e whitewashing).
> Not sure what you mean by that.
I think there is a coupling effec introduced between the historical
liquidity buckets of routing scoring algorithms and the introduction
of endorsment scheme with adjustement of the channel liquidity and
slots in function of local topology reputation.
See the LDK scoring engine comments here :
https://github.com/lightningdevkit/rust-lightning/blob/eec5ec6b50720144fc23503c3ee9c1c8850517ac/lightning/src/routing/scoring.rs#L336
Best,
Antoine
Le mer. 17 mai 2023 à 21:49, Clara Shikhelman <clara.shikhelman at gmail.com>
a écrit :
> 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/20230531/5017e472/attachment.html>;
🗒️ Summary of this message: The distinction between routing fees and reputation revenue is important in the HTLC endorsement model. Compensation for revenue lost during an attack is given to nodes with high reputation. However, there may be issues with the coupling effect between routing scoring algorithms and the introduction of endorsement schemes.
📝 Original message:
> 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*.
I think the distinction you're proposing between routing fees and
reputation revenue matters in the HTLC endorsement model. For the
example I'm using let's say Caroll and Bob share the same exact
parameters, *reputation_revenue* = 1,000, *routing_window*=100 and
*routing_window*=10, where the reputation revenue of Bob towards
Caroll is made from multiple incoming links.
For each HTLC forwarding request issued from Alice, Bob has to make
the decision between refusing Alice HTLC forward over the Caroll
incoming link, and lose an opportunity of fee income, or accept the
HTLC and suffers from a damage if Alice reveals a posteriori as a
jamming attacker.
This is unclear to me how the compensation mechanism works in the
chain of nodes that have high reputation with each other, and I still
think the HTLC endorsement mitigation suffers from the classic issues
of reputation systems (i.e whitewashing).
> Not sure what you mean by that.
I think there is a coupling effec introduced between the historical
liquidity buckets of routing scoring algorithms and the introduction
of endorsment scheme with adjustement of the channel liquidity and
slots in function of local topology reputation.
See the LDK scoring engine comments here :
https://github.com/lightningdevkit/rust-lightning/blob/eec5ec6b50720144fc23503c3ee9c1c8850517ac/lightning/src/routing/scoring.rs#L336
Best,
Antoine
Le mer. 17 mai 2023 à 21:49, Clara Shikhelman <clara.shikhelman at gmail.com>
a écrit :
> 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/20230531/5017e472/attachment.html>;