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
|
Return-Path: <lf-lists@mattcorallo.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 1A8C9B1E
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Mar 2017 23:28:46 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.bluematt.me (mail.bluematt.me [192.241.179.72])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5F6C6127
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Mar 2017 23:28:45 +0000 (UTC)
Received: from [IPv6:2607:fb90:27db:b4f2:48d5:1575:9cd0:2768]
(ma10536d0.tmodns.net [208.54.5.161])
by mail.bluematt.me (Postfix) with ESMTPSA id 6DC11138335;
Thu, 23 Mar 2017 23:28:43 +0000 (UTC)
Date: Thu, 23 Mar 2017 23:01:09 +0000
In-Reply-To: <SC1P152MB1648D0F9DF4279C49D755233F53F0@SC1P152MB1648.LAMP152.PROD.OUTLOOK.COM>
References: <SC1P152MB1648D0F9DF4279C49D755233F53F0@SC1P152MB1648.LAMP152.PROD.OUTLOOK.COM>
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----MHX2UZ32ZCJXBF5CXXRABMR097QE7L"
Content-Transfer-Encoding: 7bit
To: Juan Garavaglia <jg@112bit.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
Juan Garavaglia via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
From: Matt Corallo <lf-lists@mattcorallo.com>
Message-ID: <9752F0E1-A339-4A2D-9574-843DE32AE5A3@mattcorallo.com>
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE
autolearn=ham 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:28:46 -0000
------MHX2UZ32ZCJXBF5CXXRABMR097QE7L
Content-Type: text/plain;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
I haven't investigated, but you may be seeing segwit-invalid blocks=2E=2E=
=2E0=2E13=2E0+ nodes will enforce segwit as it activated some time ago on t=
estnet, 0=2E12=2EX nodes will not=2E
On March 23, 2017 3:37:34 PM PDT, Juan Garavaglia via bitcoin-dev <bitcoin=
-dev@lists=2Elinuxfoundation=2Eorg> 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=2E 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=2E Nonetheless,
>well established explorers like blocktrail=2Ecom or blockr=2Eio were
>following different chains at different heights which led to me to
>believe that it was not a network issue=2E After some time, a reorg
>occurs and it all comes to normal state as a single chain=2E
>We started investigating more and we identified that the fork occurs
>with nodes 0=2E12; in some situations, nodes 0=2E12 has longer/different
>chains=2E The blocks in both chains are valid so something must be
>occurring in the communication between nodes but not related with the
>network itself=2E
>Long story short, when nodes 0=2E13+ receive blocks from 0=2E13+ nodes al=
l
>is ok, and those blocks propagate to older nodes with no issues=2E But
>when a block tries to be propagated from bitcoind 0=2E12=2E+ to newer one=
s
>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=2E
>My conclusion is that we have a backward compatibility issue between
>0=2E13=2EX+ and older versions=2E
>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=2E12=2EX and older, and y=
ou
>will notice that the latest version node will never receive a new
>block=2E
>Probably some alternative bitcoin implementations act as bridges
>between these two versions and facilitate the chain reorgs=2E
>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=2E13=2EX+ should
>remain compatible with older ones, but a 0=2E13+ node may become isolated
>by 0=2E12 peers, and there is not notice for the node owner=2E
------MHX2UZ32ZCJXBF5CXXRABMR097QE7L
Content-Type: text/html;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html v=3D"urn:schemas-microsoft-com:vml" o=3D"urn:schemas-microsoft-com:of=
fice:office" w=3D"urn:schemas-microsoft-com:office:word" m=3D"http://schema=
s=2Emicrosoft=2Ecom/office/2004/12/omml"><head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii=
" />
<meta name=3D"Generator" content=3D"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=2EMsoNormal, li=2EMsoNormal, div=2EMsoNormal
{margin-top:0in;
margin-right:0in;
margin-bottom:8=2E0pt;
margin-left:0in;
line-height:106%;
font-size:11=2E0pt;
font-family:"Calibri",sans-serif;}
a:link, span=2EMsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span=2EMsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
span=2EEmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
=2EMsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8=2E5in 11=2E0in;
margin:1=2E0in 1=2E0in 1=2E0in 1=2E0in;}
div=2EWordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head><body lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72">I haven'=
;t investigated, but you may be seeing segwit-invalid blocks=2E=2E=2E0=2E13=
=2E0+ nodes will enforce segwit as it activated some time ago on testnet, 0=
=2E12=2EX nodes will not=2E<br><br><div class=3D"gmail_quote">On March 23, =
2017 3:37:34 PM PDT, Juan Garavaglia via bitcoin-dev <bitcoin-dev@lists=
=2Elinuxfoundation=2Eorg> wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0pt 0pt 0pt 0=2E8ex; border-left: 1px solid rgb(204, 204, 204);=
padding-left: 1ex;">
<div class=3D"WordSection1">
<p class=3D"MsoNormal" style=3D"margin-left:=2E5in">We notice some reorgs =
in Bitcoin testnet, while reorgs in testnet are common and may be part of d=
ifferent tests and experiments, it seems the forks are not created by a sin=
gle user and multiple blocks were mined
by different users in each chain=2E My first impression was that th=
e problem was related to network issues but some Bitcoin explorers were fol=
lowing one chain while others follow the other one=2E Nonetheless, we=
ll established explorers like blocktrail=2Ecom or
blockr=2Eio were following different chains at different heights which le=
d to me to believe that it was not a network issue=2E After some time, a re=
org occurs and it all comes to normal state as a single chain=2E</p><p></p>
<p class=3D"MsoNormal" style=3D"margin-left:=2E5in">We started investigati=
ng more and we identified that the fork occurs with nodes 0=2E12; in some s=
ituations, nodes 0=2E12 has longer/different chains=2E The blocks in both c=
hains are valid so something must be occurring
in the communication between nodes but not related with the network itsel=
f=2E</p><p></p>
<p class=3D"MsoNormal" style=3D"margin-left:=2E5in">Long story short, when=
nodes 0=2E13+ receive blocks from 0=2E13+ nodes all is ok, and those block=
s propagate to older nodes with no issues=2E But when a block tries to be p=
ropagated from bitcoind 0=2E12=2E+ to newer ones
those blocks are NOT being propagated to the peers with newer versions wh=
ile these newer blocks are being propagated to peers with older versions wi=
th no issues=2E</p><p></p>
<p class=3D"MsoNormal" style=3D"margin-left:=2E5in">My conclusion is that =
we have a backward compatibility issue between 0=2E13=2EX+ and older versio=
ns=2E</p><p></p>
<p class=3D"MsoNormal" style=3D"margin-left:=2E5in">The issue is simple to=
replicate, first, get latest version of bitcoind, complete the IBD after i=
s at current height, then force it to use exclusively one or more peers of =
versions 0=2E12=2EX and older, and you will
notice that the latest version node will never receive a new block=2E</p>=
<p></p>
<p class=3D"MsoNormal" style=3D"margin-left:=2E5in">Probably some alternat=
ive bitcoin implementations act as bridges between these two versions and f=
acilitate the chain reorgs=2E</p><p></p>
<p class=3D"MsoNormal" style=3D"margin-left:=2E5in">I have not yet found a=
ny way where/how it can be used in a malicious way or be exploited by a min=
er but in theory Bitcoin 0=2E13=2EX+ should remain compatible with older on=
es, but a 0=2E13+ node may become isolated by
0=2E12 peers, and there is not notice for the node owner=2E</p><p></p>
<p class=3D"MsoNormal"></p><p> </p>
</div>
</blockquote></div></body></html>
------MHX2UZ32ZCJXBF5CXXRABMR097QE7L--
|
