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 >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
