From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id ED8FEC002D for ; Sat, 12 Nov 2022 03:23:34 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id B481060C03 for ; Sat, 12 Nov 2022 03:23:34 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org B481060C03 Authentication-Results: smtp3.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=KKNeS9YP 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_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84hpoGJfhZry for ; Sat, 12 Nov 2022 03:23:33 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org ED01560B00 Received: from mail-4317.proton.ch (mail-4317.proton.ch [185.70.43.17]) by smtp3.osuosl.org (Postfix) with ESMTPS id ED01560B00 for ; Sat, 12 Nov 2022 03:23:30 +0000 (UTC) Date: Sat, 12 Nov 2022 03:23:16 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wuille.net; s=protonmail3; t=1668223407; x=1668482607; bh=DdKr6mv5U9hosc8Ipw154WvPiXlL70Q+55jDxyGSK3Y=; 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=KKNeS9YPWKezt5QTVK9tgkwWlVrSmjLTuyDXQxjV/iMzzs7pdwjuXgI2LOVtqQlb0 EnA+cOfVAtXMOYpVOGvzqljYRLFdaYBBNAuc21S/ZynBIHUpdNn7+3PaF9549bIskB 50dRcssR6hrTIMq9ERG/kDN2r4U7ebxjVIHGcwhvSPDNpeNSyj6Q7UrbIrvVtvdVZY MkchFXUALWnOSphEgkIkuIJykE8bpvJGgxUm8HAL2ud688CyACgvF1wZ+pOwFnEWJx 25HZOIBa5Rnpwk3jDg5SRGcyKECVeIn+x4C35yZGTEVMAa12fIe1B5MCD//CyIbeFO tjBJIH0/9wJRg== To: Bitcoin Protocol Discussion 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: Sat, 12 Nov 2022 09:00:56 +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: Sat, 12 Nov 2022 03:23:35 -0000 Another idea... On Thursday, November 10th, 2022 at 4:23 PM, Pieter Wuille via bitcoin-dev = wrote: > On Thursday, November 3rd, 2022 at 1:53 PM, Murch wrote: >=20 > > From what I understand we'll have about 35 message types on the network > > with the addition of BIP324. 256 possible IDs sounds like plenty room t= o > > grow, but perhaps we can be a bit more conservative: > >=20 > > We could use the first bit to signal a 2-byte message ID. That allows u= s > > to express 128 IDs with 1 byte, but if we need more, we get a total of > > 2^15 IDs across 2 bytes. >=20 > Yeah, effectively treating the first 1 or 2 bytes as a simple variable > length integer is a nice way of increasing the space at low cost. The above would really result in having two separate variable-length encodi= ngs: * First byte 1-12 to signify length of alphabetic command * Otherwise first bit to signify length of short command I think we can just merge the two and have a single variable-length command= structure that can be used for both: command encodings are 1 to 12 bytes, = each byte's top bit indicating whether another byte follows (the top bit of= byte 11 has no special meaning). This means: * Every alphabetic command of L characters becomes L bytes. * 102 non-alphabetic 1-byte commands can be assigned. * 15708 non-alphabetic 2-byte commands can be assigned. * etc So this gives a uniform space which commands can be assigned from, and ther= e is no strict need for thinking of the short-binary and long-alphabetic co= mmands as distinct. In v2, some short ones would be treated as aliases for = old long-alphabetic ones. But new commands could also just be introduced as= short ones only (even in v1). WDYT? Cheers, --=20 Pieter