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

Olaoluwa Osuntokun laolu32 at gmail.com
Mon Sep 5 19:24:11 UTC 2016


On Fri, Sep 2, 2016 at 5:08 AM Christian Decker <decker.christian at gmail.com>
wrote:

> As far as I can see we mostly agree on the spec, with some issues that
> should be deferred until later/to other specs:
>
>  - Key-rotation policies
>  - Backlog of seen shared secrets
>  - Payload formatting (what data to include and how it is encoded)
>
> Sounds good to me. That's a good summarization of the current outstanding
aspects to be deferred based on our past discussions.


> Anyway, I'm happy to shelve this aspect for a future v2 of the onion
> routing protocol, and include the payload in the HMAC.
>

Agreed, the full specification of the rendezvous handshake can deferred to
a later v2. We may even learn of some limitations or issues with the
current format which may impact the requirements or traits we want from a
future rendezvous protocol.

I think for now we should also keep the payload sizes fixed at 20
> bytes for per-hop and 1024 byte for end-to-end payload


Sure, although I have some reservations about the 1024-byte e2e payload due
to the potential bandwidth overhead for each HTLC-add in a high frequency
setting. However we should gather metrics from live testing environments to
see if this is actually a concern in practice.

Since we seem to want to add and remove bits and pieces it might be worth
> to make it flexible using a generic encoding (JSON, msgpack, ...).
> This potentially includes the "forward X units of coin Y" and the "expect X
> units" for the endpoint. We can also address the "last-hop corrupts"
> problem in the payload with an additional end-to-end secret like you
> suggested. Having them in the per-hop payload and HMACing the
> payloads secures them against tampering.
>

It feels like targeting a generic encoding might be at odds with the space
constraints imposed by the size of the per-hop payload. However if we can
find a format that's both succinct yet generic, then that would be very
attractive.


> BTW do we have a process in place for upgrading spec drafts
> or do we keep things informal?
>

Hmm, I'm not sure. As far as I'm aware, none of the current specifications
have been elevated to anything above a "draft" state. Perhaps we can hammer
out the ins-and-outs of what we'd all like to see in the process in Milan?

Yay! This is exciting :), I'm happy with the way the current specification
has turned out. I think your break down of the current outstanding issues
to be deferred to later specs are accurate. I also welcome a PR to our
"lightning-onion" repo integrating the changes you implemented in your fork
of my original code.

-- Laolu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160905/d2e5fe4c/attachment.html>


More information about the Lightning-dev mailing list