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

[Olaoluwa Osuntokun]

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