From aj at erisian.com.au Mon Aug 31 21:08:58 2015 From: aj at erisian.com.au (Anthony Towns) Date: Tue, 1 Sep 2015 07:08:58 +1000 Subject: [Lightning-dev] Loop attack with onion routing.. In-Reply-To: <1440957679.5747.48.camel@hppg6.kloosterkade> References: <874mjujyqe.fsf@rustcorp.com.au> <1440870652.4197.88.camel@hppg6.kloosterkade> <1440957679.5747.48.camel@hppg6.kloosterkade> Message-ID: On 31 August 2015 at 04:01, CJP wrote: > > 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. > Hmm. I would look at that more like: Setup: - H wants to be secretive. - H establishes a channel with g - H tells F he can route to H via g - H tells D he can route to H via F Announcement: - H tells other people (such as A) they can route to H via D Then A sends a txn for H to D as instructed, and D chooses to forward it on via F. (Hmm. In that scenario, if e tried to send a txn to H, she would route via D, then find D routed the txn back to it -- using the same R -- and that F was the next destination. This would be an information leak, arguably. Likewise for anyone whose cheapest path to D was through e) 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. > Isn't that a bit circular -- "you obtain the route by sending messages along the route" ? It also relies on end-to-end communication in realtime, which wouldn't work for paying to a cold-wallet lightning channel that's only occassionally online. If you *did* assume everything is in realtime, you could avoid fines entirely just by having the protocol be something like: - the official timeout was 4 days, the unofficial timeout is 4 minutes - ... - okay 4 minutes is up, do you know R? - no, okay, we're revoking the transaction. - you don't want to? fine, channel is closed. Maybe that's what the default protocol should be anyway, and fines are just an extension to that to bribe the payer not to close the channel... 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. ?I don't think it can go arbitrarily large -- if the recipient is paying the fines at each point, then the scenario is: incoming HTLC: (Alice to Bob) timeout T X (onward funds) + f (Bob's fees) on success x*t (fine Bob pays Alice) if it takes a long time, t forwarded HTLC (Bob to Carol) timeout T' X (onward funds) (x+y)*t' (fine Carol pays Bob) if it takes a long time, t' So Bob can set T' <= M/x where M is the maximum fine I'm willing to pay Alice to keep the channel open, if Carol fails to pay the fine and just closes the channel. If T'<=1 hour or similar, you just return a PKT_ROUTE_FAIL quickly and don't pay any fines. ?Carol is faced with T'' <= M/(x+y) which is likely smaller still, and s on. In the case where a node ?is expected to take a while, the original payer should be able to send a fee along to cover that node's 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. > ?Only by sacrificing a channel, though.? If you set commit_fee = 1 mBTC (how much a unilateral channel close costs) close_fee = 0.1 mBTC (fees on a cooperative close) then if you've got N open HTLC's on your channel with Mallory, then you can set M=0.8/N mBTC and offer Mallory the following options: a) he pays you the fines he owes, and everyone's happy b) he closes the channel unilaterally and gets whatever he can c) you both close the channel cooperatively, splitting the 0.9 mBTC in fees as 0.8 to you, 0.1 to him. Mallory's better off in c) than b), and with c) you can afford to pay your fines. Active HTLCs in both directions complicate matters, and 0.8/N mBTC still isn't very much, though. ?Cheers, aj? -- Anthony Towns -------------- next part -------------- An HTML attachment was scrubbed... URL: