Jim Posen <jim.po...@gmail.com> writes: > Thanks for the thoughtful responses. > >> You missed the vital detail: that you must prove channel closure if you >> can't unpeel the onion further. That *will* hit an unresponsive party >> with a penalty. > > Ah, that is a good point. I still find the proposal overall worryingly > complex in terms of communication overhead, time it takes to prove channel > closure, all of your points in [1], [2], [3], etc. Furthermore, this > mandates that immediate channel closure is the only allowed reaction to a > party delaying an HTLC for a time period above a threshold -- the node > reputation approach gives more discretion to the preceding hop. > Deobfuscating the route may turn out to be the right option, but I think > the reputation system has certain advantages over this.
Agreed, it's a tradeoff. >> The models we tried in Milan all created an incentive to fail payments, >> which is a non-starter. > > Do you mind elaborating or summarizing the reasons? The way I'm analyzing > it, even if there's a nominal spam fee paid to routing nodes that fail > payments, as long as it's low enough (say 2-5% for arguments sake), the > nodes still have more to gain by forwarding the payment and earning the > full fee on a completed payment, and possibly the reputation boost > associated with completing a payment if that system was in effect. 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. > Moreover, a node that constantly fails payments will be blacklisted by the > sender eventually and stop receiving HTLCs from them at all. Overall, I > don't think this is a profitable strategy. Furthermore, I think it works > quite well in combination with the reputation system. If the system is sufficiently decentralized, managing to cheat everyone once is very profitable though. >> This seems like we'd need some serious evaluation to show that this >> works, because the risks are very high. > > I agree that it needs to be evaluated. I may start working on some network > simulations to test various DOS mitigation strategies. > >> I can destroy your node's reputation by routing crap through you; even >> if it costs me marginaly more reputation than it does you, that just >> means that the largest players can force failure upon smaller players, >> centralizing the network. And I think trying to ensure that it costs me >> more reputation than the sum of downstream reputation loss leaks too >> much information > > I will add to ZmnSCPxj's response, which is mostly on point. The key here > is that the only way to lose significant reputation is to delay a payment > yourself or forward to a malicious downstream that delays -- neither of > these can be forced by the sender alone. This amounts to a system where you > are on the hook for any malicious behavior of your downstream peers, which > is why you must keep a reputation score for each which they earn over time. > This should keep all links in the network high quality and quickly > disconnect off delaying nodes if the incentives are right. 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. > While I agree that a lot of reputation is leaked by aggregating the losses > along the route, this serves exactly to prevent large nodes with high > reputation from ruining links elsewhere. There are two things a node > looking to cause reputation loss could do. 1) Identify a node (not itself) > it thinks will delay a payment and send to them. This locks up funds on > their behalf, but is actually good behavior because it identifies a faulty > node and rightfully forces a loss in their reputation, eventually resulting > in them being booted from the network. Everyone upstream loses some > reputation for having connectivity to them, but less because of the loss > aggregation along the route. 2) Delay a payment oneself and force upstream > reputation loss. This is why I think it's important that the reputation > loss aggregate so that the malicious party loses the most. 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. > As for the amount of information leaked, yes, it helps determine the number > of upstream hops in a route. However, the CLTV values help determine the > number of downstream hops in a route in exactly the same way. I see these > as symmetric in a sense. Yes, which is why we have mitigations in place (which are still probably insufficient). I really don't want to add another vector. > This is exactly the question that your local view of peer reputations helps > solve: are the potential fees here worth the risk of forwarding this > payment to this downstream? 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! 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. Cheers, Rusty. _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
