Date: Sat, 12 Nov 2022 03:23:16 +0000
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: Pieter Wuille <bitcoin-dev@wuille.net>
Message-ID: <JXfTBjsA71dHE3h9wkxnWXANrwTbMADO4s2w34gEvMbiduKu4PEt5t-KA3EAIz-Xs4urjBHZ15NDFZST2a7e0x_NqyJymUnEORuTp3SNfMs=@wuille.net>
In-Reply-To: <wDqcIVw-YGTsjdf5M2GO9NNRl_UQuBeka2CUQUyQ329u6u-o7RabW_7S4FD3EDfk02kUczb3bXf8LtHhKLtx773UhQ7djKOl-JPOIrXqBSc=@wuille.net>
References: <56677685-619a-691f-d5bc-54b69fdb6ed2@bip324.com>
 <zxv58iXZ73hf9ge8S0QLTanW-uLzaWjNtMHuKONP9hrqS5RhwitxzfVaMH8hbi3yImgNrKme3lCuDcHYKkpxEQHyGZZHJ8xtReOcnAx3o4g=@wuille.net>
 <Y2nK99fHUKxbPHmw@erisian.com.au>
 <wDqcIVw-YGTsjdf5M2GO9NNRl_UQuBeka2CUQUyQ329u6u-o7RabW_7S4FD3EDfk02kUczb3bXf8LtHhKLtx773UhQ7djKOl-JPOIrXqBSc=@wuille.net>
Feedback-ID: 19463299:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Refreshed BIP324
Precedence: list

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:
>=20
> > 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 t=
o
> > grow, but perhaps we can be a bit more conservative:
> >=20
> > We could use the first bit to signal a 2-byte message ID. That allows u=
s
> > to express 128 IDs with 1 byte, but if we need more, we get a total of
> > 2^15 IDs across 2 bytes.
>=20
> 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 encodi=
ngs:
* 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 ther=
e is no strict need for thinking of the short-binary and long-alphabetic co=
mmands 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,

--=20
Pieter