From: Jonas Schnelli <dev@jonasschnelli.ch>
Message-Id: <EDE2573D-ED27-4140-91BE-D405BC3D238D@jonasschnelli.ch>
Content-Type: multipart/signed;
	boundary="Apple-Mail=_35C90815-CA33-4AFB-8FE2-04AAF3624D83";
	protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Sun, 24 Mar 2019 20:35:45 +0100
In-Reply-To: <20190324132910.ss2fe4nzoneazti5@email>
To: "David A. Harding" <dave@dtrt.org>
References: <26A4BEC6-403C-4534-8A2D-57C71D1736FB@jonasschnelli.ch>
	<20190324132910.ss2fe4nzoneazti5@email>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] New BIP - v2 peer-to-peer message transport
 protocol (former BIP151)
Precedence: list


--Apple-Mail=_35C90815-CA33-4AFB-8FE2-04AAF3624D83
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi Dave

Thanks for the review...

>> =3D=3D=3D=3D Short Command ID =3D=3D=3D=3D
>>=20
>> 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.
>=20
> 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=E2=80=99t make short IDs mandatory.
Though, there are little benefits for commands like VERSION, FILTERxx, =
SENDHEADERS, etc.,... and, we only(?!) have 244 short IDs.

/jonas


--Apple-Mail=_35C90815-CA33-4AFB-8FE2-04AAF3624D83
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEyhopCNzi8TB0xizeHrd2uwPHki0FAlyX3BEACgkQHrd2uwPH
ki0KWhAAwVB8mm2LW1lZnjQ6pJ5XvshDhA5DQqhL2L35vGVZeCk3LLuvRPyTAGn6
hvIsWSnEcTSp8UmXYR6eAg2mNaYhSaP6387QEO2wFIFWwlKge7B8qJtX1lslOIJq
8JLBsGBs7/RzaYDK7AifXaohBxCGC+ohdXXUcAukcJOZu57CxpL/IRIAAuedMSGG
/xjj/Xq64DZSnsFnaxtHy0QEQ7QeJHfR6SmGF2SJFVar6C7tOTLYAKJy4WY3R3JB
h7iV+oKyCivDUYYXRd/v0FAdAYy+EOOjZXwmmdWEOO+Fe4Zi8/4Xk3k7tc66idHu
nRpRRbFJyKNQTD+30IY7WAdd0zkliCAPQeN/HEP01ifzkqY05RykpsjuiwSZbZXR
xErO/M0eXfKUauSjY/O7yoOPSJsSk+KdOfQrIIC8ns94by8UFMafT3C3Z1K1c7Gm
+isrTCr3KjhervH3DHuVx88o/lQVdY7GRkZgA0hP08X6e0FN+P1Jc6+hqq3xs/S9
jjroIf0bMRWZejV218BhB5ud8uavhmBVCJBjlCOE6/I/6kS1NF9ug7UMZrdPx3Cz
nEYbUFeRhXhQF1HD30lI8kfb0rVQ0At997ANg/02r1AXkzEF/njMydqkmkSvHaiq
ZamHWAM2Ha0OBRrRV7YS/827i5qQIOlRvHZCn5SJ/RgK4eYybbo=
=K5zE
-----END PGP SIGNATURE-----

--Apple-Mail=_35C90815-CA33-4AFB-8FE2-04AAF3624D83--