From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 6733EC002D for ; Fri, 18 Nov 2022 08:25:02 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 34DD260B6F for ; Fri, 18 Nov 2022 08:25:02 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 34DD260B6F 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 smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5sjFX6kjHs7 for ; Fri, 18 Nov 2022 08:24:58 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org BFBF56063B Received: from azure.erisian.com.au (azure.erisian.com.au [172.104.61.193]) by smtp3.osuosl.org (Postfix) with ESMTPS id BFBF56063B for ; Fri, 18 Nov 2022 08:24:57 +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 1ovwg9-0005q8-6B; Fri, 18 Nov 2022 18:24:54 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Fri, 18 Nov 2022 18:24:49 +1000 Date: Fri, 18 Nov 2022 18:24:49 +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: Fri, 18 Nov 2022 08:25:02 -0000 On Sat, Nov 12, 2022 at 03:23:16AM +0000, Pieter Wuille via bitcoin-dev wrote: > Another idea... > This means: > * Every alphabetic command of L characters becomes L bytes. > * 102 non-alphabetic 1-byte commands can be assigned. > * 15708 non-alphabetic 2-byte commands can be assigned. (There are 128**L possible L-byte commands, 26**L alphabetic L-byte commands, and hence 128**L-26**L non-alphabetical L-byte commands) > * 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... Doing: -> VERSION <- VERSION <- SHORTMSG ["BIP324", "foo.org/experiment"] <- VERACK -> SHORTMSG ["BIP324"] -> VERACK -> SENDSHORTMSG "BIP324" [(13, "ADDRV3")] <- SENDSHORTMSG "BIP324" -> 34 (SENDHEADERS) -> 25 (GETHEADERS) ... where "SHORTMSG" lets you specify an array of tables you support (such as BIP324's), and, once you know both sides supports a table, you can send `SENDSHORTMSG` to choose the table you'll use to abbreviate messages you send, as well as any modifications to that table (like replacing ADDR with ADDRV3). Then when writing BIPs, you just choose a meaningful string ("ADDRV3"), and when implementing you send a one-time "SENDSHORTMSG" message to optimise the messages you'll send most often... As time goes on and the most common messages change, issue a new BIP with a new table so that your one-time SHORTIDs message becomes shorter too, at least when you connect to peers that also know about the new bip.. Could potentially support that without bip324, by taking over the one byte message space, presuming you don't have any one-character messages you actually want to send? Could do this /as well as/ the encoding above, I guess; then you would have bips specify alphabetic message ids, and use SENDSHORTMSG to dynamically (and sequentially) override/allocate non-alphabetic ids? That would presumably limit the number of non-alphabetic ids to how many you could specify in a single SENDSHORTIDs message, which I think would be up to something like 749k different 1/2/3/4/5/6-byte alphabetic message ids (encoded as 1/2/3-byte non-alphabetic messages). Probably some more specific limit would be better though. Cheers, aj