📅 Original date posted:2017-03-24
📝 Original message: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 at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170323/74d42235/attachment-0001.html>;
Andrew Chow [ARCHIVE] /
npub1fg…xak44
2023-06-07 17:57:43
in reply to nevent1q…zvzn
Author Public Key
npub1fgnnmg7f4wzup9hct8nv5pnd9l07wcjqdjku9ax432n4g69v4rgq7xak44Published at
2023-06-07 17:57:43Event JSON
{
"id": "354201a55a0f4490dc9a97325912cbb9330a93bc5f8a48b480983f50841b24ef",
"pubkey": "4a273da3c9ab85c096f859e6ca066d2fdfe762406cadc2f4d58aa75468aca8d0",
"created_at": 1686160663,
"kind": 1,
"tags": [
[
"e",
"a77672c0bec72cf6c744f58f911e3b4b495fa3bf41bc9de349fa803c65967858",
"",
"root"
],
[
"e",
"c6e880fbadb973dc7fbc529fb66e933c83fdd194d74ac765f41da9d92196ebb7",
"",
"reply"
],
[
"p",
"4a273da3c9ab85c096f859e6ca066d2fdfe762406cadc2f4d58aa75468aca8d0"
]
],
"content": "📅 Original date posted:2017-03-24\n📝 Original message:A correction to my previous email (because people are quoting me on\nr/btc and what I wrote was wrong)\n\nThis statement is incorrect:\n\n\u003e Given that Testnet has a smaller number of nodes and less difficulty,\nthis could result in some miners using 0.13.0+ mining blocks which do\nnot propagate well and thus causing multiple chain splits and reorgs as\nother miners find blocks for the same height before receiving a block\nfor that height.\n\nMiners using 0.13.0+ will produce blocks that propagate well. This is\nbecause 0.12.x- nodes will accept those blocks, and so will 0.13.0+.\nFurthermore Core 0.13.0+ will use its outbound connections to connect to\nsegwit enabled peers so that it will be relaying segwit blocks to\nsomeone. However Bitcoin Core 0.13.0+ will not request blocks from peers\nthat are not segwit enabled (because with segwit, they will be receiving\nblocks without witnesses which are invalid to a segwit node), so they\nwill not receive blocks mined by a 0.12.x- node. This means that 0.12.x-\nmined blocks propagate poorly, even though are valid. Because of the\npoor propagation, a 0.13.0+ miner can find a block at the same height\nwhich is more likely to get built upon. However, the poorly propagated\nblock can still reach other 0.12.x- miners who can build upon it due to\nthe low difficulty and difficulty resets, thus causing multiple chains\nto exist, particularly among pockets of 0.12.x- nodes. The reorgs happen\nwhen either the 0.12.x- nodes hear of the segwit blockchain that is\npresumably longer because it has the majority hashrate, or when people\nrun bridges which allow 0.12.x- nodes relay blocks to 0.13.0+ nodes.\n\nOn 3/23/2017 7:14 PM, Andrew Chow wrote:\n\u003e\n\u003e The issue is due to Segwit blocks since Testnet has already activated\n\u003e Segwit. 0.12.x- nodes will receive a Segwit block with all of the\n\u003e witnesses stripped. When they relay this block to a 0.13.0+ node, the\n\u003e block will be rejected because those have Segwit functionality and\n\u003e require the witnesses to be in the block. Given that Testnet has a\n\u003e smaller number of nodes and less difficulty, this could result in some\n\u003e miners using 0.13.0+ mining blocks which do not propagate well and\n\u003e thus causing multiple chain splits and reorgs as other miners find\n\u003e blocks for the same height before receiving a block for that height.\n\u003e\n\u003e\n\u003e On 3/23/2017 6:37 PM, Juan Garavaglia via bitcoin-dev wrote:\n\u003e\u003e\n\u003e\u003e We notice some reorgs in Bitcoin testnet, while reorgs in testnet are\n\u003e\u003e common and may be part of different tests and experiments, it seems\n\u003e\u003e the forks are not created by a single user and multiple blocks were\n\u003e\u003e mined by different users in each chain. My first impression was that\n\u003e\u003e the problem was related to network issues but some Bitcoin explorers\n\u003e\u003e were following one chain while others follow the other one. \n\u003e\u003e Nonetheless, well established explorers like blocktrail.com or\n\u003e\u003e blockr.io were following different chains at different heights which\n\u003e\u003e led to me to believe that it was not a network issue. After some\n\u003e\u003e time, a reorg occurs and it all comes to normal state as a single chain.\n\u003e\u003e\n\u003e\u003e We started investigating more and we identified that the fork occurs\n\u003e\u003e with nodes 0.12; in some situations, nodes 0.12 has longer/different\n\u003e\u003e chains. The blocks in both chains are valid so something must be\n\u003e\u003e occurring in the communication between nodes but not related with the\n\u003e\u003e network itself.\n\u003e\u003e\n\u003e\u003e Long story short, when nodes 0.13+ receive blocks from 0.13+ nodes\n\u003e\u003e all is ok, and those blocks propagate to older nodes with no issues.\n\u003e\u003e But when a block tries to be propagated from bitcoind 0.12.+ to newer\n\u003e\u003e ones those blocks are NOT being propagated to the peers with newer\n\u003e\u003e versions while these newer blocks are being propagated to peers with\n\u003e\u003e older versions with no issues.\n\u003e\u003e\n\u003e\u003e My conclusion is that we have a backward compatibility issue between\n\u003e\u003e 0.13.X+ and older versions.\n\u003e\u003e\n\u003e\u003e The issue is simple to replicate, first, get latest version of\n\u003e\u003e bitcoind, complete the IBD after is at current height, then force it\n\u003e\u003e to use exclusively one or more peers of versions 0.12.X and older,\n\u003e\u003e and you will notice that the latest version node will never receive a\n\u003e\u003e new block.\n\u003e\u003e\n\u003e\u003e Probably some alternative bitcoin implementations act as bridges\n\u003e\u003e between these two versions and facilitate the chain reorgs.\n\u003e\u003e\n\u003e\u003e I have not yet found any way where/how it can be used in a malicious\n\u003e\u003e way or be exploited by a miner but in theory Bitcoin 0.13.X+ should\n\u003e\u003e remain compatible with older ones, but a 0.13+ node may become\n\u003e\u003e isolated by 0.12 peers, and there is not notice for the node owner.\n\u003e\u003e\n\u003e\u003e \n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170323/74d42235/attachment-0001.html\u003e",
"sig": "332209dcc1522b001dd4d641b1fe035d819fcce14611676543be3ee3609256ccdcaf9515d61cd00f2291cfe5707882e7a78d3412ae0ba5c1634db1d863d5396a"
}