📅 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
Conner Fromknecht [ARCHIVE] /
npub1za…uua2a
2023-06-09 12:52:53
in reply to nevent1q…88kx
Author Public Key
npub1za0a9afyj7um5feva0d5xmhfsah3zxm252hna2duq0numa952frqvuua2aPublished at
2023-06-09 12:52:53Event JSON
{
"id": "c84f5f04f24ef73d1f375bb31e66cef2e49da2af331b61d7f2f718b4d42790c0",
"pubkey": "175fd2f52497b9ba272cebdb436ee9876f111b6aa2af3ea9bc03e7cdf4b45246",
"created_at": 1686315173,
"kind": 1,
"tags": [
[
"e",
"d96b54bd1a16a00379a91b3db2449979b8b41d8eecbbb0fb0270247887f2b600",
"",
"root"
],
[
"e",
"5d0905101cd0052d523ec458b3a96226f7db40265f221b1d6214c16213963c38",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2018-11-15\n📝 Original message:\nHi ZmnSCPxj,\n\nThanks for writing this up! I had started an email, but you beat me to it :)\n\n\u003e 1. For a sequence of `type,len,value`, each `type` must be unique. --\n\u003e accepted.\n\nTo add to this, it seemed that there was some agreement that repeated fields\nshould be serialized under a single root key, since a receiver can't know if a\nfield is allowed to have duplicates if they don't understand the field.\n\n\u003e For a sequence of `type,len,value`, the `type`s must be in ascending order\n\u003e -- not explicitly accepted or rejected. It would be easier to check\n\u003e uniqueness \u003e (the previous rule we accepted) here for a naive parser (keep\n\u003e track of some \"minimum allowed type\" that initializes at zero, check current\n\u003e type \u003e= this, update to current type + 1) if `type`s are in ascending order.\n\nYep ascending makes sense to me, for the reasons you stated.\n\n\u003e 1, `type` - one byte or two?\n\nI'd lean towards one, if a message has 256 optional fields, it might be time to\nconsider a new message type altogether.\n\n\u003e 3. `type` - does \"it's OK to be odd\" apply? i.e. if an even `type` that is\n\u003e not known is found, crash and burn. But intent of this system is for future\n\u003e expansion for optional fields, so...?\n\nPerhaps this depends on context:\n - for gossip messages, I think the primary concern is not breaking signature\n validation, and that these would need to remain optional for backwards\n compatibility.\n - for link-level messages, we have a little more control. I imagined the fields\n would be gated by feature bit negotiation, and deviating from\n unsupported/required would result in being disconnected.\n\n\u003e 5. `len` - one byte or two? I believe we tend to use two bytes for various\n\u003e lengths.\n\nMaybe varint? One byte is not enough for all lengths, but two seems excessive\nfor uint8 or even uint32.\n\n\u003e 6. BOLT - I propose making a separate BOLT for `type,len,value`, which other\n\u003e messages and so on simply refer to.\n\nIndeed, are you thinking we'd use this to add new fields proposed in 1.1?\n\nIn addition to the above, do we also want to flesh out what sub-TLV structures\nwould look like? Or perhaps that isn't necessary, if we can continue adding more\nroot-level keys.\n\n--Conner\nOn Wed, Nov 14, 2018 at 8:54 PM ZmnSCPxj via Lightning-dev\n\u003clightning-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e Good morning list,\n\u003e\n\u003e 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).\n\u003e This would allow some transition to future additional fields while maintaining backward compatibility.\n\u003e\n\u003e I believe these were brought up:\n\u003e\n\u003e 1. For a sequence of `type,len,value`, each `type` must be unique. -- accepted.\n\u003e 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 \u003e= this, update to current type + 1) if `type`s are in ascending order.\n\u003e\n\u003e Now for bikeshedding:\n\u003e\n\u003e 1, `type` - one byte or two?\n\u003e 2. `type` - maybe some other name, since we already use `type` for messages? How about, `key` instead?\n\u003e 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...?\n\u003e 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`.\n\u003e 5. `len` - one byte or two? I believe we tend to use two bytes for various lengths.\n\u003e 6. BOLT - I propose making a separate BOLT for `type,len,value`, which other messages and so on simply refer to.\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev",
"sig": "8c357e8d51c6b326e32e076b894b3a099fafb6f4da7bf49067de4f3dacd6573f6c4b1ee16ea422ffa741571873d47011d1936c295dae43c1bd1cda451124deed"
}