From cjp at ultimatestunts.nl Sun Aug 30 18:01:19 2015 From: cjp at ultimatestunts.nl (CJP) Date: Sun, 30 Aug 2015 20:01:19 +0200 Subject: [Lightning-dev] Loop attack with onion routing.. In-Reply-To: References: <874mjujyqe.fsf@rustcorp.com.au> <1440870652.4197.88.camel@hppg6.kloosterkade> Message-ID: <1440957679.5747.48.camel@hppg6.kloosterkade> > A - b - c - D - e - F - g - H > H pays 0.003 mBTC to F (explicit source routing fee; H > selected F for > onion-routing towards D, without A's knowledge) > > > You mean "D selected F for onion-routing towards H" here, surely? No :-) Both sides of a payment may value their privacy, so both sides may want to perform onion routing independently. It's a bit similar to TOR hidden services: you route from both sides towards a "meeting point" somewhere on the route, which is not necessarily one of the end points. Note that, because locking of transaction funds is always done in payer -> payee direction, this requires a separate routing phase before the locking. So, first you find a route (where all parties say they agree to fees, tx amount, timeouts and other conditions), and then you start performing transaction-channel actions. > > A pays 0.002 mBTC to b (non-source routing fee) > b pays 0.001 mBTC to c (non-source routing fee) > D pays 0.001 mBTC to c (non-source routing fee) > D pays 0.001 mBTC to e (non-source routing fee) > F pays 0.001 mBTC to e (non-source routing fee) > F pays 0.001 mBTC to g (non-source routing fee) > H pays 0.001 mBTC to g (non-source routing fee) > > > These fees still don't vary with time?, so a 30s result versus a 4 day > result still has a factor of 10k difference in cost vs revenue. I > think over 4 days, a 0.20% fee is about reasonable matching the 0.002 > fees that c, e and g end up with above (0.20%/4 days works out to a > 20% ROI per annum if all your channels are constantly at 100% use), so > linearising to an hour that's a 0.002% fee, which works out to 2 > satoshi per mBTC per hour. Yeah, after writing that e-mail, I realized I was contradicting myself a bit. That system is OK for normal tx fees, but it doesn't seem to work for "delayed tx fines". It's a bit of an open question for me how to distribute these fines on a mixed source/non-source routing network. On the non-source routed parts, you can't check whether intermediate nodes are honest when calculating the to-be-paid fines. Is that a problem, or is it good enough to let the free market do its job, so that nodes who demand too high fines will lose connections, just like with tx fees? Anyway, I think that for the non-source routing parts, the height of the fine (as a function of tx amount and delay) should be agreed prior to performing a transaction. An intermediate node can demand a payee-side fine that includes a weighed average of the fines it has to pay payer-side on its other links, to stay profitable. This is the same as with regular tx fees. On the source-routed parts, the fines seem to end up with the end points. Problems: 1. There is no persistent business / trust relationship and no payment channel between endpoint and intermediate source-routed node. So there is no way to enforce fine payment? 2. The payee endpoint is not always the bad guy in a delayed payment scenario. It could be that fund locking from payer to payee stopped somewhere in the middle of the route: in that case, the payee endpoint rightfully never discloses R. You could of course ignore source routing for the fines, and distribute the fines as if it is only a non-source routing path. The problem is that an attacker can create an arbitrarily long path with source routing, thereby creating arbitrarily large total damage to the network, corresponding to arbitrarily large total fines. If you use pre-calculated fine amounts, an attacker can always make a route that will result in a (large) loss for some intermediate nodes. CJP