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
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
|
Return-Path: <achow101-lists@achow101.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 67400A88
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 24 Mar 2017 03:38:23 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f172.google.com (mail-qk0-f172.google.com
[209.85.220.172])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6D812AD
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 24 Mar 2017 03:38:22 +0000 (UTC)
Received: by mail-qk0-f172.google.com with SMTP id v127so2097076qkb.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Mar 2017 20:38:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=achow101-com.20150623.gappssmtp.com; s=20150623;
h=subject:to:references:from:message-id:date:user-agent:mime-version
:in-reply-to; bh=XR7R4zt3rQgyt3Bn8/MYilygVxKjYCYJUvAxj0odxqY=;
b=n+rrowQAAlOeTbMEvDc0WMOBifmH9CKtmooWYI4QPL8aN4I++f1vBo52LAS5yCIz5Z
Xkt+mj10JRQaFBcKec0KX5LKpG5RbqkpBIvnUts9R4ACYAz4wuQFaqj60jeoE9oEskJe
Bpq817KVAAhLceFrkjGQ5CgSzbM1Y+z42IL5CRs0JsjGzcK63TQjYjSZFzawrYZeQKPt
HllUfFVDzpoVEhekGsdlkvxoNZusj36jFKwgG1E1kyNC2vtciwMWf+fRD+6f9SHBB6eC
8QGc0xbnTjh7/APEkXQUA0SszZWI6O1XAQR2IbScY/xebJoR+Xx4WVwgCGCXW8rJs+4L
529g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:subject:to:references:from:message-id:date
:user-agent:mime-version:in-reply-to;
bh=XR7R4zt3rQgyt3Bn8/MYilygVxKjYCYJUvAxj0odxqY=;
b=CpMsRhcGWzYKxaNPJyXlOQ/HuLjmtLrRL0AKHCmNC4LtG9AkpDVKkcTR+jXGxM3l5m
drnK2vbzDA9iTAO3N6oBn+ACnM0Tz3Bjq/YMQIxyJk7GcZUaecilaMi9GCcBHeIIOrGh
drWllrlS6TYTHu4GnEMb5fnmV9KNLTPIMPBUpeUDtGr2vjbPdgq2VODRwB592+Cqj553
bGLU0JLvRBzth+1JPpJVp63FAvndfeLD6tAYVgQBUv9oHggMM2HXiI97W3k90uwpaA+y
zQkBZxzCIGDL/i1hgVFwhvxRTnf84g3Bc6jBduPgEUBisgmo3OTRSHk+VyhUmeruvpdo
Bexg==
X-Gm-Message-State: AFeK/H2AAJkBD9y6NEwW8lG29yXEyAwZcuZgL/dknRJ1hN5J2ctvOn2y5WhG/tNJE0lQHw==
X-Received: by 10.55.49.70 with SMTP id x67mr5108732qkx.186.1490326701370;
Thu, 23 Mar 2017 20:38:21 -0700 (PDT)
Received: from ?IPv6:2601:45:8200:e070:cdd4:fd6a:c2b2:a135?
([2601:45:8200:e070:cdd4:fd6a:c2b2:a135])
by smtp.gmail.com with ESMTPSA id w63sm717519qte.38.2017.03.23.20.38.20
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Thu, 23 Mar 2017 20:38:20 -0700 (PDT)
To: Juan Garavaglia <jg@112bit.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <SC1P152MB1648D0F9DF4279C49D755233F53F0@SC1P152MB1648.LAMP152.PROD.OUTLOOK.COM>
<3fd9846c-6c57-9b57-0b6e-e5958e644e1d@achow101.com>
From: Andrew Chow <achow101-lists@achow101.com>
Message-ID: <2caa270f-9feb-4720-9b68-eff458cdc956@achow101.com>
Date: Thu, 23 Mar 2017 23:38:21 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <3fd9846c-6c57-9b57-0b6e-e5958e644e1d@achow101.com>
Content-Type: multipart/alternative;
boundary="------------FEC3CC8897C04E05CE3D2D12"
X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, HTML_MESSAGE, RCVD_IN_DNSWL_NONE,
RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Issolated Bitcoin Nodes
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: Fri, 24 Mar 2017 03:38:23 -0000
This is a multi-part message in MIME format.
--------------FEC3CC8897C04E05CE3D2D12
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
A correction to my previous email (because people are quoting me on
r/btc and what I wrote was wrong)
This statement is incorrect:
> Given that Testnet has a smaller number of nodes and less difficulty,
this could result in some miners using 0.13.0+ mining blocks which do
not propagate well and thus causing multiple chain splits and reorgs as
other miners find blocks for the same height before receiving a block
for that height.
Miners using 0.13.0+ will produce blocks that propagate well. This is
because 0.12.x- nodes will accept those blocks, and so will 0.13.0+.
Furthermore Core 0.13.0+ will use its outbound connections to connect to
segwit enabled peers so that it will be relaying segwit blocks to
someone. However Bitcoin Core 0.13.0+ will not request blocks from peers
that are not segwit enabled (because with segwit, they will be receiving
blocks without witnesses which are invalid to a segwit node), so they
will not receive blocks mined by a 0.12.x- node. This means that 0.12.x-
mined blocks propagate poorly, even though are valid. Because of the
poor propagation, a 0.13.0+ miner can find a block at the same height
which is more likely to get built upon. However, the poorly propagated
block can still reach other 0.12.x- miners who can build upon it due to
the low difficulty and difficulty resets, thus causing multiple chains
to exist, particularly among pockets of 0.12.x- nodes. The reorgs happen
when either the 0.12.x- nodes hear of the segwit blockchain that is
presumably longer because it has the majority hashrate, or when people
run bridges which allow 0.12.x- nodes relay blocks to 0.13.0+ nodes.
On 3/23/2017 7:14 PM, Andrew Chow wrote:
>
> The issue is due to Segwit blocks since Testnet has already activated
> Segwit. 0.12.x- nodes will receive a Segwit block with all of the
> witnesses stripped. When they relay this block to a 0.13.0+ node, the
> block will be rejected because those have Segwit functionality and
> require the witnesses to be in the block. Given that Testnet has a
> smaller number of nodes and less difficulty, this could result in some
> miners using 0.13.0+ mining blocks which do not propagate well and
> thus causing multiple chain splits and reorgs as other miners find
> blocks for the same height before receiving a block for that height.
>
>
> On 3/23/2017 6:37 PM, Juan Garavaglia via bitcoin-dev wrote:
>>
>> We notice some reorgs in Bitcoin testnet, while reorgs in testnet are
>> common and may be part of different tests and experiments, it seems
>> the forks are not created by a single user and multiple blocks were
>> mined by different users in each chain. My first impression was that
>> the problem was related to network issues but some Bitcoin explorers
>> were following one chain while others follow the other one.
>> Nonetheless, well established explorers like blocktrail.com or
>> blockr.io were following different chains at different heights which
>> led to me to believe that it was not a network issue. After some
>> time, a reorg occurs and it all comes to normal state as a single chain.
>>
>> We started investigating more and we identified that the fork occurs
>> with nodes 0.12; in some situations, nodes 0.12 has longer/different
>> chains. The blocks in both chains are valid so something must be
>> occurring in the communication between nodes but not related with the
>> network itself.
>>
>> Long story short, when nodes 0.13+ receive blocks from 0.13+ nodes
>> all is ok, and those blocks propagate to older nodes with no issues.
>> But when a block tries to be propagated from bitcoind 0.12.+ to newer
>> ones those blocks are NOT being propagated to the peers with newer
>> versions while these newer blocks are being propagated to peers with
>> older versions with no issues.
>>
>> My conclusion is that we have a backward compatibility issue between
>> 0.13.X+ and older versions.
>>
>> The issue is simple to replicate, first, get latest version of
>> bitcoind, complete the IBD after is at current height, then force it
>> to use exclusively one or more peers of versions 0.12.X and older,
>> and you will notice that the latest version node will never receive a
>> new block.
>>
>> Probably some alternative bitcoin implementations act as bridges
>> between these two versions and facilitate the chain reorgs.
>>
>> I have not yet found any way where/how it can be used in a malicious
>> way or be exploited by a miner but in theory Bitcoin 0.13.X+ should
>> remain compatible with older ones, but a 0.13+ node may become
>> isolated by 0.12 peers, and there is not notice for the node owner.
>>
>>
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--------------FEC3CC8897C04E05CE3D2D12
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>A correction to my previous email (because people are quoting me
on r/btc and what I wrote was wrong)</p>
<p>This statement is incorrect:</p>
<p>> Given that Testnet has a smaller number of nodes and less
difficulty, this could result in some miners using 0.13.0+ mining
blocks which do not propagate well and thus causing multiple chain
splits and reorgs as other miners find blocks for the same height
before receiving a block for that height.</p>
<p>Miners using 0.13.0+ will produce blocks that propagate well.
This is because 0.12.x- nodes will accept those blocks, and so
will 0.13.0+. Furthermore Core 0.13.0+ will use its outbound
connections to connect to segwit enabled peers so that it will be
relaying segwit blocks to someone. However Bitcoin Core 0.13.0+
will not request blocks from peers that are not segwit enabled
(because with segwit, they will be receiving blocks without
witnesses which are invalid to a segwit node), so they will not
receive blocks mined by a 0.12.x- node. This means that 0.12.x-
mined blocks propagate poorly, even though are valid. Because of
the poor propagation, a 0.13.0+ miner can find a block at the same
height which is more likely to get built upon. However, the poorly
propagated block can still reach other 0.12.x- miners who can
build upon it due to the low difficulty and difficulty resets,
thus causing multiple chains to exist, particularly among pockets
of 0.12.x- nodes. The reorgs happen when either the 0.12.x- nodes
hear of the segwit blockchain that is presumably longer because it
has the majority hashrate, or when people run bridges which allow
0.12.x- nodes relay blocks to 0.13.0+ nodes.<br>
</p>
<div class="moz-cite-prefix">On 3/23/2017 7:14 PM, Andrew Chow
wrote:<br>
</div>
<blockquote
cite="mid:3fd9846c-6c57-9b57-0b6e-e5958e644e1d@achow101.com"
type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<p>The issue is due to Segwit blocks since Testnet has already
activated Segwit. 0.12.x- nodes will receive a Segwit block with
all of the witnesses stripped. When they relay this block to a
0.13.0+ node, the block will be rejected because those have
Segwit functionality and require the witnesses to be in the
block. Given that Testnet has a smaller number of nodes and less
difficulty, this could result in some miners using 0.13.0+
mining blocks which do not propagate well and thus causing
multiple chain splits and reorgs as other miners find blocks for
the same height before receiving a block for that height.<br>
</p>
<br>
<div class="moz-cite-prefix">On 3/23/2017 6:37 PM, Juan Garavaglia
via bitcoin-dev wrote:<br>
</div>
<blockquote
cite="mid:SC1P152MB1648D0F9DF4279C49D755233F53F0@SC1P152MB1648.LAMP152.PROD.OUTLOOK.COM"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin-top:0in;
margin-right:0in;
margin-bottom:8.0pt;
margin-left:0in;
line-height:106%;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal" style="margin-left:.5in">We notice some
reorgs in Bitcoin testnet, while reorgs in testnet are
common and may be part of different tests and experiments,
it seems the forks are not created by a single user and
multiple blocks were mined by different users in each
chain. My first impression was that the problem was related
to network issues but some Bitcoin explorers were following
one chain while others follow the other one. Nonetheless,
well established explorers like blocktrail.com or blockr.io
were following different chains at different heights which
led to me to believe that it was not a network issue. After
some time, a reorg occurs and it all comes to normal state
as a single chain.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">We started
investigating more and we identified that the fork occurs
with nodes 0.12; in some situations, nodes 0.12 has
longer/different chains. The blocks in both chains are valid
so something must be occurring in the communication between
nodes but not related with the network itself.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">Long story
short, when nodes 0.13+ receive blocks from 0.13+ nodes all
is ok, and those blocks propagate to older nodes with no
issues. But when a block tries to be propagated from
bitcoind 0.12.+ to newer ones those blocks are NOT being
propagated to the peers with newer versions while these
newer blocks are being propagated to peers with older
versions with no issues.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">My conclusion is
that we have a backward compatibility issue between 0.13.X+
and older versions.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">The issue is
simple to replicate, first, get latest version of bitcoind,
complete the IBD after is at current height, then force it
to use exclusively one or more peers of versions 0.12.X and
older, and you will notice that the latest version node will
never receive a new block.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">Probably some
alternative bitcoin implementations act as bridges between
these two versions and facilitate the chain reorgs.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">I have not yet
found any way where/how it can be used in a malicious way or
be exploited by a miner but in theory Bitcoin 0.13.X+ should
remain compatible with older ones, but a 0.13+ node may
become isolated by 0.12 peers, and there is not notice for
the node owner.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
bitcoin-dev mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a>
</pre>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>
--------------FEC3CC8897C04E05CE3D2D12--
|
