Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 7CF2F259 for ; Thu, 23 Mar 2017 23:14:30 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qt0-f176.google.com (mail-qt0-f176.google.com [209.85.216.176]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C0BB71E8 for ; Thu, 23 Mar 2017 23:14:29 +0000 (UTC) Received: by mail-qt0-f176.google.com with SMTP id n21so188897481qta.1 for ; Thu, 23 Mar 2017 16:14:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=achow101-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=YiWT7D99XFsHNcA4yUHJA1jMndmhLsjS7yBriv2iH14=; b=Y15b/c+VqHFDFbRdlherFnAUiq1OBzy4MDOw+OQgNLvYAFUGGgQamMxgU4M3bCN9ey AC29xrj5gB6gT4oJUAaHJT5K+qGfI6daOp4AGG1xshPVSKhhfd9ydmF/1627yxFKNskJ WfpaKXE5KCFWcLftNiqZ5FLZPjSOE1opmXJTAol3OMTuHZZLBh0cCspzz+SCfNMbUgHR XG59OERwxlycNH3OD5Jn2b7PuTpIRp1/fvjgnbPObhoH/949ImEAVUpsKScfyeXaswCv EPWaLzNLRVn/kAnySeDbLz6f5auRvZpoZmZfm98Q4OoS8Qa9gYHGL64a8/or9lCbyFn6 DWRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=YiWT7D99XFsHNcA4yUHJA1jMndmhLsjS7yBriv2iH14=; b=Mqhq0ypkKCX7YGqnTI4y+V3EdWdmQQ4I1w/qb4fG1Uv/dDPI20zwqoUu8UiG+anvp5 9V5io9D/e1raEvpDZ9Din2KpQ1vcz54kwFHuM8ZkiDSA6J7dFFbsSH5TgcUX1lgmaSki 5ymytzNAr8mWGb/1DQCmMgwkbDfvPYUEkjBCiXJu3nJrYohuo5wi4ZZAeoBKyVZNholN 98C4oReDSSiKEk44FcfbnA2QHMYogAT9v+GVLr5I8RE5AacFlTrHW1t3b6fRZkLhCjo0 hubblG2teL0LocDYEfniTy6bjvwGbyvmWiJDfGeZVp7snBtzwS5PIXVRMb7mazcikhma 9Egg== X-Gm-Message-State: AFeK/H3SgqmCh2mLm9DPzwAld3gFPNgVQ/vM59KfR5SJrSbU7u6O5WilIavUbQan2ckntw== X-Received: by 10.237.43.68 with SMTP id p62mr4901408qtd.207.1490310868814; Thu, 23 Mar 2017 16:14:28 -0700 (PDT) Received: from ?IPv6:2601:45:8200:e070:cdd4:fd6a:c2b2:a135? ([2601:45:8200:e070:cdd4:fd6a:c2b2:a135]) by smtp.gmail.com with ESMTPSA id y3sm328954qke.59.2017.03.23.16.14.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Mar 2017 16:14:28 -0700 (PDT) To: Juan Garavaglia , Bitcoin Protocol Discussion References: From: Andrew Chow Message-ID: <3fd9846c-6c57-9b57-0b6e-e5958e644e1d@achow101.com> Date: Thu, 23 Mar 2017 19:14:28 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D2C1106ADBA4B982BB3A2F48" X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no 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:14:30 -0000 This is a multi-part message in MIME format. --------------D2C1106ADBA4B982BB3A2F48 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit The issue is due to Segwit blocks since Testnet has already activated Segwit. 0.12.x- nodes will receive a Segwit block with all of the witnesses stripped. When they relay this block to a 0.13.0+ node, the block will be rejected because those have Segwit functionality and require the witnesses to be in the block. Given that Testnet has a smaller number of nodes and less difficulty, this could result in some miners using 0.13.0+ mining blocks which do not propagate well and thus causing multiple chain splits and reorgs as other miners find blocks for the same height before receiving a block for that height. On 3/23/2017 6:37 PM, 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. 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 heights which > led to me to believe that it was not a network issue. After some 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 nodes 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 communication between nodes but not related with the > network itself. > > Long story short, when nodes 0.13+ receive blocks from 0.13+ nodes all > is ok, and those blocks propagate to older nodes with no issues. But > when a block tries to be propagated from bitcoind 0.12.+ to newer ones > 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. > > 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, complete 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 the latest version node will never receive a new > block. > > Probably some alternative bitcoin implementations act as bridges > between these 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 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. > > > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --------------D2C1106ADBA4B982BB3A2F48 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

The issue is due to Segwit blocks since Testnet has already activated Segwit. 0.12.x- nodes will receive a Segwit block with all of the witnesses stripped. When they relay this block to a 0.13.0+ node, the block will be rejected because those have Segwit functionality and require the witnesses to be in the block. Given that Testnet has a smaller number of nodes and less difficulty, this could result in some miners using 0.13.0+ mining blocks which do not propagate well and thus causing multiple chain splits and reorgs as other miners find blocks for the same height before receiving a block for that height.


On 3/23/2017 6:37 PM, 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.  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 heights which led to me to believe that it was not a network issue. After some 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 nodes 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 communication between nodes but not related with the network itself.

Long story short, when nodes 0.13+ receive blocks from 0.13+ nodes all is ok, and those blocks propagate to older nodes with no issues. But when a block tries to be propagated from bitcoind 0.12.+ to newer ones 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.

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, complete 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 the latest version node will never receive a new block.

Probably some alternative bitcoin implementations act as bridges between these 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 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.

 



_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--------------D2C1106ADBA4B982BB3A2F48--