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
|
Return-Path: <dave@dtrt.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 49E58A7A
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 24 Mar 2019 13:30:35 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from newmail.dtrt.org (li1228-87.members.linode.com [45.79.129.87])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6A9E02D5
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 24 Mar 2019 13:30:33 +0000 (UTC)
Received: from harding by newmail.dtrt.org with local (Exim 4.89)
(envelope-from <dave@dtrt.org>)
id 1h83Cp-0004GH-Q3; Sun, 24 Mar 2019 09:30:31 -0400
Date: Sun, 24 Mar 2019 09:29:10 -0400
From: "David A. Harding" <dave@dtrt.org>
To: Jonas Schnelli <dev@jonasschnelli.ch>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20190324132910.ss2fe4nzoneazti5@email>
References: <26A4BEC6-403C-4534-8A2D-57C71D1736FB@jonasschnelli.ch>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="bhq2lx6nmnd6k5st"
Content-Disposition: inline
In-Reply-To: <26A4BEC6-403C-4534-8A2D-57C71D1736FB@jonasschnelli.ch>
User-Agent: NeoMutt/20170113 (1.7.2)
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Sun, 24 Mar 2019 14:28:52 +0000
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 13:30:35 -0000
--bhq2lx6nmnd6k5st
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Mar 22, 2019 at 10:04:46PM +0100, Jonas Schnelli via bitcoin-dev wr=
ote:
> =3D=3D=3D v2 Messages Structure =3D=3D=3D
>=20
> {|class=3D"wikitable"
> ! Field Size !! Description !! Data type !! Comments
> [...]
> | 1-13 || encrypted command || variable || ASCII command (or one byte sho=
rt command ID)
> [...]=20
> The command field MUST start with a byte that defines the length of the A=
SCII
> command string up to 12 chars (1 to 12) or a short command ID (see below).
> [...]=20
> =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.
Thanks,
-Dave
[1] src/protocol.cpp:
const static std::string allNetMessageTypes[] =3D {
NetMsgType::VERSION,
NetMsgType::VERACK,
NetMsgType::ADDR,
NetMsgType::INV,
NetMsgType::GETDATA,
NetMsgType::MERKLEBLOCK,
NetMsgType::GETBLOCKS,
NetMsgType::GETHEADERS,
NetMsgType::TX,
NetMsgType::HEADERS,
NetMsgType::BLOCK,
NetMsgType::GETADDR,
NetMsgType::MEMPOOL,
NetMsgType::PING,
NetMsgType::PONG,
NetMsgType::NOTFOUND,
NetMsgType::FILTERLOAD,
NetMsgType::FILTERADD,
NetMsgType::FILTERCLEAR,
NetMsgType::REJECT,
NetMsgType::SENDHEADERS,
NetMsgType::FEEFILTER,
NetMsgType::SENDCMPCT,
NetMsgType::CMPCTBLOCK,
NetMsgType::GETBLOCKTXN,
NetMsgType::BLOCKTXN,
};
--bhq2lx6nmnd6k5st
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEgxUkqkMp0LnoXjCr2dtBqWwiadMFAlyXhiUACgkQ2dtBqWwi
adOvkw//bELyZ8HKRSsqxUDRfqPTgue4sdUw33mN7LmhMiQ5h80CXoYFYZgWIFh4
E4Z/Xf1AdPJUCoc0c8FFwnlRU90/ZdjW3Ur2bCDL5VRI2jt8TkRXVuPl3e2RZ92g
qcJ3xQ64TBVeiPqYrKjvLyHLPH3mliOMACKDwX13DhFSyt4Xzl5cwney+niia87k
nBVnM3CeCgOTDQr+UjbU2m/etDxtR0PcMnrotT/nI6e6N25CZAUTlNE43MhYlwU/
lsRwFfEpKQPvh56UntVygk7cV2dFxof5ZG46U7fbp7UW2nJz9U5uScejALnacXK4
2KHEc60c1QztPQdbyki293pQbNghi2HknzdA5w3rnNSGmiCd6pVXOHXoBo/RXPsg
YbB+WN8xe6+ryegGXM7lnq4eEbyeDTFCryTK4HqK7I8pLHlBqLEj5KPcQngH0JSZ
C6/6J0+C+7LGMjCfII40ATTV2EHYa0/58pm5XZkMHS0t2t7kO8KgdInHHUzGCkfC
7W3umaCWxVOsQHLFc8uym+W7hdUbe3IHqSM3AThNK7phnoOstgPIh9yIEODe/7wx
sXpD0yYNGbKgzsesJciQq7qQ5LoBTmbwuHa28hNhHHsNvuC76JmZfMKRuf4LKEsK
FFrCYt9nw8xmKbcix/9KpNYoADRTZrLikRRymLrkCt+IA8zDLR0=
=T09R
-----END PGP SIGNATURE-----
--bhq2lx6nmnd6k5st--
|
