Bolt 1: Missing version number in message format?

[jeroenvanagt]

For future upgradability and backwards compatibility would it not be wise to include a version number in the message format? I know there is a type field, but it makes sense to have them both otherwise you will run out of types fields quickly (in the future).

[cdecker]

Well, we have a number of extension mechanisms at our disposal, the type mechanism being one. type offers us up to 65k updates. In addition we have the localfeatures and globalfeatures fields which allow a much more fine-grained signaling mechanism than a single version field. Finally, we also have the ignore trailing data mechanism, which allows us to stuff additional fields at the end of a message and have it ignored by nodes that do not support it.

Should we ever run out of options to extend the protocol we can still make a protocol upgrade by sending a protocol upgrade message and then using the new and improved version 😉

[rustyrussell]

Jeroen van Agt <[email protected]> writes:

For future upgradability and backwards compatibility would it not be wise to include a version number in the message format? I know there is a type field, but it makes sense to have them both otherwise you will run out of types fields quickly (in the future).

Version numbers are a very limited way of attempting compatibility. We use version bits, in effect. To quote BOLT #1: Once authentication is complete, the first message reveals the features supported or required by this node. Odd features are optional, even features are compulsory (_it's OK to be odd_). The meaning of these bits will be defined in the future. 1. type: 16 (`init`) 2. data: * [2:gflen] * [gflen:globalfeatures] * [2:lflen] * [lflen:localfeatures] Hope that helps! Rusty.