From laolu32 at gmail.com Fri Aug 12 18:00:34 2016 From: laolu32 at gmail.com (Olaoluwa Osuntokun) Date: Fri, 12 Aug 2016 18:00:34 +0000 Subject: [Lightning-dev] [BOLT Draft] Onion Routing Spec In-Reply-To: References: Message-ID: 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). 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. > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: