š
Original date posted:2018-11-15
š Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181115/815ebee9/attachment.html>;
ZmnSCPxj [ARCHIVE] /
npub1g5ā¦3ms3l
2023-06-09 12:52:53
in reply to nevent1qā¦g6ec
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lPublished at
2023-06-09 12:52:53Event JSON
{
"id": "5d0905101cd0052d523ec458b3a96226f7db40265f221b1d6214c16213963c38",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686315173,
"kind": 1,
"tags": [
[
"e",
"d96b54bd1a16a00379a91b3db2449979b8b41d8eecbbb0fb0270247887f2b600",
"",
"reply"
],
[
"p",
"9456f7acb763eaab2e02bd8e60cf17df74f352c2ae579dce1f1dd25c95dd611c"
]
],
"content": "š
Original date posted:2018-11-15\nš Original message:\nGood morning list,\n\nAn 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).\nThis would allow some transition to future additional fields while maintaining backward compatibility.\n\nI believe these were brought up:\n\n1. For a sequence of `type,len,value`, each `type` must be unique. -- accepted.\n2. 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\nNow for bikeshedding:\n\n1, `type` - one byte or two?\n2. `type` - maybe some other name, since we already use `type` for messages? How about, `key` instead?\n3. `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...?\n4. `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`.\n5. `len` - one byte or two? I believe we tend to use two bytes for various lengths.\n6. BOLT - I propose making a separate BOLT for `type,len,value`, which other messages and so on simply refer to.\n\nRegards,\nZmnSCPxj\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181115/815ebee9/attachment.html\u003e",
"sig": "3b4f3a82e918a7ccf39ae533664e0d5f04d5303eb11bdc89fbaab9554715c613268c7c1dcdfb09b5a21cd11f2574f3bd8b06930e78cce88b60a34b2f5121c439"
}