Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id EF8C24A6 for ; Thu, 23 Mar 2017 22:37:41 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EE233106 for ; Thu, 23 Mar 2017 22:37:40 +0000 (UTC) Received: from pure.maildistiller.com (unknown [10.110.50.29]) by dispatch1-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTP id 3A5276006F for ; Thu, 23 Mar 2017 22:37:40 +0000 (UTC) X-Virus-Scanned: Proofpoint Essentials engine Received: from mx3-us3.ppe-hosted.com (unknown [10.110.49.251]) by pure.maildistiller.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 940E060053 for ; Thu, 23 Mar 2017 22:37:39 +0000 (UTC) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01lp0178.outbound.protection.outlook.com [216.32.181.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx3-us3.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 2B9926007A for ; Thu, 23 Mar 2017 22:37:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORG2631885.onmicrosoft.com; s=selector1-112bit-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PadG0is8MLXe+LAn3epjLV5sl33zBqyPWao9rxKlMzY=; b=FohODzFOPhenYIB/9zaHAn9+5aAnbeMFdADtt0L4d+RDYQZY2gg2osBQqk40H2/LySywvV3c4lAUl/jhhwU7taffBfs11aGrnuKc2P7bpLH/whqvcAx66+ssq5JETpbEEFrEs5ctItpuY3msCBR904aYZRdVg9T++nOapT2o5B4= Received: from SC1P152MB1648.LAMP152.PROD.OUTLOOK.COM (10.171.68.8) by SC1P152MB1645.LAMP152.PROD.OUTLOOK.COM (10.171.67.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.11; Thu, 23 Mar 2017 22:37:34 +0000 Received: from SC1P152MB1648.LAMP152.PROD.OUTLOOK.COM ([10.171.68.8]) by SC1P152MB1648.LAMP152.PROD.OUTLOOK.COM ([10.171.68.8]) with mapi id 15.01.0947.022; Thu, 23 Mar 2017 22:37:34 +0000 From: Juan Garavaglia To: Bitcoin Protocol Discussion Thread-Topic: Issolated Bitcoin Nodes Thread-Index: AdKkJg2YWuE1Y1o1TBGNcvF0JByzDg== Date: Thu, 23 Mar 2017 22:37:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: lists.linuxfoundation.org; dkim=none (message not signed) header.d=none; lists.linuxfoundation.org; dmarc=none action=none header.from=112bit.com; x-originating-ip: [201.252.72.209] x-ms-office365-filtering-correlation-id: 050a85b9-4d0e-457f-f253-08d4723d3376 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:SC1P152MB1645; x-microsoft-exchange-diagnostics: 1; SC1P152MB1645; 7:pBuZ96SAZLIo9Xa6nDSghKUjcC7d+qTQBa2DOMOfOB8/feMguNpHPbmzdXlkUVeJHbBlPSLdPjKHZBcvzTxjngqFYsvvpKLc7g27Z/kbXkMI7wVNxhSU+B6cZ5tW/pOatTVQ0dNIvF/bdkNBmj9mdNZUjrElHs5Xbw/MmugLZOhyj8LUuG8fM/9k0Du6+acAesTZ7K2SGbFfrysoNBd2DaxgXerdphI0UTRK/bQmLHxbDbq3ZlDqQmXwjHiS/itseRYDPvayARd6T5Si3T7zYNy85/33pfFaaKrk29FFJEVVbWK/yD1lcUaDcdGUqXdDopWlcnrT+mBGkRB221tv0g==; 20:uPOWyq429xp+rKO0AcL00Plbl86lEKyQjYLKTNTPq6dZtVKhEAm5226hFCp7BbVKzBRGl4VPA6VH+tbDQ0teJNPhF9U/pNU6PWizzotQ3BggCvXuI06EQkx+fS5eEMWFLZGDk+TDdJUec9PcreGNqswvYRyRtc6yXYmejxaxBHg= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123558025)(20161123564025)(20161123562025)(2016111802025)(20161123555025)(20161123560025)(6042181)(6043046)(6072148); SRVR:SC1P152MB1645; BCL:0; PCL:0; RULEID:; SRVR:SC1P152MB1645; x-forefront-prvs: 0255DF69B9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6039001)(6009001)(7116003)(55016002)(6506006)(6916009)(6436002)(2900100001)(6306002)(81166006)(25786009)(6116002)(5660300001)(54896002)(38730400002)(53936002)(77096006)(189998001)(9686003)(3480700004)(50986999)(110136004)(54356999)(3660700001)(790700001)(3846002)(3280700002)(8676002)(66066001)(7696004)(86362001)(102836003)(2906002)(7736002)(122556002)(74316002)(8936002)(33656002)(42262002); DIR:OUT; SFP:1101; SCL:1; SRVR:SC1P152MB1645; H:SC1P152MB1648.LAMP152.PROD.OUTLOOK.COM; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SC1P152MB1648D0F9DF4279C49D755233F53F0SC1P152MB1648LAMP_" MIME-Version: 1.0 X-OriginatorOrg: 112bit.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2017 22:37:34.4984 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 1d040637-74d5-403e-b49a-443aa975c900 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SC1P152MB1645 X-MDID: 1490308660-oNy93bFiIpC0 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, HTML_MESSAGE, RCVD_IN_DNSWL_LOW, RCVD_IN_SORBS_SPAM autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Thu, 23 Mar 2017 22:55:17 +0000 Subject: [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 22:37:42 -0000 --_000_SC1P152MB1648D0F9DF4279C49D755233F53F0SC1P152MB1648LAMP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We notice some reorgs in Bitcoin testnet, while reorgs in testnet are commo= n and may be part of different tests and experiments, it seems the forks ar= e 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 h= eights which led to me to believe that it was not a network issue. After so= me 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 n= odes 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 commu= nication between nodes but not related with the network itself. Long story short, when nodes 0.13+ receive blocks from 0.13+ nodes all is o= k, and those blocks propagate to older nodes with no issues. But when a blo= ck tries to be propagated from bitcoind 0.12.+ to newer ones those blocks a= re 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, co= mplete 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 t= he latest version node will never receive a new block. Probably some alternative bitcoin implementations act as bridges between th= ese 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 compat= ible with older ones, but a 0.13+ node may become isolated by 0.12 peers, a= nd there is not notice for the node owner. --_000_SC1P152MB1648D0F9DF4279C49D755233F53F0SC1P152MB1648LAMP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We notice some reorgs in = Bitcoin testnet, while reorgs in testnet are common and may be part of diff= erent 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 p= roblem was related to network issues but some Bitcoin explorers were follow= ing one chain while others follow the other one.  Nonetheless, well es= tablished explorers like blocktrail.com or blockr.io were following different chains at different heights which led t= o me to believe that it was not a network issue. After some time, a reorg o= ccurs 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 situat= ions, 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 no= des 0.13+ receive blocks from 0.13+ nodes all is ok, and those bloc= ks propagate to older nodes with no issues. But when a block tries to be pr= opagated from bitcoind 0.12.+ to newer ones those blocks are NOT being propagated to the peers with newer versions whi= le these newer blocks are being propagated to peers with older versions wit= h no issues.

My conclusion is that we = have a backward compatibility issue between 0.13.X+ and older versions.=

The issue is simple to re= plicate, first, get latest version of bitcoind, complete the IBD after is a= t current height, then force it to use exclusively one or more peers of ver= sions 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 faci= litate 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.

 

--_000_SC1P152MB1648D0F9DF4279C49D755233F53F0SC1P152MB1648LAMP_--