From laolu32 at gmail.com Mon Aug 22 19:47:56 2016 From: laolu32 at gmail.com (Olaoluwa Osuntokun) Date: Mon, 22 Aug 2016 19:47:56 +0000 Subject: [Lightning-dev] [BOLT Draft] Onion Routing Spec In-Reply-To: <87pop1df71.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> <20160819183647.GB15105@lightning.network> <87pop1df71.fsf@rustcorp.com.au> Message-ID: On Sun, Aug 21, 2016 at 1:46 PM Rusty Russell wrote: > > 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). > > Great catch. Oops... > During the whole payment negotiation process, the sender and receiver can additionally agree on a shared secret-ish value (possibly the hash of the contract) that should be included in the per-hop payload for the final hop. If the portion of the per-hop payload doesn't match identically with this value, then the payment should be rejected as a prior node has unsuccessfully attempted re-create the onion packet. -- Laolu -------------- next part -------------- An HTML attachment was scrubbed... URL: