* [bitcoin-dev] Issolated Bitcoin Nodes
@ 2017-03-23 22:37 Juan Garavaglia
2017-03-23 23:01 ` Matt Corallo
` (2 more replies)
0 siblings, 3 replies; 7+ messages in thread
From: Juan Garavaglia @ 2017-03-23 22:37 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 2117 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 4307 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] Issolated Bitcoin Nodes
2017-03-23 22:37 [bitcoin-dev] Issolated Bitcoin Nodes Juan Garavaglia
@ 2017-03-23 23:01 ` Matt Corallo
2017-03-23 23:14 ` Andrew Chow
2017-03-24 0:20 ` Pieter Wuille
2 siblings, 0 replies; 7+ messages in thread
From: Matt Corallo @ 2017-03-23 23:01 UTC (permalink / raw)
To: Juan Garavaglia, Bitcoin Protocol Discussion,
Juan Garavaglia via bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 2462 bytes --]
I haven't investigated, but you may be seeing segwit-invalid blocks...0.13.0+ nodes will enforce segwit as it activated some time ago on testnet, 0.12.X nodes will not.
On March 23, 2017 3:37:34 PM PDT, Juan Garavaglia via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> 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.
[-- Attachment #2: Type: text/html, Size: 4662 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] Issolated Bitcoin Nodes
2017-03-23 22:37 [bitcoin-dev] Issolated Bitcoin Nodes Juan Garavaglia
2017-03-23 23:01 ` Matt Corallo
@ 2017-03-23 23:14 ` Andrew Chow
2017-03-24 3:38 ` Andrew Chow
2017-03-24 0:20 ` Pieter Wuille
2 siblings, 1 reply; 7+ messages in thread
From: Andrew Chow @ 2017-03-23 23:14 UTC (permalink / raw)
To: Juan Garavaglia, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 3062 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 5965 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] Issolated Bitcoin Nodes
2017-03-23 22:37 [bitcoin-dev] Issolated Bitcoin Nodes Juan Garavaglia
2017-03-23 23:01 ` Matt Corallo
2017-03-23 23:14 ` Andrew Chow
@ 2017-03-24 0:20 ` Pieter Wuille
2017-03-24 0:31 ` James Hilliard
2017-03-24 1:58 ` Eric Voskuil
2 siblings, 2 replies; 7+ messages in thread
From: Pieter Wuille @ 2017-03-24 0:20 UTC (permalink / raw)
To: Juan Garavaglia, Bitcoin Protocol Discussion
On Thu, Mar 23, 2017 at 3:37 PM, Juan Garavaglia via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> 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.
Hello Juan,
this is expected behaviour. Nodes with segwit active only download
blocks from other segwit peers, as old peers cannot provide the
witness data they need to verify the blocks.
--
Pieter
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] Issolated Bitcoin Nodes
2017-03-24 0:20 ` Pieter Wuille
@ 2017-03-24 0:31 ` James Hilliard
2017-03-24 1:58 ` Eric Voskuil
1 sibling, 0 replies; 7+ messages in thread
From: James Hilliard @ 2017-03-24 0:31 UTC (permalink / raw)
To: Pieter Wuille, Bitcoin Protocol Discussion
There were bridge nodes being run on testnet at one point to prevent
forks https://github.com/jl2012/bitcoin/commit/9717d856e72baa939d4b273f0a56e6009978e11b
On Thu, Mar 23, 2017 at 7:20 PM, Pieter Wuille via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> On Thu, Mar 23, 2017 at 3:37 PM, Juan Garavaglia via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>> 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.
>
> Hello Juan,
>
> this is expected behaviour. Nodes with segwit active only download
> blocks from other segwit peers, as old peers cannot provide the
> witness data they need to verify the blocks.
>
> --
> Pieter
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] Issolated Bitcoin Nodes
2017-03-24 0:20 ` Pieter Wuille
2017-03-24 0:31 ` James Hilliard
@ 2017-03-24 1:58 ` Eric Voskuil
1 sibling, 0 replies; 7+ messages in thread
From: Eric Voskuil @ 2017-03-24 1:58 UTC (permalink / raw)
To: Pieter Wuille, Bitcoin Protocol Discussion, Juan Garavaglia
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 03/23/2017 05:20 PM, Pieter Wuille via bitcoin-dev wrote:
> On Thu, Mar 23, 2017 at 3:37 PM, Juan Garavaglia via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>> 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.
>
> Hello Juan,
>
> this is expected behaviour. Nodes with segwit active only download
> blocks from other segwit peers, as old peers cannot provide the
> witness data they need to verify the blocks.
Juan's statement pertains to incompatibility, not mysterious causation.
Clearly it's a material consideration. Is it an oversight that this is
not documented as an incompatibility in any of the segwit BIPs?
I don't recall any discussion on the importance of segwit bridge
nodes. Is there a plan for bridging mainnet?
e
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBCAAGBQJY1H1AAAoJEDzYwH8LXOFOAk4H/RrJyexvyFKXfY7qC0bGCVwN
2iZ0wR0n/H0Z0qfP5nzDID0RARC3F/KFAAeLTaCIZa5uI0h3MrPbNm7hSi/m0nHJ
mTzfJf0E8g+ETzyDpWjgR25ta6n3VdKp2tnNrY3z/ojnGYBFthpRDWV09K5trX5k
qMyoPDfTP8jVIwihqx3MZLBnfiQKlEjNxCxmnuL7bh37msp6WK+elKudSrDBPiIi
ljQ+u5NyeKWY+qzEzKPShIKnm3wC4K/RiiZIUvz60x6PCHr8OZGTEiKhPLWznVuj
Q9gVtHxFzDpMZbxo4vP4nH+isQgqNa9gQ2E5783OC0/lpxHCoZEsgsD5lTAcp08=
=GyRS
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] Issolated Bitcoin Nodes
2017-03-23 23:14 ` Andrew Chow
@ 2017-03-24 3:38 ` Andrew Chow
0 siblings, 0 replies; 7+ messages in thread
From: Andrew Chow @ 2017-03-24 3:38 UTC (permalink / raw)
To: Juan Garavaglia, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 4816 bytes --]
A correction to my previous email (because people are quoting me on
r/btc and what I wrote was wrong)
This statement is incorrect:
> 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.
Miners using 0.13.0+ will produce blocks that propagate well. This is
because 0.12.x- nodes will accept those blocks, and so will 0.13.0+.
Furthermore Core 0.13.0+ will use its outbound connections to connect to
segwit enabled peers so that it will be relaying segwit blocks to
someone. However Bitcoin Core 0.13.0+ will not request blocks from peers
that are not segwit enabled (because with segwit, they will be receiving
blocks without witnesses which are invalid to a segwit node), so they
will not receive blocks mined by a 0.12.x- node. This means that 0.12.x-
mined blocks propagate poorly, even though are valid. Because of the
poor propagation, a 0.13.0+ miner can find a block at the same height
which is more likely to get built upon. However, the poorly propagated
block can still reach other 0.12.x- miners who can build upon it due to
the low difficulty and difficulty resets, thus causing multiple chains
to exist, particularly among pockets of 0.12.x- nodes. The reorgs happen
when either the 0.12.x- nodes hear of the segwit blockchain that is
presumably longer because it has the majority hashrate, or when people
run bridges which allow 0.12.x- nodes relay blocks to 0.13.0+ nodes.
On 3/23/2017 7:14 PM, Andrew Chow wrote:
>
> 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
>
[-- Attachment #2: Type: text/html, Size: 8313 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2017-03-24 3:38 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-23 22:37 [bitcoin-dev] Issolated Bitcoin Nodes Juan Garavaglia
2017-03-23 23:01 ` Matt Corallo
2017-03-23 23:14 ` Andrew Chow
2017-03-24 3:38 ` Andrew Chow
2017-03-24 0:20 ` Pieter Wuille
2017-03-24 0:31 ` James Hilliard
2017-03-24 1:58 ` Eric Voskuil
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox