From joseph at lightning.network Fri Aug 19 18:36:47 2016 From: joseph at lightning.network (Joseph Poon) Date: Fri, 19 Aug 2016 11:36:47 -0700 Subject: [Lightning-dev] [BOLT Draft] Onion Routing Spec In-Reply-To: <871t1lefuo.fsf@rustcorp.com.au> 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> <871t1lefuo.fsf@rustcorp.com.au> Message-ID: <20160819183647.GB15105@lightning.network> On Fri, Aug 19, 2016 at 10:26:31AM +0930, Rusty Russell wrote: > >> > 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. Yeah, for sure, I agree with y'all. By default, there should be a requirement that the amount is pre-negotiated by the sender and the recipient (pay-to-contract, etc.) Sufficient percentages of senders to a charity should be interested in getting a receipt to prove funds were sent to a charity that I don't think pre-sending it without generating a proof shouldn't be a normal case. By default, I don't think clients should even send funds until they have a signed receipt before cross-chain is supported for safety. However, I'm not too concerned with cross-chain. As long as there's some identifier between each hop, I suspect that should be sufficient. Is the intent of the realm byte to indicate protocols? I think it's reasonable to have some kind of byte for identifying the message (e.g. using this as a transport layer for other things), but I think there should already be sufficient information for cross-chain, presuming pay-to-contract. > > 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. This may not fully solve the problem, since if one presumes that the second-to-last hop is malicious, they can re-create a new onion blob (presuming consistent hashes for each hop, of course). There may be a requirement from deriving the fee amount for the last hop, though. > > 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. Either way seems practical for some nodes -- I presume if a small percentage of nodes redeem without forwarding, then basically nobody would re-use. Not sure if "steal" is the right word, though. -- Joseph Poon