After the recent two chain reorgs taking place in Bitcoin Cash SV, I am finding a number of developers stating that large blocks are the reason for the reorgs:

"Almost each time someone is trying to produce a very large block on the $BSV chain, there’s a reorg." Nikita Zhavoronkov, lead developer at Blockchair

“This is basically exactly the problem the BU gigabock testnet identified. At sizes > 100mb the mempools were so out of sync that blocks were basically transmitted as full blocks.

"BSV had ONE 128mb block and it caused a six block reorg. On the BU testnet sustained 128mb blocks caused a total breakdown of the chain where there were so many reorgs that every node had a different view of the state of the blockchain. And would you believe barely a day goes by where the BSV supporters don’t mock me pointing this out as if it’s sooooo obvious how wrong I was.” Chris Pacia, CEO of OpenBazaar

What is it about the nature of large blocks that makes it more likely that the blockchain will reorganise itself?


This shows the inherent flaw with the idea of increasing block sizes if the network cannot handle them propagating in a timely manner.

If the block sizes are huge and the mempools of the connected nodes are way out of sync, the full node will basically have to download almost entire block before adding to its chain and then transmitting this block to the nodes that are connected to it. This can consume a lot of time. If a miner mines a block h, they will generally try to build block h+1 on top of the block that they found. It is only after they receive block h+1 (before they mined it) will it know that they lost the 'race' for h+1. The miners will then reorganize its chain to the best height h+1 that they just received and mine on top of that.

When block sizes are huge, the miner in above example, might receive block h+1 only after he has mined h+1. So the miner will start building on top of the block he has mined, being deceived that he was the first to find the solution to the block h+1. If block sizes are huge, this can extend for multiple heights, until the miner receives say a block at height h+6 before he mined the block at that height. So the miner will now have his chain reorganized based on the blocks he has received in the past. The full nodes that are closely connected to the miners, will also have to reorganize their chain for that to happen.


This is a good explanation from Ugam Kamat as to how a bitcoin chain re-organisation plays out.

Although I do think many miss the point about what it all means...

Why is a chain re-organisation a problem? It isn’t.

Users are unaffected – If they use 0-confirmation transactions. For something that is important enough to consider the minute probability of a double-spending attack being successful, there are other methods that can be used to ensure the transaction is safe – than simply waiting for block confirmations.

Miners lose – They cannot access the reward (block subsidy and transaction fees) from a stale block.

Why did they lose? It took them too long to validate and transmit blocks to each other.

Stale blocks are an economic incentive for miners to compete to become better connected in the small-world network … or to mine smaller blocks.

Being highly connected is just another aspect of the “proof of work” required to win the block reward. The work incentivises something which is good for bitcoin – and necessary for it to work at scale.

In a more distant future - one of abundant bandwidth and vast numbers of transactions, a significant aspect of “proof of work” will be validating transactions – as the computational cost of validating transactions rises approximately linearly with transaction count.

Stale blocks and the re-organisations they cause, are an economic incentive for miners to improve. It is an integral part of the bitcoin design.

Due to the block size cap and the low numbers of transactions, it has never been seen in any significant way before – and people seem to misunderstand the risks. They can all be mitigated.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.