From laolu32 at gmail.com Mon Sep 5 19:24:11 2016 From: laolu32 at gmail.com (Olaoluwa Osuntokun) Date: Mon, 05 Sep 2016 19:24:11 +0000 Subject: [Lightning-dev] [BOLT Draft] Onion Routing Spec In-Reply-To: <20160902120822.GA4575@nex> References: <87oa58ox54.fsf@rustcorp.com.au> <87wpjl3rzh.fsf@rustcorp.com.au> <20160815120647.GA2595@nex> <87h9ajae48.fsf@rustcorp.com.au> <20160818090622.GA28345@nex> <871t1lefuo.fsf@rustcorp.com.au> <20160819183647.GB15105@lightning.network> <87pop1df71.fsf@rustcorp.com.au> <20160902120822.GA4575@nex> Message-ID: On Fri, Sep 2, 2016 at 5:08 AM Christian Decker 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: