> > This can still be manipulated if Rusty1 opens a direct channel to Jim. > Then Rusty1 can route payments Rusty1->Jim->Rusty2 that succeed quickly, > then route payments Rusty1->ZmnSCPxj->Jim->Rusty2 that stall. Thus Rusty2 > can have the Jim->Rusty2 reputation boosted, while alternating with > reputation losses that make ZmnSCPxj->Jim reputation go down. Since local > reputation is used, ZmnSCPxj and Jim will not talk to each other about how > Rusty2 seems to stall when not routing a payment from Rusty1. Rusty1 can > now manipulate the reputation view of ZmnSCPxj and Jim of each other while > keeping Rusty2 reputation somewhat high. >
Yes, you are correct that in scenarios like this an attacker can pay to degrade the reputation of one of its peers (or even nodes further away). The key point is that doing so should be costly to the attacker because they must pay the victim node to continue making itself vulnerable to payment delays. But if the node is getting compensated, is that really an attack then? This system is designed with the assumption that the best way to defend an anonymous/decentralized network that allows sybils is by pricing resource utilization appropriately. In a similar way, the Bitcoin blockchain is "vulnerable" to spam attacks in the sense that attackers can pay to fill up block space. > As mentioned, the CLTV total leaks information on how far the payee is. I > might decide to keep track of a reputation score, not of the local peers I > have, but on the entire network. If the CLTV total at my outgoing is high, > then if the outgoing HTLC takes a long time to respond, I will distribute a > small reputation loss to a large number of nodes that are accessible from > the outgoing channel; if the CLTV total at my outgoing is low, I will > distribute a large reputation loss to a small number of nodes that are > accessible from the outgoing channel. I now have the incentive to make > this estimation even more accurate in the future. > One could do this today. I'd even argue that they are incentivized to already as a protection against loop attacks/payment delays. But it's likely a pretty ineffective strategy depending on the number of channels that the possible downstream hops have open. Please describe the below: > > 1. Behavior if payment succeeds after T time. > 2. Behavior if payment fails after T time. > > It seems you only described "Behavior if payment succeeds after T time". > Ah, sorry if I didn't make that clear. The reputation is increased in the case of successful payments by the fee collected. The reputation is decreased on the downstream peer proportional to time T *regardless* of whether the payment succeeds or fails. If a payment succeeds quickly, the increase should outweigh the decrease, but if the payment succeeds after a long time, the change in reputation may be net negative. If the payment fails, the upstream peer's reputation does not change and the downstream peer's reputation always decreases proportional to time T.
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev