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&#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--