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>
Subject: Re: [bitcoin-dev] Issolated Bitcoin Nodes
Precedence: list

------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&#39=
;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 &lt;bitcoin-dev@lists=
=2Elinuxfoundation=2Eorg&gt; 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&nbsp; 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&nbsp; 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>&nbsp;</p>
</div>

</blockquote></div></body></html>
------MHX2UZ32ZCJXBF5CXXRABMR097QE7L--