Christian Decker [ARCHIVE] on Nostr: 📅 Original date posted:2016-08-15 📝 Original message: On Sat, Aug 13, 2016 at ...

📅 Original date posted:2016-08-15
📝 Original message:
On Sat, Aug 13, 2016 at 07:34:02PM +0930, Rusty Russell wrote:
> 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.

I agree that the realm byte is a sensible addition. To trigger this we
would need to have multiple channels, on different chains, using the
same identifiers between two nodes. Only in this case we'd have an
ambiguity where to transfer the funds. Assuming we have the route A ->
B => C, where => indicates two channels, one in litecoin and one in
bitcoin, and both channels use the same identity for C. Then the
instruction to forward 0.01 units to C is ambiguous, as it could be
denominated in either litecoin or bitcoin.

While not dangerous it is rather unfortunate as it results in
guesswork. It is not dangerous because if A transferred litecoin to B
then B will (hopefully) never forward a higher value to C using
bitcoin, and if it were bitcoin then the final recipient would not
sign off an inferior amount than what he expected.

To prevent this we could make it a policy to never re-use identities
for multiple channels, but someone will surely get it wrong at some
point :-)

I was thinking that it'd be stored in the per-hop payload, along with
the instructions for the hop, which is why I did not specify it, but
I'm happy to add it, should it make things clearer.

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

Indeed the last hop's routing information is all zeroes and the
per-hop payload is currently unused (as the node does not forward
anything). If we use the terminal identifier we can shave the 40 bytes
routing info off the packet, provided the node checks the terminal
byte in the per-hop payload before attempting anything with the
routing info which'd be garbage, i.e., encrypted fillers by the first
hop.

Cheers,
Christian