From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 7896EC002B for ; Tue, 28 Feb 2023 18:16:03 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 72DB781AAB for ; Tue, 28 Feb 2023 18:16:02 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 72DB781AAB Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key, unprotected) header.d=bip324.com header.i=@bip324.com header.a=rsa-sha256 header.s=protonmail2 header.b=PwwcJ2mT X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJ22RNwkmBG4 for ; Tue, 28 Feb 2023 18:16:01 +0000 (UTC) X-Greylist: delayed 00:08:29 by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org AFD1081A5C Received: from mail-4327.protonmail.ch (mail-4327.protonmail.ch [185.70.43.27]) by smtp1.osuosl.org (Postfix) with ESMTPS id AFD1081A5C for ; Tue, 28 Feb 2023 18:16:00 +0000 (UTC) Date: Tue, 28 Feb 2023 18:07:06 +0000 Authentication-Results: mail-4321.protonmail.ch; dkim=pass (2048-bit key) header.d=bip324.com header.i=@bip324.com header.b="PwwcJ2mT" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bip324.com; s=protonmail2; t=1677607638; x=1677866838; bh=FkZRcVRnm2pB/b33jT/jmXex4zwMOUxFQKZsNR7kLas=; h=Date:To:From:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=PwwcJ2mTUACrADk3Q79+RkRZ7KYlax+f83XZUkCgoppLczulx+tgp0oNmGtgBX2As jI3izwS/2kDbqFQ/gJBuVSZNUFUlRjKJkS6WNI4tx+xbu97I0O1ku6HrDvJrTvj7im UC+X8RQQa18Qf9cOAdft4hYurhOb9oTNjG9QuoheZJTJZpbRyjep0eqN+xE//LtGJW bH0aMnE81s/srFZS8jUB2zlXcH1fDIV/uOzhP4BlPMKC6p+YHILMWTQVZfIXbVzrDz DS/rSdMf1gaiLQkWTq1al5JG4gHQuneMAw4AjwOxJbANnfHcv83tEAahh2axBaypJR dhEzTPwEMW70A== To: bitcoin-dev@lists.linuxfoundation.org From: Dhruv M Message-ID: In-Reply-To: References: <56677685-619a-691f-d5bc-54b69fdb6ed2@bip324.com> <6b83c32e-59ca-65ef-2553-d66f8d117e56@bip324.com> <1zGcFRzB9Has9bXWlYaOXXnOy9jxwLJvhkL_46OlA8JRsx2ultkYweDdPnW3Tbf145byXb8cG8pimWBT0qBBDaKisufJufP2wssDtigKass=@wuille.net> Feedback-ID: 44080706:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 28 Feb 2023 18:41:54 +0000 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, 28 Feb 2023 18:16:03 -0000 The relevant changes from this discussion about short 1-byte message type IDs are now in a PR for the bips repo: https://github.com/bitcoin/bips/pull/1428 On 2/21/23 08:03, Anthony Towns via bitcoin-dev wrote: > On Mon, Feb 20, 2023 at 03:22:30PM +0000, Pieter Wuille via bitcoin-dev w= rote: >> On Sunday, February 19th, 2023 at 6:56 PM, Anthony Towns wrote: >>> 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 bein= g available before VERACK negotiation, then it may be possible to introduce= a way to negotiate a different short id mapping table without needing a me= chanism 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. >> Right, I wasn't talking about how many steps/messages the negotiation ta= kes. I just meant that if all negotiation of the mapping table happens just= once (before VERACK) and that negotiation itself happens without use of sh= ort commands, then there is no need for re-negotiating short commands after= they are already in use. Nothing concrete, but I can imagine that that may= simplify some implementations. > Yeah; I was just thinking of the fact that currently the negotiation is: > > * send your VERSION message > * see what their VERSION message is > > * announce a bunch of features, depending on the version (or service > flags) > * send the VERACK (and GETADDR and final ALERT) > > * wait for their announcements and VERACK > * negotiation is finished; we know everything; we're ready to go > > which only gets you two steps if you send the short id stuff as part of > the VERSION message. Obviously you could just add an extra phase either > just before or just after the VERACK, though. > > I suppose being able to choose your own short id mapping from day 0 would > mean that every bip324 node could use a single short id mapping for all > outgoing messages, which might also make implementation marginally easier > (no need to use one table for modern nodes, but also support the original > table for old bip324 implementations)... > > Cheers, > aj > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev