Date: Fri, 6 Jan 2023 09:12:50 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Pieter Wuille <bitcoin-dev@wuille.net>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <Y7dZctMlZtH6PEsz@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>
 <gSxFQedPc72pTioi9vuxvLKpaRBsnKFL4gkPKPn2G-EJgz_2Y1pYQ7cHD5SnunyCaLln7UQEHIxnopqP74LlnK__Mf9BURbJW8B5MYTZvCU=@wuille.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <gSxFQedPc72pTioi9vuxvLKpaRBsnKFL4gkPKPn2G-EJgz_2Y1pYQ7cHD5SnunyCaLln7UQEHIxnopqP74LlnK__Mf9BURbJW8B5MYTZvCU=@wuille.net>
Subject: Re: [bitcoin-dev] Refreshed BIP324
Precedence: list

On Thu, Jan 05, 2023 at 10:06:29PM +0000, Pieter Wuille via bitcoin-dev wrote:
> > > 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).
> Oh, yes. I meant this as an encoding scheme, not as a (replacement for) the negotiation/coordination mechanism. There could still be an initial assignment 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 explicit distinction between "short commands" and "long commands" at that layer.
> But maybe none of this is worth it, as it's perhaps more complexity than the alternative, and the alternative already has a working implementation and written-up specification.

Heh, I was just looking at this yesterday, but failing to quite reach
a conclusion.

One thing I hadn't realised about this was that it's not actually
a restriction compared to what we currently allow with p2p v1:
CMessageHeader::IsCommandValid() already rejects commands that use
characters outside of 0x20 to 0x7E, so the high bit is already available
for signalling when we reach the last byte.

The current implementation for 324 does the aliasing
as part of V2TransportDeserializer::GetMessage and
V2TransportSerializer::prepareForTransport. That makes a lot of sense,
but particularly if we were to negotiate short commands sometime around
VERSION or VERACK, it might make more sense for the aliasing to move up
to the protocol layer rather than have it close to the  wire layer. In
that case having a uniform encoding means we could just keep using
CSerializedNetMsg whether we're sending a short command or a multibyte
ascii command -- without a uniform encoding, if we wanted to move short
commands up a layer, I think we'd need to change CSerializedNetMsg to
have m_type be a `std::variant<uint8_t,std::string>` instead of just a
string, or something similar.

I think I'm leaning towards "it doesn't matter either way" though:

 * if we can negotiate short commands on a per-peer basis, then once
   negotiation's finished we'll only be using short commands so saving a
   byte on long commands doesn't matter much

 * if we've only got around 30 or 40 commands we understand anyway
   (even counting one-time-only negotiation stuff), then it doesn't
   matter if we can do 102, 126 or 242 short commands since those are
   all more than we need

 * whether we'd have to tweak an internal struct if we want to change
   the way our code is structured shouldn't really be much of an influence
   on protocol design...

Cheers,
aj