public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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 --]

  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 [bitcoin-dev] Refreshed BIP324 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.one \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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