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

[Rusty Russell]

Olaoluwa Osuntokun <laolu32 at gmail.com> writes:
> 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).

Kind of.  We need some identifier to know, as nodes may straddle chains.

> 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.

Some node will have to straddle two chains, right?  So you'd route A ->
B -> C as normal, and C is (say) litecoin (B straddles both).  You
really want the onion to be explicit that this transfer to litecoin is
what the sender intended.  Or some sidechain.

Now, we'd hope nobody would screw this up, but I think it's worth
flagging since the sender really should know it's changing chains.

> 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).

That implies there's a final hop in the packet which is unused?  I
believe strongly we want a realm byte, so I think it makes more sense to
overload it for this.

>> 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!

I shall try to use those consistently from now on!

Thanks,
Rusty.