Good morning list,
An item added discussed in the summit was the proposed "type,len,value", which
is added to the end of messages and other intercommunication structures
(invoices and so on).
This would allow some transition to future additional fields while maintaining
backward compatibility.
I believe these were brought up:
1. For a sequence of `type,len,value`, each `type` must be unique. -- accepted.
2. For a sequence of `type,len,value`, the `type`s must be in ascending order
-- not explicitly accepted or rejected. It would be easier to check uniqueness
(the previous rule we accepted) here for a naive parser (keep track of some
"minimum allowed type" that initializes at zero, check current type >= this,
update to current type + 1) if `type`s are in ascending order.
Now for bikeshedding:
1, `type` - one byte or two?
2. `type` - maybe some other name, since we already use `type` for messages?
How about, `key` instead?
3. `type` - does "it's OK to be odd" apply? i.e. if an even `type` that is not
known is found, crash and burn. But intent of this system is for future
expansion for optional fields, so...?
4. `len` - measures bytes of `value`, obviously since if the receiver does not
know the `type` then it cannot know what unit is used for the `value`.
5. `len` - one byte or two? I believe we tend to use two bytes for various
lengths.
6. BOLT - I propose making a separate BOLT for `type,len,value`, which other
messages and so on simply refer to.
Regards,
ZmnSCPxj
_______________________________________________
Lightning-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
