ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2019-02-23 📝 Original message: Good morning Christian, ...
📅 Original date posted:2019-02-23
📝 Original message:
Good morning Christian, Rusty, and list,
> There is however a third option, namely make the entire payload a
> TLV-set and then use the old payload format (`short_channel_id`,
> `amt_to_forward`, `outgoing_ctlv_value`) as a single TLV-value with 20
> bytes of size. That means we have only 2 bytes of overhead compared to
> the old v0 format (4 byte less than option 2), and can drop it if we
> require some other payload that doesn't adhere to this format.
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.
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.
Regards,
ZmnSCPxj
📝 Original message:
Good morning Christian, Rusty, and list,
> There is however a third option, namely make the entire payload a
> TLV-set and then use the old payload format (`short_channel_id`,
> `amt_to_forward`, `outgoing_ctlv_value`) as a single TLV-value with 20
> bytes of size. That means we have only 2 bytes of overhead compared to
> the old v0 format (4 byte less than option 2), and can drop it if we
> require some other payload that doesn't adhere to this format.
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.
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.
Regards,
ZmnSCPxj