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
|
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 7CF2F259
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Mar 2017 23:14:30 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f176.google.com (mail-qt0-f176.google.com
[209.85.216.176])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C0BB71E8
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Mar 2017 23:14:29 +0000 (UTC)
Received: by mail-qt0-f176.google.com with SMTP id n21so188897481qta.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Mar 2017 16:14:29 -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=YiWT7D99XFsHNcA4yUHJA1jMndmhLsjS7yBriv2iH14=;
b=Y15b/c+VqHFDFbRdlherFnAUiq1OBzy4MDOw+OQgNLvYAFUGGgQamMxgU4M3bCN9ey
AC29xrj5gB6gT4oJUAaHJT5K+qGfI6daOp4AGG1xshPVSKhhfd9ydmF/1627yxFKNskJ
WfpaKXE5KCFWcLftNiqZ5FLZPjSOE1opmXJTAol3OMTuHZZLBh0cCspzz+SCfNMbUgHR
XG59OERwxlycNH3OD5Jn2b7PuTpIRp1/fvjgnbPObhoH/949ImEAVUpsKScfyeXaswCv
EPWaLzNLRVn/kAnySeDbLz6f5auRvZpoZmZfm98Q4OoS8Qa9gYHGL64a8/or9lCbyFn6
DWRw==
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=YiWT7D99XFsHNcA4yUHJA1jMndmhLsjS7yBriv2iH14=;
b=Mqhq0ypkKCX7YGqnTI4y+V3EdWdmQQ4I1w/qb4fG1Uv/dDPI20zwqoUu8UiG+anvp5
9V5io9D/e1raEvpDZ9Din2KpQ1vcz54kwFHuM8ZkiDSA6J7dFFbsSH5TgcUX1lgmaSki
5ymytzNAr8mWGb/1DQCmMgwkbDfvPYUEkjBCiXJu3nJrYohuo5wi4ZZAeoBKyVZNholN
98C4oReDSSiKEk44FcfbnA2QHMYogAT9v+GVLr5I8RE5AacFlTrHW1t3b6fRZkLhCjo0
hubblG2teL0LocDYEfniTy6bjvwGbyvmWiJDfGeZVp7snBtzwS5PIXVRMb7mazcikhma
9Egg==
X-Gm-Message-State: AFeK/H3SgqmCh2mLm9DPzwAld3gFPNgVQ/vM59KfR5SJrSbU7u6O5WilIavUbQan2ckntw==
X-Received: by 10.237.43.68 with SMTP id p62mr4901408qtd.207.1490310868814;
Thu, 23 Mar 2017 16:14:28 -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 y3sm328954qke.59.2017.03.23.16.14.28
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Thu, 23 Mar 2017 16:14:28 -0700 (PDT)
To: Juan Garavaglia <jg@112bit.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <SC1P152MB1648D0F9DF4279C49D755233F53F0@SC1P152MB1648.LAMP152.PROD.OUTLOOK.COM>
From: Andrew Chow <achow101-lists@achow101.com>
Message-ID: <3fd9846c-6c57-9b57-0b6e-e5958e644e1d@achow101.com>
Date: Thu, 23 Mar 2017 19:14:28 -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: <SC1P152MB1648D0F9DF4279C49D755233F53F0@SC1P152MB1648.LAMP152.PROD.OUTLOOK.COM>
Content-Type: multipart/alternative;
boundary="------------D2C1106ADBA4B982BB3A2F48"
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: Thu, 23 Mar 2017 23:14:30 -0000
This is a multi-part message in MIME format.
--------------D2C1106ADBA4B982BB3A2F48
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
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
--------------D2C1106ADBA4B982BB3A2F48
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>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 class="moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>
<a 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>
</body>
</html>
--------------D2C1106ADBA4B982BB3A2F48--
|
