Rusty Russell <ru...@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 _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
