Christian Decker [ARCHIVE] on Nostr: 📅 Original date posted:2019-02-22 📝 Original message: Rusty Russell <rusty at ...

📅 Original date posted:2019-02-22
📝 Original message:
Rusty Russell <rusty at rustcorp.com.au> writes:
> There are two ways to add TLV to the onion:
> 1. Leave the existing fields and put TLV in the padding:
> * [`8`:`short_channel_id`]
> * [`8`:`amt_to_forward`]
> * [`4`:`outgoing_cltv_value`]
> * [`12`:`padding`]
> 2. Replace existing fields with TLV (eg. 2=short_channel_id,
> 4=amt_to_forward, 6=outgoing_cltv_value) and use realm > 0
> to flag the new TLV format.
>
> The length turns out about the same for intermediary hops, since:
> TLV of short_channel_id => 10 bytes
> TLV of amt_to_forward => probably 5-6 bytes.
> TLV of outgoing_cltv_value => probably 3-4 bytes.
>
> For final hop, we don't use short_channel_id, so we save significantly
> there. That's also where many proposals to add information go (eg. a
> special "app-level" value), so it sways me in the direction of making
> TLV take the entire room.

I'd definitely vote for making the entire payload a TLV (option 2) since
that allows us to completely redefine the payload. I don't think the
overhead argument really applies since we're currently wasting 12 bytes
of payload anyway, and with option 2 we still fit the current payload in
a single frame.

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.

Cheers,
Christian