From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 1A8C9B1E for ; 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 ; 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: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----MHX2UZ32ZCJXBF5CXXRABMR097QE7L" Content-Transfer-Encoding: 7bit To: Juan Garavaglia , Bitcoin Protocol Discussion , Juan Garavaglia via bitcoin-dev From: Matt Corallo 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 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

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

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

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

My conclusion is that = we have a backward compatibility issue between 0=2E13=2EX+ and older versio= ns=2E

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

=

Probably some alternat= ive bitcoin implementations act as bridges between these two versions and f= acilitate the chain reorgs=2E

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

 

------MHX2UZ32ZCJXBF5CXXRABMR097QE7L--