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
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
|
Return-Path: <sdaftuar@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 5B52B12A4
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 24 Sep 2015 18:02:30 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ob0-f177.google.com (mail-ob0-f177.google.com
[209.85.214.177])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3A1DE126
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 24 Sep 2015 18:02:29 +0000 (UTC)
Received: by obbmp4 with SMTP id mp4so64345912obb.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 24 Sep 2015 11:02:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:date:message-id:subject:from:to:content-type;
bh=wQxVN9UX/nlc/b3ry4Nf/n3RRvUnmFu8KVFEJh7S0Eo=;
b=pXGrl39B+/K1gmSbUJCCD0gZZZaEEzME1Jy5Qz69Fp2cDVufQhzABQZ2GoZWBSdmRh
RY8qVRVwWRxCQUl8pe0GT2s1oKI6wQMmuYessJxABz78JKnsOhEJKyV/k/2XmEcQlHza
dTCGsqEugACmuNPr0FAmJzDu3QGUyz91It/NnyJ/dq+p9+sVx0Uw1720z8GiYeKJ76aT
nxj31Q0xV6Fz4FalHfWwHSiyCiqBCBbMvOaHZtmpdGVv4EMRiSvKNjGt5pU7oFwfpZN7
cGwC6ALhSd9DsyK/rnF1I4SMY/WX4OXow2yHNjfr/0RQRjYHVZ1nPyGd1TwKY2iwDGsG
BwpQ==
MIME-Version: 1.0
X-Received: by 10.182.70.101 with SMTP id l5mr570094obu.51.1443117748474; Thu,
24 Sep 2015 11:02:28 -0700 (PDT)
Received: by 10.202.197.83 with HTTP; Thu, 24 Sep 2015 11:02:28 -0700 (PDT)
Date: Thu, 24 Sep 2015 14:02:28 -0400
Message-ID: <CAFp6fsHBbyVo21DnQKGBVJ7P=8NqOGJ-jv0-MH9WaBD6vauudA@mail.gmail.com>
From: Suhas Daftuar <sdaftuar@gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=089e0149c320c45a44052082080b
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: [bitcoin-dev] [BIP Proposal] New "sendheaders" p2p message
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Thu, 24 Sep 2015 18:02:30 -0000
--089e0149c320c45a44052082080b
Content-Type: text/plain; charset=UTF-8
Hi,
I'm proposing the addition of a new, optional p2p message to help improve
the way blocks are announced on the network. The draft BIP is available
here and pasted below:
https://gist.github.com/sdaftuar/465bf008f0a4768c0def
The goal of this p2p message is to facilitate nodes being able to
optionally announce blocks with headers messages rather than with inv's,
which is particularly beneficial since the introduction of headers-first
download in Bitcoin Core 0.10. In particular, this allows for more
efficient propagation of reorgs as it would eliminate a round trip in
network communication.
The implementation of this BIP (which includes code to directly fetch
blocks based on announced headers) is in
https://github.com/bitcoin/bitcoin/pull/6494. For additional background,
please also see https://github.com/bitcoin/bitcoin/issues/5982.
Note that this new p2p message is optional; nodes can feel free to ignore
and continue to use inv messages to announce new blocks.
Thanks to Pieter Wuille for suggesting this idea.
Draft BIP text:
<pre>
BIP: <unassigned>
Title: sendheaders message
Author: Suhas Daftuar <sdaftuar@chaincode.com>
Status: Draft
Type: Standards Track
Created: 2015-05-08
</pre>
==Abstract==
Add a new message, "sendheaders", which indicates that a node prefers to
receive new block announcements via a "headers" message rather than an
"inv".
==Motivation==
Since the introduction of "headers-first" downloading of blocks in 0.10,
blocks will not be processed unless
they are able to connect to a (valid) headers chain. Consequently, block
relay generally works
as follows:
# A node (N) announces the new tip with an "inv" message, containing the
block hash
# A peer (P) responds to the "inv" with a "getheaders" message (to request
headers up to the new tip) and a "getdata" message for the new tip itself
# N responds with a "headers" message (with the header for the new block
along with any preceding headers unknown to P) and a "block" message
containing the new block
However, in the case where a new block is being announced that builds on
the tip, it would be generally more efficient if the node N just announced
the block header for the new block, rather than just the block hash, and
saved the peer from generating and transmitting the getheaders message (and
the required block locator).
In the case of a reorg, where 1 or more blocks are disconnected, nodes
currently just send an "inv" for the new tip. Peers currently are able to
request the new tip immediately, but wait until the headers for the
intermediate blocks are delivered before requesting those blocks. By
announcing headers from the last fork point leading up to the new tip in
the block announcement, peers are able to request all the intermediate
blocks immediately.
==Specification==
# The sendheaders message is defined as an empty message where pchCommand
== "sendheaders"
# Upon receipt of a "sendheaders" message, the node will be permitted, but
not required, to announce new blocks by sending the header of the new block
(along with any other blocks that a node believes a peer might need in
order for the block to connect).
# Feature discovery is enabled by checking protocol version >= 70012
==Backward compatibility==
Older clients remain fully compatible and interoperable after this change.
==Implementation==
https://github.com/bitcoin/bitcoin/pull/6494
--089e0149c320c45a44052082080b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi,<div><br></div><div>I'm proposing the addition of a=
new, optional p2p message to help improve the way blocks are announced on =
the network.=C2=A0 The draft BIP is available here and pasted below:</div><=
div><div><a href=3D"https://gist.github.com/sdaftuar/465bf008f0a4768c0def">=
https://gist.github.com/sdaftuar/465bf008f0a4768c0def</a></div></div><div><=
br></div><div>The goal of this p2p message is to facilitate nodes being abl=
e to optionally announce blocks with headers messages rather than with inv&=
#39;s, which is particularly beneficial since the introduction of headers-f=
irst download in Bitcoin Core 0.10.=C2=A0 In particular, this allows for mo=
re efficient propagation of reorgs as it would eliminate a round trip in ne=
twork communication.</div><div><br></div><div>The implementation of this BI=
P (which includes code to directly fetch blocks based on announced headers)=
is in <a href=3D"https://github.com/bitcoin/bitcoin/pull/6494">https://git=
hub.com/bitcoin/bitcoin/pull/6494</a>.=C2=A0 For additional background, ple=
ase also see <a href=3D"https://github.com/bitcoin/bitcoin/issues/5982">htt=
ps://github.com/bitcoin/bitcoin/issues/5982</a>.</div><div><br></div><div>N=
ote that this new p2p message is optional; nodes can feel free to ignore an=
d continue to use inv messages to announce new blocks.</div><div><br></div>=
<div>Thanks to Pieter Wuille for suggesting this idea.</div><div><br></div>=
<div>Draft BIP text:</div><div><br></div><div><div><font face=3D"monospace,=
monospace"><pre></font></div><div><font face=3D"monospace, monospace=
">=C2=A0 BIP: <unassigned></font></div><div><font face=3D"monospace, =
monospace">=C2=A0 Title: sendheaders message</font></div><div><font face=3D=
"monospace, monospace">=C2=A0 Author: Suhas Daftuar <<a href=3D"mailto:s=
daftuar@chaincode.com">sdaftuar@chaincode.com</a>></font></div><div><fon=
t face=3D"monospace, monospace">=C2=A0 Status: Draft</font></div><div><font=
face=3D"monospace, monospace">=C2=A0 Type: Standards Track</font></div><di=
v><font face=3D"monospace, monospace">=C2=A0 Created: 2015-05-08</font></di=
v><div><font face=3D"monospace, monospace"></pre></font></div><div><f=
ont face=3D"monospace, monospace"><br></font></div><div><font face=3D"monos=
pace, monospace">=3D=3DAbstract=3D=3D</font></div><div><font face=3D"monosp=
ace, monospace"><br></font></div><div><font face=3D"monospace, monospace">A=
dd a new message, "sendheaders", which indicates that a node pref=
ers to receive new block announcements via a "headers" message ra=
ther than an "inv".</font></div><div><font face=3D"monospace, mon=
ospace"><br></font></div><div><font face=3D"monospace, monospace">=3D=3DMot=
ivation=3D=3D</font></div><div><font face=3D"monospace, monospace"><br></fo=
nt></div><div><font face=3D"monospace, monospace">Since the introduction of=
"headers-first" downloading of blocks in 0.10, blocks will not b=
e processed unless</font></div><div><font face=3D"monospace, monospace">the=
y are able to connect to a (valid) headers chain.=C2=A0 Consequently, block=
relay generally works</font></div><div><font face=3D"monospace, monospace"=
>as follows:</font></div><div><font face=3D"monospace, monospace"># A node =
(N) announces the new tip with an "inv" message, containing the b=
lock hash</font></div><div><font face=3D"monospace, monospace"># A peer (P)=
responds to the "inv" with a "getheaders" message (to =
request headers up to the new tip) and a "getdata" message for th=
e new tip itself</font></div><div><font face=3D"monospace, monospace"># N r=
esponds with a "headers" message (with the header for the new blo=
ck along with any preceding headers unknown to P) and a "block" m=
essage containing the new block</font></div><div><font face=3D"monospace, m=
onospace"><br></font></div><div><font face=3D"monospace, monospace">However=
, in the case where a new block is being announced that builds on the tip, =
it would be generally more efficient if the node N just announced the block=
header for the new block, rather than just the block hash, and saved the p=
eer from generating and transmitting the getheaders message (and the requir=
ed block locator).</font></div><div><font face=3D"monospace, monospace"><br=
></font></div><div><font face=3D"monospace, monospace">In the case of a reo=
rg, where 1 or more blocks are disconnected, nodes currently just send an &=
quot;inv" for the new tip.=C2=A0 Peers currently are able to request t=
he new tip immediately, but wait until the headers for the intermediate blo=
cks are delivered before requesting those blocks.=C2=A0 By announcing heade=
rs from the last fork point leading up to the new tip in the block announce=
ment, peers are able to request all the intermediate blocks immediately.</f=
ont></div><div><font face=3D"monospace, monospace"><br></font></div><div><f=
ont face=3D"monospace, monospace">=3D=3DSpecification=3D=3D</font></div><di=
v><font face=3D"monospace, monospace"><br></font></div><div><font face=3D"m=
onospace, monospace"># The sendheaders message is defined as an empty messa=
ge where pchCommand =3D=3D "sendheaders"</font></div><div><font f=
ace=3D"monospace, monospace"># Upon receipt of a "sendheaders" me=
ssage, the node will be permitted, but not required, to announce new blocks=
by sending the header of the new block (along with any other blocks that a=
node believes a peer might need in order for the block to connect).</font>=
</div><div><font face=3D"monospace, monospace"># Feature discovery is enabl=
ed by checking protocol version >=3D 70012</font></div><div><font face=
=3D"monospace, monospace"><br></font></div><div><font face=3D"monospace, mo=
nospace">=3D=3DBackward compatibility=3D=3D</font></div><div><font face=3D"=
monospace, monospace"><br></font></div><div><font face=3D"monospace, monosp=
ace">Older clients remain fully compatible and interoperable after this cha=
nge.</font></div><div><font face=3D"monospace, monospace"><br></font></div>=
<div><font face=3D"monospace, monospace">=3D=3DImplementation=3D=3D</font><=
/div><div><font face=3D"monospace, monospace"><br></font></div><div><font f=
ace=3D"monospace, monospace"><a href=3D"https://github.com/bitcoin/bitcoin/=
pull/6494">https://github.com/bitcoin/bitcoin/pull/6494</a></font></div></d=
iv></div>
--089e0149c320c45a44052082080b--
|
