Date: Thu, 05 Jan 2023 22:06:29 +0000
To: Anthony Towns <aj@erisian.com.au>
From: Pieter Wuille <bitcoin-dev@wuille.net>
Message-ID: <gSxFQedPc72pTioi9vuxvLKpaRBsnKFL4gkPKPn2G-EJgz_2Y1pYQ7cHD5SnunyCaLln7UQEHIxnopqP74LlnK__Mf9BURbJW8B5MYTZvCU=@wuille.net>
In-Reply-To: <Y3dBUXPhTskCx+Fu@erisian.com.au>
References: <56677685-619a-691f-d5bc-54b69fdb6ed2@bip324.com>
 <zxv58iXZ73hf9ge8S0QLTanW-uLzaWjNtMHuKONP9hrqS5RhwitxzfVaMH8hbi3yImgNrKme3lCuDcHYKkpxEQHyGZZHJ8xtReOcnAx3o4g=@wuille.net>
 <Y2nK99fHUKxbPHmw@erisian.com.au>
 <wDqcIVw-YGTsjdf5M2GO9NNRl_UQuBeka2CUQUyQ329u6u-o7RabW_7S4FD3EDfk02kUczb3bXf8LtHhKLtx773UhQ7djKOl-JPOIrXqBSc=@wuille.net>
 <JXfTBjsA71dHE3h9wkxnWXANrwTbMADO4s2w34gEvMbiduKu4PEt5t-KA3EAIz-Xs4urjBHZ15NDFZST2a7e0x_NqyJymUnEORuTp3SNfMs=@wuille.net>
 <Y3dBUXPhTskCx+Fu@erisian.com.au>
Feedback-ID: 19463299:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Refreshed BIP324
Precedence: list

------- Original Message -------
On Friday, November 18th, 2022 at 3:24 AM, Anthony Towns <aj@erisian.com.au=
> wrote:

> > * 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-alphabeti=
c 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 introduce=
d as short ones only (even in v1).
>=20
> Isn't that optimising for the wrong thing? Aren't the goals we want:
>=20
> 1) it should be easy to come up with a message identifier without
> accidently conflicting with someone else's proposal
>=20
> 2) commonly used messages on the wire should have a short encoding
> in order to save bandwidth
>=20
> Depending on how much the p2p protocol ossifies, which messages are
> "commonly used on the wire" might be expected to change; and picking an
> otherwise meaningless value from a set of 102 elements seems likely to
> produce conflicts...

Oh, yes. I meant this as an encoding scheme, not as a (replacement for) the=
 negotiation/coordination mechanism. There could still be an initial assign=
ment for 1-byte encodings, and/or an explicit mechanism to negotiate other =
assignment, and/or nothing at all for now.

I just thought it would be interesting to have a uniform encoding without e=
xplicit distinction between "short commands" and "long commands" at that la=
yer.

But maybe none of this is worth it, as it's perhaps more complexity than th=
e alternative, and the alternative already has a working implementation and=
 written-up specification.

Cheers,

--=20
Pieter