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