Jim Posen [ARCHIVE] on Nostr: 📅 Original date posted:2018-05-15 📝 Original message: > > This can still be ...

📅 Original date posted:2018-05-15
📝 Original message:
>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180515/755f6eaf/attachment-0001.html>;