Conner Fromknecht [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-15 📝 Original message: Hi ZmnSCPxj, Thanks for ...
📅 Original date posted:2018-11-15
📝 Original message:
Hi ZmnSCPxj,
Thanks for writing this up! I had started an email, but you beat me to it :)
> 1. For a sequence of `type,len,value`, each `type` must be unique. --
> accepted.
To add to this, it seemed that there was some agreement that repeated fields
should be serialized under a single root key, since a receiver can't know if a
field is allowed to have duplicates if they don't understand the field.
> 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.
Yep ascending makes sense to me, for the reasons you stated.
> 1, `type` - one byte or two?
I'd lean towards one, if a message has 256 optional fields, it might be time to
consider a new message type altogether.
> 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...?
Perhaps this depends on context:
- for gossip messages, I think the primary concern is not breaking signature
validation, and that these would need to remain optional for backwards
compatibility.
- for link-level messages, we have a little more control. I imagined the fields
would be gated by feature bit negotiation, and deviating from
unsupported/required would result in being disconnected.
> 5. `len` - one byte or two? I believe we tend to use two bytes for various
> lengths.
Maybe varint? One byte is not enough for all lengths, but two seems excessive
for uint8 or even uint32.
> 6. BOLT - I propose making a separate BOLT for `type,len,value`, which other
> messages and so on simply refer to.
Indeed, are you thinking we'd use this to add new fields proposed in 1.1?
In addition to the above, do we also want to flesh out what sub-TLV structures
would look like? Or perhaps that isn't necessary, if we can continue adding more
root-level keys.
--Conner
On Wed, Nov 14, 2018 at 8:54 PM ZmnSCPxj via Lightning-dev
<lightning-dev at lists.linuxfoundation.org> wrote:
>
> 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
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
📝 Original message:
Hi ZmnSCPxj,
Thanks for writing this up! I had started an email, but you beat me to it :)
> 1. For a sequence of `type,len,value`, each `type` must be unique. --
> accepted.
To add to this, it seemed that there was some agreement that repeated fields
should be serialized under a single root key, since a receiver can't know if a
field is allowed to have duplicates if they don't understand the field.
> 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.
Yep ascending makes sense to me, for the reasons you stated.
> 1, `type` - one byte or two?
I'd lean towards one, if a message has 256 optional fields, it might be time to
consider a new message type altogether.
> 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...?
Perhaps this depends on context:
- for gossip messages, I think the primary concern is not breaking signature
validation, and that these would need to remain optional for backwards
compatibility.
- for link-level messages, we have a little more control. I imagined the fields
would be gated by feature bit negotiation, and deviating from
unsupported/required would result in being disconnected.
> 5. `len` - one byte or two? I believe we tend to use two bytes for various
> lengths.
Maybe varint? One byte is not enough for all lengths, but two seems excessive
for uint8 or even uint32.
> 6. BOLT - I propose making a separate BOLT for `type,len,value`, which other
> messages and so on simply refer to.
Indeed, are you thinking we'd use this to add new fields proposed in 1.1?
In addition to the above, do we also want to flesh out what sub-TLV structures
would look like? Or perhaps that isn't necessary, if we can continue adding more
root-level keys.
--Conner
On Wed, Nov 14, 2018 at 8:54 PM ZmnSCPxj via Lightning-dev
<lightning-dev at lists.linuxfoundation.org> wrote:
>
> 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
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev