Use zero-sized field for message padding

[jkczyz]

Could you use something like PhantomData<[u8; 12]> (or our own custom Padding type) for this? It could allow for using zero bytes yet still have a field for reading/writing the data. Then we'd make reading the padding explicit rather than doing so while reading outgoing_cltv_value.

Originally posted by @jkczyz in #434

[varunsrin]

Happy to pick this up, unless @TheBlueMatt is already working on it.

@jkczyz To clarify, do we always set amt_to_forward (u64) and outgoing_cltv_value (u32) to 0 values to provide padding for the legacy format? And is the goal to use an explicit type rather than implicit ones?

[jkczyz]

Happy to pick this up, unless @TheBlueMatt is already working on it.

Go for it!

@jkczyz To clarify, do we always set amt_to_forward (u64) and outgoing_cltv_value (u32) to 0 values to provide padding for the legacy format? And is the goal to use an explicit type rather than implicit ones?

Padding actually predates the format becoming legacy. It is reserved for future use in that format. This is defined in BOLT 4 in v1.0 of the spec.

https://github.com/lightningnetwork/lightning-rfc/blob/v1.0/04-onion-routing.md

The changes in #434 are from the working v1.1 spec, which makes that format legacy.

https://github.com/lightningnetwork/lightning-rfc/blob/master/04-onion-routing.md

[varunsrin]

Pushed for review: #469

[upjohnc]

IIUC: this ticket could be closed. Looks like PR #469 made the code change.

[TheBlueMatt]

That PR never ended up getting merged, though I'm not sure it's worth doing this now - it wouldn't clean up our serialization and let us switch to a macro and eventually we'll fully remove the pre-TLV onion format.