Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2022-11-08 📝 Original message:On Wed, Oct 26, 2022 at ...
📅 Original date posted:2022-11-08
📝 Original message:On Wed, Oct 26, 2022 at 04:39:02PM +0000, Pieter Wuille via bitcoin-dev wrote:
> However, it obviously raises the question of how the mapping table between the
> 1-byte IDs and the commands they represent should be maintained:
>
> 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. [...]
> 3. Yet another possibility is not having a fixed table at all, and negotiate
> the mapping dynamically. E.g. either side could send a message at
> connection time with an explicit table of entries "when I send byte X, I
> mean command Y".
FWIW, I think these two options seem fine -- maintaining a purely local
and hardcoded internal mapping of "message string C has id Y" where Y
is capped by the number of commands you actually implement (presumably
less than 65536 total) is easy, and providing a per-peer mapping from
"byte X" to "id Y" then requires at most 512 bytes per peer, along with
up to 3kB of initial setup to tell your peer what mappings you'll use.
> Our idea is to start out with approach (1), with a mapping table effectively
> managed by the BIP process directly, but if and when collisions become a
> concern (maybe due to many parallel proposals, maybe because the number of
> messages just grows too big), switch to approach (3), possibly even
> differentially (the sent mappings are just additions/overwrites of the
> BIP-defined table mappings, rather than a full mapping).
I guess I think it would make sense to not start using a novel 1-byte
message unless you've done something to introduce that message first;
whether that's via approach (3) ("I'm going to use 0xE9 to mean pkgtxns")
or via a multibyte feature support message ("I sent sendaddrv3 as a
10-byte message, that implies 0xA3 means addrv3 from now on").
I do still think it'd be better to recommend against reserving a byte for
one-shot messages, and not do it for existing one-shot messages though.
Cheers,
aj
📝 Original message:On Wed, Oct 26, 2022 at 04:39:02PM +0000, Pieter Wuille via bitcoin-dev wrote:
> However, it obviously raises the question of how the mapping table between the
> 1-byte IDs and the commands they represent should be maintained:
>
> 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. [...]
> 3. Yet another possibility is not having a fixed table at all, and negotiate
> the mapping dynamically. E.g. either side could send a message at
> connection time with an explicit table of entries "when I send byte X, I
> mean command Y".
FWIW, I think these two options seem fine -- maintaining a purely local
and hardcoded internal mapping of "message string C has id Y" where Y
is capped by the number of commands you actually implement (presumably
less than 65536 total) is easy, and providing a per-peer mapping from
"byte X" to "id Y" then requires at most 512 bytes per peer, along with
up to 3kB of initial setup to tell your peer what mappings you'll use.
> Our idea is to start out with approach (1), with a mapping table effectively
> managed by the BIP process directly, but if and when collisions become a
> concern (maybe due to many parallel proposals, maybe because the number of
> messages just grows too big), switch to approach (3), possibly even
> differentially (the sent mappings are just additions/overwrites of the
> BIP-defined table mappings, rather than a full mapping).
I guess I think it would make sense to not start using a novel 1-byte
message unless you've done something to introduce that message first;
whether that's via approach (3) ("I'm going to use 0xE9 to mean pkgtxns")
or via a multibyte feature support message ("I sent sendaddrv3 as a
10-byte message, that implies 0xA3 means addrv3 from now on").
I do still think it'd be better to recommend against reserving a byte for
one-shot messages, and not do it for existing one-shot messages though.
Cheers,
aj