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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
