[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