📅 Original date posted:2019-02-24
📝 Original message:
ZmnSCPxj <ZmnSCPxj at protonmail.com> writes:
> Good morning Christian, Rusty, and list,
> You can take this a step further and make the realm 0 byte into a
> special type "0" which has a fixed length of 1299 bytes, with the
> length never encoded for this special type. It would then define the
> next 1299 bytes as the "V", having the format of 64 bytes of the
> current hop format (short channel ID, amount, CLTV, 12-byte padding,
> HMAC), plus 19*65 bytes as the encrypted form of the next hop data.
> This lets us reclaim even the realm byte, removing its overhead by
> re-encoding it as the type in a TLV system, and with the special
> exception of dropping the "L" for the type 0 (== current realm 0)
> case.
I disagree that this would be any clearer than the current proposal
since we completely lose the separation of payload encoding vs. onion
encoding. Let's not mix the concepts of payload and transport onion,
please.
> In short, drop the concept of 65-byte "frames".
>
> We could have another special length-not-encoded type 255, which
> declares the next 32 bytes as HMAC and the rest of the onion packet as
> the data for the next hop.
>
> The above is not a particularly serious proposal.
You had me worried for a second there :-)
Christian Decker [ARCHIVE] /
npub1wt…gtuyn
2023-06-09 12:54:19
in reply to nevent1q…ht5c
Author Public Key
npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynPublished at
2023-06-09 12:54:19Event JSON
{
"id": "ffc804395c6fd4efbb39c3f55d3fe2d78f2f141b07d805212192807ad1beab59",
"pubkey": "72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057",
"created_at": 1686315259,
"kind": 1,
"tags": [
[
"e",
"61dca50065a6b61d750bc7aab5174590056d9870f8b930ce2ae7ab6470716ff3",
"",
"root"
],
[
"e",
"9e5654b351104cc87d116ed9f5737f0f098c6aedb1dced14944652bafbd03b29",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2019-02-24\n📝 Original message:\nZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e writes:\n\u003e Good morning Christian, Rusty, and list,\n\u003e You can take this a step further and make the realm 0 byte into a\n\u003e special type \"0\" which has a fixed length of 1299 bytes, with the\n\u003e length never encoded for this special type. It would then define the\n\u003e next 1299 bytes as the \"V\", having the format of 64 bytes of the\n\u003e current hop format (short channel ID, amount, CLTV, 12-byte padding,\n\u003e HMAC), plus 19*65 bytes as the encrypted form of the next hop data.\n\u003e This lets us reclaim even the realm byte, removing its overhead by\n\u003e re-encoding it as the type in a TLV system, and with the special\n\u003e exception of dropping the \"L\" for the type 0 (== current realm 0)\n\u003e case.\n\nI disagree that this would be any clearer than the current proposal\nsince we completely lose the separation of payload encoding vs. onion\nencoding. Let's not mix the concepts of payload and transport onion,\nplease.\n\n\u003e In short, drop the concept of 65-byte \"frames\".\n\u003e\n\u003e We could have another special length-not-encoded type 255, which\n\u003e declares the next 32 bytes as HMAC and the rest of the onion packet as\n\u003e the data for the next hop.\n\u003e\n\u003e The above is not a particularly serious proposal.\n\nYou had me worried for a second there :-)",
"sig": "1fcf981320f7d40a13905de3977e0dba5fc4f80debe611371ed93e6c32a9c9bc1339ab8505ee071acde74e6912ec8bda14179d601bd7a0ccd61afcba55e5584c"
}