From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 769CBC002D for ; Tue, 8 Nov 2022 03:20:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 5E725408A6 for ; Tue, 8 Nov 2022 03:20:33 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 5E725408A6 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 s-vHpCyJoO99 for ; Tue, 8 Nov 2022 03:20:32 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 6334840516 Received: from azure.erisian.com.au (azure.erisian.com.au [172.104.61.193]) by smtp2.osuosl.org (Postfix) with ESMTPS id 6334840516 for ; Tue, 8 Nov 2022 03:20:32 +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 1osFA4-0006BR-6c; Tue, 08 Nov 2022 13:20:29 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Tue, 08 Nov 2022 13:20:23 +1000 Date: Tue, 8 Nov 2022 13:20:23 +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: Cc: Dhruv M 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: Tue, 08 Nov 2022 03:20:33 -0000 On Wed, Oct 26, 2022 at 04:39:02PM +0000, Pieter Wuille via bitcoin-dev wrote: > However, it obviously raises the question of how the mapping table between the > 1-byte IDs and the commands they represent should be maintained: > > 1. The most straightforward solution is using the BIP process as-is: let BIP324 > introduce a fixed initial table, and future BIPs which introduce new > messages can introduce new mapping entries for it. [...] > 3. Yet another possibility is not having a fixed table at all, and negotiate > the mapping dynamically. E.g. either side could send a message at > connection time with an explicit table of entries "when I send byte X, I > mean command Y". FWIW, I think these two options seem fine -- maintaining a purely local and hardcoded internal mapping of "message string C has id Y" where Y is capped by the number of commands you actually implement (presumably less than 65536 total) is easy, and providing a per-peer mapping from "byte X" to "id Y" then requires at most 512 bytes per peer, along with up to 3kB of initial setup to tell your peer what mappings you'll use. > Our idea is to start out with approach (1), with a mapping table effectively > managed by the BIP process directly, but if and when collisions become a > concern (maybe due to many parallel proposals, maybe because the number of > messages just grows too big), switch to approach (3), possibly even > differentially (the sent mappings are just additions/overwrites of the > BIP-defined table mappings, rather than a full mapping). I guess I think it would make sense to not start using a novel 1-byte message unless you've done something to introduce that message first; whether that's via approach (3) ("I'm going to use 0xE9 to mean pkgtxns") or via a multibyte feature support message ("I sent sendaddrv3 as a 10-byte message, that implies 0xA3 means addrv3 from now on"). I do still think it'd be better to recommend against reserving a byte for one-shot messages, and not do it for existing one-shot messages though. Cheers, aj