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
|
Return-Path: <jg@112bit.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id EF8C24A6
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Mar 2017 22:37:41 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com
[67.231.154.164])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EE233106
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Mar 2017 22:37:40 +0000 (UTC)
Received: from pure.maildistiller.com (unknown [10.110.50.29])
by dispatch1-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server)
with ESMTP id 3A5276006F for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Mar 2017 22:37:40 +0000 (UTC)
X-Virus-Scanned: Proofpoint Essentials engine
Received: from mx3-us3.ppe-hosted.com (unknown [10.110.49.251])
by pure.maildistiller.com (Proofpoint Essentials ESMTP Server) with
ESMTPS id 940E060053 for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Mar 2017 22:37:39 +0000 (UTC)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com
(mail-by2nam01lp0178.outbound.protection.outlook.com
[216.32.181.178])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits))
(No client certificate requested)
by mx3-us3.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with
ESMTPS id 2B9926007A for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Mar 2017 22:37:39 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=NETORG2631885.onmicrosoft.com; s=selector1-112bit-com;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version;
bh=PadG0is8MLXe+LAn3epjLV5sl33zBqyPWao9rxKlMzY=;
b=FohODzFOPhenYIB/9zaHAn9+5aAnbeMFdADtt0L4d+RDYQZY2gg2osBQqk40H2/LySywvV3c4lAUl/jhhwU7taffBfs11aGrnuKc2P7bpLH/whqvcAx66+ssq5JETpbEEFrEs5ctItpuY3msCBR904aYZRdVg9T++nOapT2o5B4=
Received: from SC1P152MB1648.LAMP152.PROD.OUTLOOK.COM (10.171.68.8) by
SC1P152MB1645.LAMP152.PROD.OUTLOOK.COM (10.171.67.148) with Microsoft
SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id
15.1.977.11; Thu, 23 Mar 2017 22:37:34 +0000
Received: from SC1P152MB1648.LAMP152.PROD.OUTLOOK.COM ([10.171.68.8]) by
SC1P152MB1648.LAMP152.PROD.OUTLOOK.COM ([10.171.68.8]) with mapi id
15.01.0947.022; Thu, 23 Mar 2017 22:37:34 +0000
From: Juan Garavaglia <jg@112bit.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Thread-Topic: Issolated Bitcoin Nodes
Thread-Index: AdKkJg2YWuE1Y1o1TBGNcvF0JByzDg==
Date: Thu, 23 Mar 2017 22:37:34 +0000
Message-ID: <SC1P152MB1648D0F9DF4279C49D755233F53F0@SC1P152MB1648.LAMP152.PROD.OUTLOOK.COM>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: lists.linuxfoundation.org; dkim=none (message not
signed) header.d=none; lists.linuxfoundation.org; dmarc=none action=none
header.from=112bit.com;
x-originating-ip: [201.252.72.209]
x-ms-office365-filtering-correlation-id: 050a85b9-4d0e-457f-f253-08d4723d3376
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075);
SRVR:SC1P152MB1645;
x-microsoft-exchange-diagnostics: 1; SC1P152MB1645;
7:pBuZ96SAZLIo9Xa6nDSghKUjcC7d+qTQBa2DOMOfOB8/feMguNpHPbmzdXlkUVeJHbBlPSLdPjKHZBcvzTxjngqFYsvvpKLc7g27Z/kbXkMI7wVNxhSU+B6cZ5tW/pOatTVQ0dNIvF/bdkNBmj9mdNZUjrElHs5Xbw/MmugLZOhyj8LUuG8fM/9k0Du6+acAesTZ7K2SGbFfrysoNBd2DaxgXerdphI0UTRK/bQmLHxbDbq3ZlDqQmXwjHiS/itseRYDPvayARd6T5Si3T7zYNy85/33pfFaaKrk29FFJEVVbWK/yD1lcUaDcdGUqXdDopWlcnrT+mBGkRB221tv0g==;
20:uPOWyq429xp+rKO0AcL00Plbl86lEKyQjYLKTNTPq6dZtVKhEAm5226hFCp7BbVKzBRGl4VPA6VH+tbDQ0teJNPhF9U/pNU6PWizzotQ3BggCvXuI06EQkx+fS5eEMWFLZGDk+TDdJUec9PcreGNqswvYRyRtc6yXYmejxaxBHg=
x-microsoft-antispam-prvs: <SC1P152MB1645D0561A7E39642CE8E33BF53F0@SC1P152MB1645.LAMP152.PROD.OUTLOOK.COM>
x-exchange-antispam-report-test: UriScan:(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0;
RULEID:(6040375)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123558025)(20161123564025)(20161123562025)(2016111802025)(20161123555025)(20161123560025)(6042181)(6043046)(6072148);
SRVR:SC1P152MB1645; BCL:0; PCL:0; RULEID:; SRVR:SC1P152MB1645;
x-forefront-prvs: 0255DF69B9
x-forefront-antispam-report: SFV:NSPM;
SFS:(10009020)(6039001)(6009001)(7116003)(55016002)(6506006)(6916009)(6436002)(2900100001)(6306002)(81166006)(25786009)(6116002)(5660300001)(54896002)(38730400002)(53936002)(77096006)(189998001)(9686003)(3480700004)(50986999)(110136004)(54356999)(3660700001)(790700001)(3846002)(3280700002)(8676002)(66066001)(7696004)(86362001)(102836003)(2906002)(7736002)(122556002)(74316002)(8936002)(33656002)(42262002);
DIR:OUT; SFP:1101; SCL:1; SRVR:SC1P152MB1645;
H:SC1P152MB1648.LAMP152.PROD.OUTLOOK.COM; FPR:; SPF:None;
MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative;
boundary="_000_SC1P152MB1648D0F9DF4279C49D755233F53F0SC1P152MB1648LAMP_"
MIME-Version: 1.0
X-OriginatorOrg: 112bit.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2017 22:37:34.4984 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 1d040637-74d5-403e-b49a-443aa975c900
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SC1P152MB1645
X-MDID: 1490308660-oNy93bFiIpC0
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, HTML_MESSAGE, RCVD_IN_DNSWL_LOW,
RCVD_IN_SORBS_SPAM 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: Thu, 23 Mar 2017 22:55:17 +0000
Subject: [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 22:37:42 -0000
--_000_SC1P152MB1648D0F9DF4279C49D755233F53F0SC1P152MB1648LAMP_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
We notice some reorgs in Bitcoin testnet, while reorgs in testnet are commo=
n and may be part of different tests and experiments, it seems the forks ar=
e 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 h=
eights which led to me to believe that it was not a network issue. After so=
me 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 n=
odes 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 commu=
nication between nodes but not related with the network itself.
Long story short, when nodes 0.13+ receive blocks from 0.13+ nodes all is o=
k, and those blocks propagate to older nodes with no issues. But when a blo=
ck tries to be propagated from bitcoind 0.12.+ to newer ones those blocks a=
re 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, co=
mplete 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 t=
he latest version node will never receive a new block.
Probably some alternative bitcoin implementations act as bridges between th=
ese 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 compat=
ible with older ones, but a 0.13+ node may become isolated by 0.12 peers, a=
nd there is not notice for the node owner.
--_000_SC1P152MB1648D0F9DF4279C49D755233F53F0SC1P152MB1648LAMP_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<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.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=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">
<div class=3D"WordSection1">
<p class=3D"MsoNormal" style=3D"margin-left:.5in">We notice some reorgs in =
Bitcoin testnet, while reorgs in testnet are common and may be part of diff=
erent 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 p=
roblem was related to network issues but some Bitcoin explorers were follow=
ing one chain while others follow the other one. Nonetheless, well es=
tablished explorers like blocktrail.com or
blockr.io were following different chains at different heights which led t=
o me to believe that it was not a network issue. After some time, a reorg o=
ccurs and it all comes to normal state as a single chain.<o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"margin-left:.5in">We started investigating =
more and we identified that the fork occurs with nodes 0.12; in some situat=
ions, 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=3D"MsoNormal" style=3D"margin-left:.5in">Long story short, when no=
des 0.13+ receive blocks from 0.13+ nodes all is ok, and those bloc=
ks propagate to older nodes with no issues. But when a block tries to be pr=
opagated from bitcoind 0.12.+ to newer ones
those blocks are NOT being propagated to the peers with newer versions whi=
le these newer blocks are being propagated to peers with older versions wit=
h no issues.<o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"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=3D"MsoNormal" style=3D"margin-left:.5in">The issue is simple to re=
plicate, first, get latest version of bitcoind, complete the IBD after is a=
t current height, then force it to use exclusively one or more peers of ver=
sions 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=3D"MsoNormal" style=3D"margin-left:.5in">Probably some alternative=
bitcoin implementations act as bridges between these two versions and faci=
litate the chain reorgs.<o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"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=3D"MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>
--_000_SC1P152MB1648D0F9DF4279C49D755233F53F0SC1P152MB1648LAMP_--
|
