> > You're forgetting the failure cases, where now I can profit. > > If I disconnect from another node, I now have a disincentive to tell > others. At the moment we send an update disabling the channel (though > we should give a few seconds for reconnect first, but whatever). > > Similarly, the rewards aren't proportional: being cheaper than other > routes gets you all the traffic, but now you profit even if you can't > service the payments. In fact, once a channel becomes hard to use (low > capacity, transient disconnect, whatever), I *should* advertize it as > cheaper route than anyone else: free money! > > I'm sure there are other ways to game it, but the underlying reason is > clear: it misaligns user and node incentives.
If the system is sufficiently decentralized, managing to cheat everyone > once is very profitable though. > I still don't agree with the conclusion. What are the incentives currently for a node to advertise disabled channels? Firstly, it reduces computational effort of performing an unnecessary channel update. The main incentive though is that it is the recommended spec compliant behavior, and makes the link appear more reliable to the sender. I think this has to be analyzed as a repeated game, where senders will prefer links that not only advertise lower fees, but have a history of being reliable (or at least don't have a history of being unreliable). So with a fee of 0 on failed payments, we think that there's probably sufficient reason for nodes to advertise when channels are disabled. I'll grant, obviously, that if that there is high fee on failed payments that it would create incentive problems, but not if the unconditional fee is low enough. Note also the unconditional fee is also visible to senders, who will choose not to route through such links for this exact reason. So your example of a node advertising cheap fees on disabled links, it would only make sense to lower the success-conditional fee, not the unconditional fee. Ultimately, I think this will reach an equilibrium assuming senders have good route selection algorithms. Now, that said, if this unconditional fee were the only (or even main) protection against loop attacks, it would probably require them to be so high as to create incentive problems. I am proposing the unconditional fee as a spam fee to punish senders who just send a bunch of failing payments in order to collect routing information, and put load on the network in the process for no good reason. With this as the purpose, I think this unconditional spam fee can be low enough to avoid the issues you raise. One of my beliefs in structuring incentives it that it's far more acceptable for senders to get cheated by nodes they route through than for routers to be attacked. The reason is that senders collect a lot more information in failure cases and can avoid repeated occurrences by selecting routes differently. Routers, on the other hand, have far more limited information and choices and their operation is critical to the efficiency and decentralization of the system, so they should be protected by the protocol to a greater degree. > 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. 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. > 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. When you receive an HTLC to be forwarded to some downstream node, compare their current reputation score with the offered reputation loss rate times 10 minutes times the CLTV on the HTLC. If their reputation is sufficient, forward the HTLC and place a hold on their total reputation for that amount (so that concurrently forwarded HTLCs can't exceed their reputation "balance"). New, unknown, peers should get some initial reputation, presumably greater for channels that one initiates vs channels one receives.
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
