Another idea... On Thursday, November 10th, 2022 at 4:23 PM, Pieter Wuille via bitcoin-dev <bitcoin-dev@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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
