Good morning,
>> But I can make you look like a delaying node whenever I want. The only
>> way to ensure that I lose more reputation than you do is to leak
>> information about route length for *everyone*. And even then, it's just
>> a matter of numbers. I can make successful payments to myself through
>> the same peers (but not you!) to stay above their threshold so my
>> reputation is intact.
>>
>> So it's basically a question of how expensive is it for me to throw you
>> off the network? You have to tune that number carefully.
>
> Remember, reputation is local to each node, so the only way you can raise
> your reputation with me is by participating in successful circuits *with me*.
> If you route successful payments on circuits with other peers, you may raise
> your reputation with them, but will do nothing to convince me to send more
> payments through you. So it is not true that you can make me look like a
> delaying node whenever you want; after a few bad interactions, I will stop
> routing through you until you participate in enough successful payments *with
> me* as the downstream to earn back your reputation.
>
> I agree this number needs to be tuned carefully, but ideally this (the
> reputation rate loss) is something that can be tuned individually by routers
> according to their risk tolerance and history of attacks on the network. I
> think it's far preferable to have a number that can be tuned in the face of
> DoS attacks than being caught with no protection whatsoever.
Consider the below network:
.Rusty1
. |
. v
.ZmnSCPxj->Jim
. | /
. v L
. Rusty2
Rusty1 can make me think highly of Rusty2, by routing many payments to Rusty2
which Rusty2 immediately accepts/forwards. Then Rusty1 can make me think lowly
of Jim, by forwarding payments via Jim to Rusty2, and having Rusty2 delay the
payment so that Jim loses reputation badly. Then in the future unrelated
forwards that would have passed through ZmnSCPxj->Jim will be rejected by me
because I think Jim has low reputation.
This holds even if local reputation is used.
Jim argues that this is unimportant, since (assuming all HTLC values are almost
equal) Jim will stop forwarding to Rusty2 (due to imposing a higher "reputation
loss rate" on Rusty2 than I impose in Jim) before I stop forwarding to 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.
>> But we're busy trying to remove all the methods of deanonymizing the
>> network, and you seem to be adding a new one, *and* providing an
>> incentive to deanonymize.
>>
>> Yes, which is why we have mitigations in place (which are still probably
>> insufficient). I really don't want to add another vector.
>
> This gets to the heart of the tradeoff between network efficiency and
> privacy. I admit that my proposal sacrifices on privacy, and I personally
> find it acceptable given the added protection against DoS attacks, but I
> understand the counterargument as well.
>
> One additional thing to consider, though, is that if DoS attacks are
> problematic and there is no protection, many nodes may stop routing payments
> entirely. Onion routing through a network with very few possible circuits
> certainly is less private than revealing additional circuit information on a
> decentralized routing network.
>
>> So now I'll try to deanonymize all payments so I can determine this.
>> Those who do this best will be rewarded, and those who don't try will be
>> knocked off the network, probably by those who can!
>
> I'm not following, how are you deanonymizing payments? Having more
> information about downstream hops can help one make better routing decisions,
> but if the reputation system works properly, you should only need to care
> about the reputation of the next hop.
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.
>
>
>> So I'd like to see a real design of the reputation system. If it's
>> practical (which is a significant hurdle), we then need to carefully
>> evaluate whether we're creating significant disincentives to
>> neighbourliness.
>
> I tried to mostly describe the design in the first email, but it's kind of
> disorganized. I'll try to sketch it out here more succinctly.
>
> Each node has a local configuration of its "reputation loss rate" per channel
> in units of Hz. This configured rate is not explicitly advertised to peers.
> Each update_add_htlc has an additional field the "reputation loss rate" in
> units of satoshis per second, calculated as the reputation loss rate of the
> upstream HTLC plus the local reputation loss rate times the offered HTLC
> value. This value can be obfuscated somewhat by the origin of the payment and
> at each hop with some amount of noise, subject to the concerns raised in my
> discussion with ZmnSCPxj. When forwarding an HTLC, the upstream hop measures
> the elapsed time between delivery of a commitment signature on the add and
> receipt of the fail/update.
>
> For each peer node, keep a reputation score in units of satoshis. For each
> peer, when a payment completes where they are the upstream or downstream hop,
> add the amount collected in fees to their reputation score. For each payment
> where they are the downstream hop, subtract from their reputation score the
> reputation loss rate on the offered HTLC times its elapsed time. Reputation
> score is not explicitly shared between peered nodes, but can be estimated to
> within differences in elapsed time measurements.
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".
Regards,
ZmnSCPxj_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
