From rusty at rustcorp.com.au Fri Aug 19 00:56:31 2016 From: rusty at rustcorp.com.au (Rusty Russell) Date: Fri, 19 Aug 2016 10:26:31 +0930 Subject: [Lightning-dev] [BOLT Draft] Onion Routing Spec In-Reply-To: <20160818090622.GA28345@nex> References: <87oa5byeyf.fsf@rustcorp.com.au> <87oa58ox54.fsf@rustcorp.com.au> <87wpjl3rzh.fsf@rustcorp.com.au> <20160815120647.GA2595@nex> <87h9ajae48.fsf@rustcorp.com.au> <20160818090622.GA28345@nex> Message-ID: <871t1lefuo.fsf@rustcorp.com.au> Christian Decker writes: > On Wed, Aug 17, 2016 at 07:53:03PM +0930, Rusty Russell wrote: >> Christian Decker writes: >> > I agree that the realm byte is a sensible addition. To trigger this we >> > would need to have multiple channels, on different chains, using the >> > same identifiers between two nodes. Only in this case we'd have an >> > ambiguity where to transfer the funds. Assuming we have the route A -> >> > B => C, where => indicates two channels, one in litecoin and one in >> > bitcoin, and both channels use the same identity for C. Then the >> > instruction to forward 0.01 units to C is ambiguous, as it could be >> > denominated in either litecoin or bitcoin. >> > >> > While not dangerous it is rather unfortunate as it results in >> > guesswork. It is not dangerous because if A transferred litecoin to B >> > then B will (hopefully) never forward a higher value to C using >> > bitcoin, and if it were bitcoin then the final recipient would not >> > sign off an inferior amount than what he expected. >> >> Worse case: C is a charity, accepting donations. A's software screwed >> up and didn't realize C was litecoin, not bitcoin. B collects a huge >> fee, C gets tiny donation. > > True, that's a dangerous scenario. If the recipient does not know the > intended amount and accepts anything then fee-shaving is very > profitable. Which creates a subtle requirement: even the terminal onion should include an amount. > In general I'm a bit concerned about rhash re-use, after > all today it's not uncommon to just publish a bitcoin address, people > might be tempted to do the same in Lightning. Hmm, maybe we should implement the code to steal such re-sends? Or more generously, fail it. That would prevent this from becoming a habit, at least. Related: I can't seem to figure out why we're so concerned with onion reuse? It seems if a node were to retransmit the same onion runs this same risk. Thanks, Rusty.