ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2018-05-16 📝 Original message: Good morning Jim, >> This ...
📅 Original date posted:2018-05-16
📝 Original message:
Good morning Jim,
>> 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.
Hmm, you are indeed correct. Rusty brings up that a rich node can do this to victimize poorer nodes, though: even if the poorer node is compensated for the loss of reputation, the rich node may arrange the network such that it is the only one that can practically earn from forwarding fees, with everyone else suspicious of everyone except the rich node.
There may not be a way to solve this?
>> 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.
Thank you. So:
1. If payment succeeds after T time, upstream reputation is increased by fee earned, downstream reputation is increased by fee earned, downstream reputation is decreased by T * reputation_loss_rate.
2. If payment fails after T time, downstream reputation is decreased by T * reputation_loss_rate.
Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180516/39a69a1e/attachment.html>;
📝 Original message:
Good morning Jim,
>> 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.
Hmm, you are indeed correct. Rusty brings up that a rich node can do this to victimize poorer nodes, though: even if the poorer node is compensated for the loss of reputation, the rich node may arrange the network such that it is the only one that can practically earn from forwarding fees, with everyone else suspicious of everyone except the rich node.
There may not be a way to solve this?
>> 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.
Thank you. So:
1. If payment succeeds after T time, upstream reputation is increased by fee earned, downstream reputation is increased by fee earned, downstream reputation is decreased by T * reputation_loss_rate.
2. If payment fails after T time, downstream reputation is decreased by T * reputation_loss_rate.
Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180516/39a69a1e/attachment.html>;