Closed moshababo closed 4 years ago
Penalizing the route would harm innocent nodes. If just one in the route is delaying the release of the preimage everyone in the route would suffer because of it.
If the route get penalized this should just affect the routing behavior or this could lead to more private channels and not allowing routing at all.
@michael1011 That's true, but I don't think we would penalize the nodes in the route on the xud level - in other words we wouldn't stop trading with them. But we may want to stop using a particular route if it is unreliable. I think ideally this would happen on the lightning layer, but we might want to have some custom logic for xud. There's been good discussion about this re: "Loop Attacks" on the lightning mailing list.
My thoughts on reputation event "penalizing" are:
Dependency: direct channel mode implemented https://github.com/ExchangeUnion/xud/issues/865#issuecomment-482148233
Since we agreed to leave the "free option problem" open for mainnet release, I moved this to post-1.0.0
. Any input on details like weight of events is appreciated though @erkarl
A simple score of -25 for a delayed preimage release >5 minutes? Second time this happens, ban threshold is met and we won't trade with this peer anymore. I would want to do this as part of https://github.com/ExchangeUnion/xud/issues/1422. Wdyt? @sangaman
I'd even consider banning the user for a short period of time first time this happens. The second time => longer ban, etc.
Yeah that sounds reasonable. So we should introduce a ban timestamp. Let's wait for @sangaman to comment.
I think this is partly covered by the SwapTimedOut
event which penalizes a peer when we have begun a swap that isn't completed in a set amount of time. A peer that withholds a preimage is going to incur this penalty every time.
However the logic currently isn't very refined, it doesn't distinguish between when we hold the preimage but a swap times out (perhaps because the peer experienced connectivity issues) and when the counterparty holds the preimage, the latter being much more dangerous because of the free option it grants. Also in looking at the code we start the timer a little earlier than we should, I'm thinking it should only start once the ball has left our court (currently it incorporates the time it takes to interact with out local lnd node for invoices/routing). I figure these should be separate categories of error, with it being more severe when a swap times out when we are the maker and have already sent our payment to the taker.
As for temp-banning, I think that may be too severe because there can be innocuous reasons why this would happen. We can distinguish a malicious peer delaying the preimage release from times where there are network issues, or when intermediary hops fail or delay the payment. It's not that unusual for payments to take a long time on LN as is, and we wouldn't want to severely punish for that I think. If this kind of thing happens regularly, though, it makes sense to ban because it means we simply can't trade in a reasonable timeframe with that peer.
Longer term I'm still thinking it would make sense to break up each swap into smaller chunks, to minimize the downside of delayed payments, free options, and locked up HTLCs.
Closing in favor of https://github.com/ExchangeUnion/xud/issues/1700
We need to be able to penalize peer for delaying the preimage release. The problem is that in a multi-hop swap we can't reliably detect whether it was delayed by the peer, or by any other node along the way. So what we can do is to time the entire swap procedure, and if it's exceeds a defined threshold, we can penalize the route (this might happen on lnd-level), and use a different route for a future swap. If we end up with a direct open channel to the peer, and the swap time exceeded the threshold, we can penalize the peer.
Also need to check for equivalent problem/solution for Raiden swaps.