📅 Original date posted:2016-08-12
📝 Original message:
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>;
Olaoluwa Osuntokun [ARCHIVE] /
npub19h…zkvn4
2023-06-09 12:46:25
in reply to nevent1q…l2rw
Author Public Key
npub19helcfnqgk2jrwzjex2aflq6jwfc8zd9uzzkwlgwhve7lykv23mq5zkvn4Published at
2023-06-09 12:46:25Event JSON
{
"id": "eca58751486c3336d89133485692fe28940909b4266d20f8b92c28b8bfbb32b9",
"pubkey": "2df3fc2660459521b852c995d4fc1a93938389a5e085677d0ebb33ef92cc5476",
"created_at": 1686314785,
"kind": 1,
"tags": [
[
"e",
"f166a20039cde752a8ba4e6cccc22d4b2719f9a29840f0c295641243ae59d83f",
"",
"root"
],
[
"e",
"e93700e98a13b75577840174dfb69d8fdc1f0529adee00afbac236c186480a98",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2016-08-12\n📝 Original message:\nRusty Russell \u003crusty at rustcorp.com.au\u003e wrote:\n\u003e Ephemeral key and mac make sense as a header, but it's fairly easy\n\u003e to image a different next hop address format for different networks.\n\u003e See also \"realm byte\" below.\n\u003e\n\u003e Thus I'm suggesting a format like:\n\u003e\n\u003e [ephemeral key] [mac] [realm] [per-realm-information]\n\u003e\n\u003e Per-realm-information is next-hop, amount, etc.\n\nIn order to maintain the security properties of the onion blob, each onion\nblob\nis required to be the exact same length. Therefore, the amount of bytes\nallocated for the \"next-hop\" address needs to be uniform. In my mind, the\nnext-hop\" field should just be an opaque blob (at the specification level)\nwith\nno further explicit meaning. Nodes residing on various chains will parse the\naddress accordingly (they might be using a different curve, etc).\n\nWith this said, I fail to see what we gain by making the current\nchain-boundary\nexplicit (within the onion blob's mix-header).\n\n\u003e An explicit network byte makes sense since we could eventually have\nmultiple\n\u003e networks (atomic cross-chain exchange). While node keys are network\nglobally\n\u003e unique (thus the exchange is *implied* by the next hop), it's nice to be\n\u003e explicit.\n\u003e\n\u003e We need some flag for the terminal node anyway, so it makes sense IMHO\n\u003e to expand it.\n\nSure, but the explicit network byte should be within the main p2p message\nheader rather than the header for the onion blob itself. When crossing\nchains,\nnodes will properly set the net magic in the outer message header.\n\nAlso we don't need to allocate an additional byte for the terminal node in\nany\ncase. The terminal node can either be identified by the null-MAC, or\nnull-nexthop (if that isn't being used to dispatch into virtual channels).\n\n\u003e Strawman proposal:\n\u003e 1) HTLC-hash and HTLC-preimage? (aha H-hash \u0026 H-preimage).\n\u003e 2) committx-hash and committx-preimage (C-hash / C-preimage) for the\n\u003e commitment transaction revocation?\n\u003e\n\u003e That avoids R altogether, which is overloaded...\n\nSounds good to me!\n\n-- Laolu\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160812/9368dd41/attachment.html\u003e",
"sig": "abb992e41072d286749facf1adbbaa4e6b33989b479f39d8931209105745b6ba11066b72883e7dbce92d87296dde8867b60ce866c82e97988614ce6cb89adc87"
}