From decker.christian at gmail.com Mon Aug 15 12:18:35 2016 From: decker.christian at gmail.com (Christian Decker) Date: Mon, 15 Aug 2016 14:18:35 +0200 Subject: [Lightning-dev] [BOLT Draft] Onion Routing Spec In-Reply-To: References: Message-ID: <20160815121835.GB2595@nex> On Fri, Aug 12, 2016 at 06:00:34PM +0000, Olaoluwa Osuntokun wrote: > Rusty Russell wrote: > > In practice, you can do this one level up: simply agree with a rendevous > > node that a given H-hash is to be fwded to you. Then direct the payer > > to the rendevous node. > > > > So I don't think it's worth any complexity in the routing protocol. > > Nevermind, I forgot that the nested header (assuming its the e2e payload) > would be wrapped in layers on onion encryption. So the hop *after* the > rendevous node is hidden from pre-rendevous node anyway :) > > > Keep it simple; let's just support regular for now. Nodes will have to > > broadcast what extensions they support, and this can be used for > > extended formats later. Including ones we *didn't* think of yet... > > Sure. Additionally, as Christian pointed out further down in the thread, > ideally we shoud aim to seamlessly integrate rendevous routing. If possible, > we should keep all onion packets indistinguishable from each other. > > > I think we're over-designing. How about: daily key rotation (which we > > want anywat), remember all onions for current and previous key. > > Yeah only daily key rotation should be sufficient. It seems that we need > either timestamps, or key rotation, not both. > > > It'd be great to avoid it, but that seems complex enough to push to a > > future spec. > > Agreed. When I first brought up key rotation eariler in the thread, I noted > it > might be better if it were deferred to a future spec. Nevertheless, the > I've found the resulting discussion very valuable. > > > id and comms keys don't have to be bitcoin keys; could be Schnorr. > > The EC Schnorr construction would likely use Bitcoin's curve, so there's no > meaningful distinction there. We're currently constrainted to ECDSA within > Bitcoin, but can freely use EC Schnorr within the network if the space > savings > are desirable (as you pointed out). IDs only have to make sense to the receiving node, so the node may actually broadcast a short identifier with the channel announcement that uniquely identifies the channel to it (index, establishment timestamp, ...). So it could be aything besides the globally unique EC pubkey. > > > Christian Decker writes: > > Sounds good, however I'm not clear on how the final recipient can provide > a > > precompiled valid header with the HMACs that include the per-hop payloads > > and the end-to-end payload without knowing them upfront. > > > > I'd prefer having a rendezvous scheme that merges the two ends of the > route > > in a seamless way, which should not be too hard to do, unless we keep the > > per-hop checkable HMACs. > > Ahh, I see what you mean now. You're correct, it seems that we may be forced > to drop the per-hop HMAC in order to enable seamless rendevous routing. > Kind of sad, I know, but we may be able to save them with an interactive protocol: the endpoints of the route negotiate a rendezvous node, then the sender builds his half of the path, computes the ephemeral key at the rendezvous point and sends it to the final recipient which finalizes the route construction. But maybe I'm overthinking it, at this point the payload could just be sent out-of-band :-) > > Do we need both a timestamped backlog of secrets and key-rotation? If we > > get the key rotation quick enough it's probably sufficient to simply keep > > all secrets for the current key, especially if we use bloom-filters to > > store the seen secrets. > > Yeah, it seems that key rotation alone is much simpler than the timestamped > log > of secrets. So the key rotation alone should suffice. > > -- Laolu Perfect, that seems like a clean and simple solution to the shared secret storage problem. Noting this does for a future spec :-) Cheers, Christian