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 D5EECC002D for ; Thu, 5 Jan 2023 22:06:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 3A5FB82251 for ; Thu, 5 Jan 2023 22:06:54 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 3A5FB82251 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=lSTMtWFN X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 8sRTmEqChSaD for ; Thu, 5 Jan 2023 22:06:49 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 892DD8224E Received: from mail-4323.proton.ch (mail-4323.proton.ch [185.70.43.23]) by smtp1.osuosl.org (Postfix) with ESMTPS id 892DD8224E for ; Thu, 5 Jan 2023 22:06:48 +0000 (UTC) Date: Thu, 05 Jan 2023 22:06:29 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wuille.net; s=protonmail3; t=1672956405; x=1673215605; bh=MV8DbWx5aJ3zg4Ytg/oN9Y6gqwrDZYmn9ZGWmA+Dpg4=; 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=lSTMtWFNCUxpwX4LUdx3aDcjq7wbp8TDPqFla27yXdfp37N6wCDBMQ/TZqKooOCsl HMRHFnPmlVQe8vES4UCgd/zu6ZlU7iWvWuFX0l13qfDHf1uXLuQbqjRxj4wyLrA1s0 ivI/1VkrVPAVWzNAmsSo4RtD8zlAfmBmOwMicMRaT4gMRrYG+3/m6hlH/g90FwL9KR Uq+K5L/aWvXuRVVk3QB+Vcs75z6yGXNAaVfAhdCfqHyu3bP8q5IjvsufqTLAPoVBMi SCA/iYCVZUuC01dm0xacIYLYzlvxcaPvwm22mWB6uGSX8Jg2gse/MHMtXzvieEinVh tY+YeVatPAQPQ== To: Anthony Towns From: Pieter Wuille Message-ID: In-Reply-To: References: <56677685-619a-691f-d5bc-54b69fdb6ed2@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: Thu, 05 Jan 2023 22:15:06 +0000 Cc: Bitcoin Protocol Discussion 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: Thu, 05 Jan 2023 22:06:54 -0000 ------- Original Message ------- On Friday, November 18th, 2022 at 3:24 AM, Anthony Towns wrote: > > * 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-alphabeti= c 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 introduce= d as short ones only (even in v1). >=20 > Isn't that optimising for the wrong thing? Aren't the goals we want: >=20 > 1) it should be easy to come up with a message identifier without > accidently conflicting with someone else's proposal >=20 > 2) commonly used messages on the wire should have a short encoding > in order to save bandwidth >=20 > 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... Oh, yes. I meant this as an encoding scheme, not as a (replacement for) the= negotiation/coordination mechanism. There could still be an initial assign= ment for 1-byte encodings, and/or an explicit mechanism to negotiate other = assignment, and/or nothing at all for now. I just thought it would be interesting to have a uniform encoding without e= xplicit distinction between "short commands" and "long commands" at that la= yer. But maybe none of this is worth it, as it's perhaps more complexity than th= e alternative, and the alternative already has a working implementation and= written-up specification. Cheers, --=20 Pieter