Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id C8F25C002B for ; Sun, 19 Feb 2023 23:56:16 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id ABCEA40A59 for ; Sun, 19 Feb 2023 23:56:16 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org ABCEA40A59 X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-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 hQvkySBX9Ocv for ; Sun, 19 Feb 2023 23:56:15 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 6F5EF404D3 Received: from cerulean.erisian.com.au (azure.erisian.com.au [172.104.61.193]) by smtp2.osuosl.org (Postfix) with ESMTPS id 6F5EF404D3 for ; Sun, 19 Feb 2023 23:56:15 +0000 (UTC) Received: from 60.42.96.58.static.exetel.com.au ([58.96.42.60] helo=sapphire.erisian.com.au) by cerulean.erisian.com.au with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1pTtXK-00045f-FT; Mon, 20 Feb 2023 09:56:11 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Mon, 20 Feb 2023 09:56:02 +1000 Date: Mon, 20 Feb 2023 09:56:02 +1000 From: Anthony Towns To: Pieter Wuille , Bitcoin Protocol Discussion Message-ID: References: <56677685-619a-691f-d5bc-54b69fdb6ed2@bip324.com> <6b83c32e-59ca-65ef-2553-d66f8d117e56@bip324.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam_score: -1.0 X-Spam_bar: - 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: Sun, 19 Feb 2023 23:56:16 -0000 On Fri, Feb 17, 2023 at 10:13:05PM +0000, Pieter Wuille via bitcoin-dev wrote: > > I think it's probably less complex to close some of the doors? > > 2) are short ids available/meaningful to send prior to VERACK being > > completed? > Ah, I hadn't considered this nuance. If we don't care about them being available before VERACK negotiation, then it may be possible to introduce a way to negotiate a different short id mapping table without needing a mechanism for *re*-negotiating. I think you still need/want two negotiation steps -- once to tell each other what tables you know about, once to choose a mutually recognised table and specify any additions. > > I think the things missing from the current list (and not currently in > > use by bitcoin core) are: > > bip 61: REJECT > > bip 331: GETPKGTXNS, PKGTXNS, ANCPKGINFO > Do you feel REJECT should be included? I don't think it matters much; reject messages are both rare and include a reason so you'd only be saving maybe 12 bytes out of 62 (~20%) for maybe 6000 messages a day per peer that sends reject messages, so 72kB/day/reject-peer? > Perhaps a possibility is having the transport layer translate short-command-number-N to the 12-byte command "\x00\x00..." + byte(N), and hand that to the application layer, which could then do the mapping? Presuming the transport layer also continues to reject commands that have a '\x00' byte at the start or in the middle (ie !IsCommandValid()), that seems pretty reasonable... Cheers, aj