+Return-Path: <achow101-lists@achow101.com>

+Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org

+ [172.17.192.35])

+ by mail.linuxfoundation.org (Postfix) with ESMTPS id 7CF2F259

+ for <bitcoin-dev@lists.linuxfoundation.org>;

+ 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 <bitcoin-dev@lists.linuxfoundation.org>;

+ Thu, 23 Mar 2017 23:14:29 +0000 (UTC)

+Received: by mail-qt0-f176.google.com with SMTP id n21so188897481qta.1

+ for <bitcoin-dev@lists.linuxfoundation.org>;

+ 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 <jg@112bit.com>,

+ Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>

+References: <SC1P152MB1648D0F9DF4279C49D755233F53F0@SC1P152MB1648.LAMP152.PROD.OUTLOOK.COM>

+From: Andrew Chow <achow101-lists@achow101.com>

+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: <SC1P152MB1648D0F9DF4279C49D755233F53F0@SC1P152MB1648.LAMP152.PROD.OUTLOOK.COM>

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

+

+<html>

+ <head>

+ <meta content="text/html; charset=windows-1252"

+ http-equiv="Content-Type">

+ </head>

+ <body bgcolor="#FFFFFF" text="#000000">

+ <p>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.<br>

+ </p>

+ <br>

+ <div class="moz-cite-prefix">On 3/23/2017 6:37 PM, Juan Garavaglia

+ via bitcoin-dev wrote:<br>

+ </div>

+ <blockquote

+cite="mid:SC1P152MB1648D0F9DF4279C49D755233F53F0@SC1P152MB1648.LAMP152.PROD.OUTLOOK.COM"

+ type="cite">

+ <meta http-equiv="Content-Type" content="text/html;

+ charset=windows-1252">

+ <meta name="Generator" content="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.MsoNormal, li.MsoNormal, div.MsoNormal

+ {margin-top:0in;

+ margin-right:0in;

+ margin-bottom:8.0pt;

+ margin-left:0in;

+ line-height:106%;

+ font-size:11.0pt;

+ font-family:"Calibri",sans-serif;}

+a:link, span.MsoHyperlink

+ {mso-style-priority:99;

+ color:#0563C1;

+ text-decoration:underline;}

+a:visited, span.MsoHyperlinkFollowed

+ {mso-style-priority:99;

+ color:#954F72;

+ text-decoration:underline;}

+span.EmailStyle17

+ {mso-style-type:personal-compose;

+ font-family:"Calibri",sans-serif;

+ color:windowtext;}

+.MsoChpDefault

+ {mso-style-type:export-only;

+ font-family:"Calibri",sans-serif;}

+@page WordSection1

+ {size:8.5in 11.0in;

+ margin:1.0in 1.0in 1.0in 1.0in;}

+div.WordSection1

+ {page:WordSection1;}

+--></style><!--[if gte mso 9]><xml>

+<o:shapedefaults v:ext="edit" spidmax="1026" />

+</xml><![endif]--><!--[if gte mso 9]><xml>

+<o:shapelayout v:ext="edit">

+<o:idmap v:ext="edit" data="1" />

+</o:shapelayout></xml><![endif]-->

+ <div class="WordSection1">

+ <p class="MsoNormal" style="margin-left:.5in">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.<o:p></o:p></p>

+ <p class="MsoNormal" style="margin-left:.5in">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.<o:p></o:p></p>

+ <p class="MsoNormal" style="margin-left:.5in">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.<o:p></o:p></p>

+ <p class="MsoNormal" style="margin-left:.5in">My conclusion is

+ that we have a backward compatibility issue between 0.13.X+

+ and older versions.<o:p></o:p></p>

+ <p class="MsoNormal" style="margin-left:.5in">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.<o:p></o:p></p>

+ <p class="MsoNormal" style="margin-left:.5in">Probably some

+ alternative bitcoin implementations act as bridges between

+ these two versions and facilitate the chain reorgs.<o:p></o:p></p>

+ <p class="MsoNormal" style="margin-left:.5in">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.<o:p></o:p></p>

+ <p class="MsoNormal"><o:p>�</o:p></p>

+ </div>

+ <br>

+ <fieldset class="mimeAttachmentHeader"></fieldset>

+ <br>

+ <pre wrap="">_______________________________________________

+bitcoin-dev mailing list

+<a class="moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>

+<a class="moz-txt-link-freetext" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a>

+</pre>

+ </blockquote>

+ <br>

+ </body>

+</html>

+

+--------------D2C1106ADBA4B982BB3A2F48--

+