From laolu32 at gmail.com Fri Aug 12 17:59:33 2016 From: laolu32 at gmail.com (Olaoluwa Osuntokun) Date: Fri, 12 Aug 2016 17:59:33 +0000 Subject: [Lightning-dev] [BOLT Draft] Onion Routing Spec In-Reply-To: <87oa58ox54.fsf@rustcorp.com.au> References: <87oa5byeyf.fsf@rustcorp.com.au> <87oa58ox54.fsf@rustcorp.com.au> Message-ID: Rusty Russell wrote: > Ephemeral key and mac make sense as a header, but it's fairly easy > to image a different next hop address format for different networks. > See also "realm byte" below. > > Thus I'm suggesting a format like: > > [ephemeral key] [mac] [realm] [per-realm-information] > > Per-realm-information is next-hop, amount, etc. In order to maintain the security properties of the onion blob, each onion blob is required to be the exact same length. Therefore, the amount of bytes allocated for the "next-hop" address needs to be uniform. In my mind, the next-hop" field should just be an opaque blob (at the specification level) with no further explicit meaning. Nodes residing on various chains will parse the address accordingly (they might be using a different curve, etc). With this said, I fail to see what we gain by making the current chain-boundary explicit (within the onion blob's mix-header). > An explicit network byte makes sense since we could eventually have multiple > networks (atomic cross-chain exchange). While node keys are network globally > unique (thus the exchange is *implied* by the next hop), it's nice to be > explicit. > > We need some flag for the terminal node anyway, so it makes sense IMHO > to expand it. Sure, but the explicit network byte should be within the main p2p message header rather than the header for the onion blob itself. When crossing chains, nodes will properly set the net magic in the outer message header. Also we don't need to allocate an additional byte for the terminal node in any case. The terminal node can either be identified by the null-MAC, or null-nexthop (if that isn't being used to dispatch into virtual channels). > Strawman proposal: > 1) HTLC-hash and HTLC-preimage? (aha H-hash & H-preimage). > 2) committx-hash and committx-preimage (C-hash / C-preimage) for the > commitment transaction revocation? > > That avoids R altogether, which is overloaded... Sounds good to me! -- Laolu -------------- next part -------------- An HTML attachment was scrubbed... URL: