From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 63E61C002B for ; Mon, 20 Feb 2023 15:29:15 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 3E6D281BF5 for ; Mon, 20 Feb 2023 15:29:15 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 3E6D281BF5 Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key, unprotected) header.d=wuille.net header.i=@wuille.net header.a=rsa-sha256 header.s=protonmail3 header.b=PC/LsMiP 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 XO1TU1HenL6y for ; Mon, 20 Feb 2023 15:29:14 +0000 (UTC) X-Greylist: delayed 00:06:26 by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 14F0A81A34 Received: from mail-41104.protonmail.ch (mail-41104.protonmail.ch [185.70.41.104]) by smtp1.osuosl.org (Postfix) with ESMTPS id 14F0A81A34 for ; Mon, 20 Feb 2023 15:29:13 +0000 (UTC) Date: Mon, 20 Feb 2023 15:22:30 +0000 Authentication-Results: mail-41104.protonmail.ch; dkim=pass (2048-bit key) header.d=wuille.net header.i=@wuille.net header.b="PC/LsMiP" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wuille.net; s=protonmail3; t=1676906555; x=1677165755; bh=mpTev0iPu0kq8CKzFFIJnfTknGIzu3oMzhYJHCPyzlA=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=PC/LsMiPVbs3xw4QqCr0+pSxJOFRjQFCbSXakoMFgXOKgoHKx8P5gTcRTXT1lB70j fO4Hab1xCWN2FRbPJ4T77qSFqjqm8ELoPAxInCwjSxuK+2OJKG67VPL6H+0XQGIT1k Zriq+6qngquS28aV2gDv+Lur6Wmitx2D79kLz3ubFwS1EqhGtB30eCVeyeqwrWY95b PgldEy9P1QMtcvjY8eHqSt1GWLKGH4K8MIox1i1UDpvClgulqb5f1bYn8kSbmcD+65 ZOh+zYMNsGjSTLeMDOiNbnmZkqYoTUgwpJ5EKQQioj0bf5L3RgjbbCay54zhWZYkIw xWmhvHBX7T64w== To: Anthony Towns From: Pieter Wuille Message-ID: <1zGcFRzB9Has9bXWlYaOXXnOy9jxwLJvhkL_46OlA8JRsx2ultkYweDdPnW3Tbf145byXb8cG8pimWBT0qBBDaKisufJufP2wssDtigKass=@wuille.net> In-Reply-To: References: <56677685-619a-691f-d5bc-54b69fdb6ed2@bip324.com> <6b83c32e-59ca-65ef-2553-d66f8d117e56@bip324.com> Feedback-ID: 19463299:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 20 Feb 2023 15:59:19 +0000 Cc: Bitcoin Protocol Discussion , 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: Mon, 20 Feb 2023 15:29:15 -0000 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 w= rote: >=20 > > > 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. >=20 > 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 takes= . I just meant that if all negotiation of the mapping table happens just on= ce (before VERACK) and that negotiation itself happens without use of short= commands, then there is no need for re-negotiating short commands after th= ey are already in use. Nothing concrete, but I can imagine that that may si= mplify some implementations. Cheers, --=20 Pieter