Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Bolt 1: Specify that extensions to existing messages must use TLV #714
The spec already prepared a hook to add additional information to existing
Since we're using TLV in many places, it would make sense to use that optional
We keep the "additional bytes must be ignored" rule for what happens after that
This was already proposed in #630 but rejected. I found additional reasons to
Imagine node A and node B are peers, both running experiments by leveraging the
This is a major inconvenience when experimenting with message extensions. I believe
The spec already prepared a hook to add additional information to existing messages (additional bytes at the end of a message must be ignored). Since we're using TLV in many places, it would make sense to use that optional additional space at the end of each message to allow an optional tlv stream. We keep the "additional bytes must be ignored" rule for what happens after that tlv stream, giving us extra flexibility to add another type of optional content to existing messages later if needed.
Open question: should the TLV stream be prefixed with its length or not?
It seems like the gossip_queries tlv streams today don't prefix with the length (length is inferred from the overall message length).
The inconvenient when we don't prefix with the length is that we completely remove the possibility of having another bag of uninterpreted bytes at the end of the message (if we decide some day that we want to extend messages with something else than TLV). Maybe we don't care, maybe we do :)
I'm leaning towards removing the tlv stream length prefix: in that case this PR makes even more sense to do now, because we don't want to have some messages be extended with a TLV stream and others extended differently, that would be a big mess. WDYT @rustyrussell @cfromknecht @sstone ?
UPDATED: removed the length prefix in
If we limit message extensions to be TLV-based we should definitely drop the length prefix.
I'd like to point out that there is a small caveat for gossip broadcast messages (
Other than that small wording issue, I'm definitely in favor of consolidating towards TLVs.
This applies to: - option_upfront_shutdown_script: if you're not interested, just set the length to 0 - channel_reestablish commitment points: it makes sense to always include those regardless of whether `option_dataloss_protect` or `option_static_remotekey` are set No need to change the `channel_update`'s `htlc_maximum_msat` because the `message_flags` encode its presence/absence. It can still be either included or omitted without causing issues to the extension stream.
I added two commits:
Do you think we should re-work
It could be done in an interesting backwards-compatible way: