[Lightning-dev] [BOLT Draft] Onion Routing Spec

Olaoluwa Osuntokun laolu32 at gmail.com
Fri Aug 12 18:00:34 UTC 2016


Rusty Russell <rusty at rustcorp.com.au> 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 <decker.christian at gmail.com> 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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160812/562993f0/attachment.html>


More information about the Lightning-dev mailing list