------- Original Message ------- On Friday, November 18th, 2022 at 3:24 AM, Anthony Towns <a...@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-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). > > Isn't that optimising for the wrong thing? Aren't the goals we want: > > 1) it should be easy to come up with a message identifier without > accidently conflicting with someone else's proposal > > 2) commonly used messages on the wire should have a short encoding > in order to save bandwidth > > 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 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. Cheers, -- Pieter _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
