📅 Original date posted:2022-11-12
📝 Original message:Another idea...
On Thursday, November 10th, 2022 at 4:23 PM, Pieter Wuille via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Thursday, November 3rd, 2022 at 1:53 PM, Murch wrote:
>
> > From what I understand we'll have about 35 message types on the network
> > with the addition of BIP324. 256 possible IDs sounds like plenty room to
> > grow, but perhaps we can be a bit more conservative:
> >
> > We could use the first bit to signal a 2-byte message ID. That allows us
> > to express 128 IDs with 1 byte, but if we need more, we get a total of
> > 2^15 IDs across 2 bytes.
>
> Yeah, effectively treating the first 1 or 2 bytes as a simple variable
> length integer is a nice way of increasing the space at low cost.
The above would really result in having two separate variable-length encodings:
* First byte 1-12 to signify length of alphabetic command
* Otherwise first bit to signify length of short command
I think we can just merge the two and have a single variable-length command structure that can be used for both: command encodings are 1 to 12 bytes, each byte's top bit indicating whether another byte follows (the top bit of byte 11 has no special meaning).
This means:
* Every alphabetic command of L characters becomes L bytes.
* 102 non-alphabetic 1-byte commands can be assigned.
* 15708 non-alphabetic 2-byte commands can be assigned.
* etc
So this gives a uniform space which commands can be assigned from, and there is no strict need for thinking of the short-binary and long-alphabetic commands as distinct. In v2, some short ones would be treated as aliases for old long-alphabetic ones. But new commands could also just be introduced as short ones only (even in v1).
WDYT?
Cheers,
--
Pieter
Pieter Wuille [ARCHIVE] /
npub1tj…jtl6r
2023-06-07 23:16:42
in reply to nevent1q…79un
Author Public Key
npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6rPublished at
2023-06-07 23:16:42Event JSON
{
"id": "9e54f08997142d223056c0867403146e662cbabd28f28fd665e87f1aaaadf2c2",
"pubkey": "5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6",
"created_at": 1686179802,
"kind": 1,
"tags": [
[
"e",
"0b6976e30325aea9b669739427371b54a6cc5a5d15b03cbe62f2441b51dd9a2e",
"",
"root"
],
[
"e",
"efc66f08de0d5b6f92b77d96fe95e92d8ecab17f41856fc0440f6ea865695bb5",
"",
"reply"
],
[
"p",
"5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6"
]
],
"content": "📅 Original date posted:2022-11-12\n📝 Original message:Another idea...\n\nOn Thursday, November 10th, 2022 at 4:23 PM, Pieter Wuille via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e On Thursday, November 3rd, 2022 at 1:53 PM, Murch wrote:\n\u003e \n\u003e \u003e From what I understand we'll have about 35 message types on the network\n\u003e \u003e with the addition of BIP324. 256 possible IDs sounds like plenty room to\n\u003e \u003e grow, but perhaps we can be a bit more conservative:\n\u003e \u003e \n\u003e \u003e We could use the first bit to signal a 2-byte message ID. That allows us\n\u003e \u003e to express 128 IDs with 1 byte, but if we need more, we get a total of\n\u003e \u003e 2^15 IDs across 2 bytes.\n\u003e \n\u003e Yeah, effectively treating the first 1 or 2 bytes as a simple variable\n\u003e length integer is a nice way of increasing the space at low cost.\n\nThe above would really result in having two separate variable-length encodings:\n* First byte 1-12 to signify length of alphabetic command\n* Otherwise first bit to signify length of short command\n\nI think we can just merge the two and have a single variable-length command structure that can be used for both: command encodings are 1 to 12 bytes, each byte's top bit indicating whether another byte follows (the top bit of byte 11 has no special meaning).\n\nThis means:\n* Every alphabetic command of L characters becomes L bytes.\n* 102 non-alphabetic 1-byte commands can be assigned.\n* 15708 non-alphabetic 2-byte commands can be assigned.\n* etc\n\nSo this gives a uniform space which commands can be assigned from, and there is no strict need for thinking of the short-binary and long-alphabetic commands as distinct. In v2, some short ones would be treated as aliases for old long-alphabetic ones. But new commands could also just be introduced as short ones only (even in v1).\n\nWDYT?\n\nCheers,\n\n-- \nPieter",
"sig": "584dfd9b3aa36b250e8cafc69874518276c024cea2b32e5dab8a646852a132ac7eb463e8bf238cacb61892b3d55591e8f98df3c95726fee33f2341bd1e9b9f92"
}