From: Anthony Towns <aj@erisian•com.au>
To: Pieter Wuille <bitcoin-dev@wuille•net>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Refreshed BIP324
Date: Fri, 6 Jan 2023 09:12:50 +1000 [thread overview]
Message-ID: <Y7dZctMlZtH6PEsz@erisian.com.au> (raw)
In-Reply-To: <gSxFQedPc72pTioi9vuxvLKpaRBsnKFL4gkPKPn2G-EJgz_2Y1pYQ7cHD5SnunyCaLln7UQEHIxnopqP74LlnK__Mf9BURbJW8B5MYTZvCU=@wuille.net>
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
next prev parent reply other threads:[~2023-01-05 23:13 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-08 12:59 Dhruv M
2022-10-26 16:39 ` Pieter Wuille
2022-10-27 7:28 ` Vasil Dimov
2022-11-03 17:53 ` Murch
2022-11-03 22:26 ` Jonas Schnelli
2022-11-08 3:20 ` Anthony Towns
2022-11-10 21:23 ` Pieter Wuille
2022-11-12 3:23 ` Pieter Wuille
2022-11-12 18:52 ` Yuval Kogman
2022-11-18 8:24 ` Anthony Towns
2023-01-05 22:06 ` Pieter Wuille
2023-01-05 23:12 ` Anthony Towns [this message]
2023-01-09 8:11 ` Anthony Towns
2023-02-16 17:43 ` Dhruv M
2023-02-17 15:51 ` Anthony Towns
2023-02-17 22:13 ` Pieter Wuille
2023-02-19 23:56 ` Anthony Towns
2023-02-20 15:22 ` Pieter Wuille
2023-02-21 16:03 ` Anthony Towns
2023-02-28 18:07 ` Dhruv M
2023-02-28 21:02 ` Erik Aronesty
2023-10-11 20:52 ` Tim Ruffing
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y7dZctMlZtH6PEsz@erisian.com.au \
--to=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=bitcoin-dev@wuille$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox