From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 389B6C002D for ; Thu, 5 Jan 2023 23:13:05 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 069C840106 for ; Thu, 5 Jan 2023 23:13:05 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 069C840106 X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04j6kArmAbRp for ; Thu, 5 Jan 2023 23:13:00 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 28196400E4 Received: from azure.erisian.com.au (azure.erisian.com.au [172.104.61.193]) by smtp2.osuosl.org (Postfix) with ESMTPS id 28196400E4 for ; Thu, 5 Jan 2023 23:12:59 +0000 (UTC) Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au) by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian)) id 1pDZPq-0001N1-KP; Fri, 06 Jan 2023 09:12:55 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Fri, 06 Jan 2023 09:12:50 +1000 Date: Fri, 6 Jan 2023 09:12:50 +1000 From: Anthony Towns To: Pieter Wuille , Bitcoin Protocol Discussion Message-ID: References: <56677685-619a-691f-d5bc-54b69fdb6ed2@bip324.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [bitcoin-dev] Refreshed BIP324 X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2023 23:13:05 -0000 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` 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