summaryrefslogtreecommitdiff
path: root/9f/36cf648751e812ce20908548a0bed3be24fd55
blob: e175cfad00c5736d462dab2e8f8fb48cc84ee2ee (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
Return-Path: <dev@jonasschnelli.ch>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id E9B40AE7
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 24 Mar 2019 19:35:54 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from bitcoin.jonasschnelli.ch (bitcoinsrv.jonasschnelli.ch
	[138.201.55.219])
	by smtp1.linuxfoundation.org (Postfix) with ESMTP id 238A12D5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 24 Mar 2019 19:35:53 +0000 (UTC)
Received: by bitcoin.jonasschnelli.ch (Postfix, from userid 1002)
	id CF61A15E5006; Sun, 24 Mar 2019 20:35:52 +0100 (CET)
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	version=3.3.1
Received: from [192.168.0.3] (cable-static-236-151.teleport.ch
	[213.188.236.151])
	by bitcoin.jonasschnelli.ch (Postfix) with ESMTPSA id CE12215E46EE;
	Sun, 24 Mar 2019 20:35:51 +0100 (CET)
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>
X-Mailer: Apple Mail (2.3445.102.3)
X-Virus-Scanned: clamav-milter 0.100.2 at bitcoinsrv.jonasschnelli.ch
X-Virus-Status: Clean
X-Mailman-Approved-At: Mon, 25 Mar 2019 06:42:25 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] New BIP - v2 peer-to-peer message transport
 protocol (former BIP151)
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 24 Mar 2019 19:35:55 -0000


--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--