📅 Original date posted:2019-03-24
📝 Original message:Hi Dave
Thanks for the review...
>> ==== Short Command ID ====
>>
>> To save valuable bandwidth, the v2 message format supports message command
>> short IDs for message types with high frequency. The ID/string mapping is a
>> peer to peer arrangement and MAY be negotiated between the initiating and
>> responding peer.
>
> Why is this optional and only specified here for some message types
> rather than being required by v2 and specified for all message types?
> There's only 26 different types at present[1], so it seems better to
> simply make this a one-byte fixed-length field than it is to deal with
> variable size, mapping negotiation, per-peer mapping in general, and
> (once the network is fully v2) the dual-logic of being able to process
> messages either from a short ID or a full command name.
One thing I was trying to avoid is some sort of central planing.
Strings as message command identifier do usually bring some sort of collision resistance when competitive implementations work on different features.
An example are the service bits where we AFAIK had an (almost) collision.
This is the main reason why I think we should avoid setting the short IDs mandatory (naturally by not giving all commands a short ID).
Short IDs do probably make most sense for messages with high frequency.
By only giving frequent messages a short ID, we may avoid ID collisions in future.
Short IDs can be altered with the message protocol version (not the transport protocol, the message protocol like 70015, etc.) and new/different negation should be straight forward.
I just ran some random stats (non representative) and inv makes about 66% of all messages (pruned peer, not helping IBDing others) followed by tx and getdata.
Those three probably deserve a short ID.
I have no big objection against adding short IDs for other commands as long as we don’t make short IDs mandatory.
Though, there are little benefits for commands like VERSION, FILTERxx, SENDHEADERS, etc.,... and, we only(?!) have 244 short IDs.
/jonas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190324/aef341d7/attachment.sig>;
Jonas Schnelli [ARCHIVE] /
npub1nf…3dtxs
2023-06-07 18:17:13
in reply to nevent1q…a6wq
Author Public Key
npub1nfrrurat393mqymf3s26pujyn5vujlem3pzcukr5p9d4qpklngxq43dtxsPublished at
2023-06-07 18:17:13Event JSON
{
"id": "3ef466ab023cbca2193ce602d7de0f68cceeefb900f4c8eaa583a8461bb294e1",
"pubkey": "9a463e0fab8963b013698c15a0f2449d19c97f3b88458e5874095b5006df9a0c",
"created_at": 1686161833,
"kind": 1,
"tags": [
[
"e",
"80c97dd2df409b16530ed2f49e103bbaab8425e612cdc0628ef2f4c2710f7674",
"",
"root"
],
[
"e",
"8b0ffcc74d5174c3647ac990eef76fbd624fddb3d61cfd5be90438a05b897fd8",
"",
"reply"
],
[
"p",
"d3574a24208f4e3d0821bb4a69a0c3ae842043d444fa5c4a8c49c369918a6fb2"
]
],
"content": "📅 Original date posted:2019-03-24\n📝 Original message:Hi Dave\n\nThanks for the review...\n\n\u003e\u003e ==== Short Command ID ====\n\u003e\u003e \n\u003e\u003e To save valuable bandwidth, the v2 message format supports message command\n\u003e\u003e short IDs for message types with high frequency. The ID/string mapping is a\n\u003e\u003e peer to peer arrangement and MAY be negotiated between the initiating and\n\u003e\u003e responding peer.\n\u003e \n\u003e Why is this optional and only specified here for some message types\n\u003e rather than being required by v2 and specified for all message types?\n\u003e There's only 26 different types at present[1], so it seems better to\n\u003e simply make this a one-byte fixed-length field than it is to deal with\n\u003e variable size, mapping negotiation, per-peer mapping in general, and\n\u003e (once the network is fully v2) the dual-logic of being able to process\n\u003e messages either from a short ID or a full command name.\n\nOne thing I was trying to avoid is some sort of central planing.\n\nStrings as message command identifier do usually bring some sort of collision resistance when competitive implementations work on different features.\nAn example are the service bits where we AFAIK had an (almost) collision.\nThis is the main reason why I think we should avoid setting the short IDs mandatory (naturally by not giving all commands a short ID).\n\nShort IDs do probably make most sense for messages with high frequency.\nBy only giving frequent messages a short ID, we may avoid ID collisions in future.\n\nShort IDs can be altered with the message protocol version (not the transport protocol, the message protocol like 70015, etc.) and new/different negation should be straight forward.\n\nI just ran some random stats (non representative) and inv makes about 66% of all messages (pruned peer, not helping IBDing others) followed by tx and getdata.\nThose three probably deserve a short ID.\n\nI have no big objection against adding short IDs for other commands as long as we don’t make short IDs mandatory.\nThough, there are little benefits for commands like VERSION, FILTERxx, SENDHEADERS, etc.,... and, we only(?!) have 244 short IDs.\n\n/jonas\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 833 bytes\nDesc: Message signed with OpenPGP\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190324/aef341d7/attachment.sig\u003e",
"sig": "3580f4f504d73236b5abf114d658b5ac1194d06ca5d1bf4b7b6fc8b3b98289fb1d585e8df86442b0b944e47c290bb5a49333aac3da6876b170bb992e8d735f18"
}