Murch [ARCHIVE] on Nostr: 📅 Original date posted:2022-11-03 📝 Original message:Hi Pieter, hello list, On ...
📅 Original date posted:2022-11-03
📝 Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221103/fa31bbc7/attachment.sig>;
📝 Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221103/fa31bbc7/attachment.sig>;