From: Murch <murch@murch•one>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Refreshed BIP324
Date: Thu, 3 Nov 2022 13:53:26 -0400 [thread overview]
Message-ID: <d4272a20-b2a7-4ad8-9b41-8ce2b7ce827d@murch.one> (raw)
In-Reply-To: <zxv58iXZ73hf9ge8S0QLTanW-uLzaWjNtMHuKONP9hrqS5RhwitxzfVaMH8hbi3yImgNrKme3lCuDcHYKkpxEQHyGZZHJ8xtReOcnAx3o4g=@wuille.net>
[-- Attachment #1.1: Type: text/plain, Size: 1303 bytes --]
Hi Pieter, hello list,
On 26.10.22 12:39, Pieter Wuille via bitcoin-dev wrote:
> 1. The most straightforward solution is using the BIP process as-is: let BIP324
> introduce a fixed initial table, and future BIPs which introduce new
> messages can introduce new mapping entries for it. In theory, this is no
> worse than the current coordination difficulty about command strings, but
> in practice the risk of collisions due to competing proposals is of course
> significantly larger with 1-byte IDs vs. 12-byte strings.
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 to
grow, but perhaps we can be a bit more conservative:
We could use the first bit to signal a 2-byte message ID. That allows us
to express 128 IDs with 1 byte, but if we need more, we get a total of
2^15 IDs across 2 bytes.
I would not be too concerned about collisions. Firstly, message types
would probably be announced to the mailing list as part of the
corresponding BIP, secondly, any overlooked collision should become
apparent at implementation time. The risk could perhaps be further
mitigated by encouraging less prevalent message types to use a 2-byte ID.
Cheers,
Murch
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2022-11-03 17:53 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-08 12:59 Dhruv M
2022-10-26 16:39 ` Pieter Wuille
2022-10-27 7:28 ` Vasil Dimov
2022-11-03 17:53 ` Murch [this message]
2022-11-03 22:26 ` Jonas Schnelli
2022-11-08 3:20 ` Anthony Towns
2022-11-10 21:23 ` Pieter Wuille
2022-11-12 3:23 ` Pieter Wuille
2022-11-12 18:52 ` Yuval Kogman
2022-11-18 8:24 ` Anthony Towns
2023-01-05 22:06 ` Pieter Wuille
2023-01-05 23:12 ` Anthony Towns
2023-01-09 8:11 ` Anthony Towns
2023-02-16 17:43 ` Dhruv M
2023-02-17 15:51 ` Anthony Towns
2023-02-17 22:13 ` Pieter Wuille
2023-02-19 23:56 ` Anthony Towns
2023-02-20 15:22 ` Pieter Wuille
2023-02-21 16:03 ` Anthony Towns
2023-02-28 18:07 ` Dhruv M
2023-02-28 21:02 ` Erik Aronesty
2023-10-11 20:52 ` Tim Ruffing
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d4272a20-b2a7-4ad8-9b41-8ce2b7ce827d@murch.one \
--to=murch@murch$(echo .)one \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox