Chain Reorganisation (Reorg) - Blockchain Guide
  • Hash256
  • Hash160
  • Reverse Bytes
  • Hexadecimal
Youtube

Chain Reorganisation Deactivating and activating blocks to adopt the new longest chain.

A chain reorganisation (or “reorg”) takes place when your node receives blocks that are part of a new longest chain. Your node will deactivate blocks in its old longest chain in favour of the blocks that build the new longest chain.

This process allows individual nodes across the network to agree on the same version of the blockchain, because the globally accepted view of the blockchain will always be the one with the longest chain of blocks.

When does a chain reorganisation take place?

A chain reorganisation most commonly takes place after two blocks have been mined at the same time.

Due to the propagation speed of blocks across the network, some nodes will receive the one block first, and some nodes will receive the other block first. Therefore there will be a disagreement about which of these blocks was actually “first” and belongs at the top of everyone’s blockchain.

Nodes have differing opinions on what the blockchain looks like.

So how can we resolve this dispute and make sure everyone agrees upon the same version of the blockchain?

Well, it can be resolved when the next block is mined. The next block to be mined will build on top of one of these blocks, creating a new longest chain. When nodes receive this newest block, they will see that it creates a new longest chain, and will each perform a chain reorganisation to adopt it.

Blocks in the old shorter chain are decactivated and blocks in the new longer chain are activated.

As a result, thanks to chain reorganisations each node has been able to independently agree on the same version of the blockchain as everyone else.

What happens to the transactions in the old longest chain?

Transactions inside blocks that are deactivated due to a chain reorganisation (also known as an “orphan blocks”) are no longer part of the transaction history of the blockchain.

Only transactions in the longest chain are part of the valid history of transactions.

So if you tried to spend the bitcoins inside an orphan block, nodes would reject your transaction because you are trying to spend bitcoins that do not exist in the valid chain.

It’s as if the transaction in the orphan block never happened.

Practically speaking though, if two blocks are mined at the same time, they’re probably going to include the same transactions in them, so a reorg isn’t usually going to cause anyone a problem.

Your transaction is most likely included in the “competing” block after a chain reorganisation.

However, if there are transactions in the orphan block that are not in the competing block, they will get sent back in to your node’s memory pool and propagated around the network again for the chance to be mined in to a future block.

But this is not a guarantee, and if a transaction is not exist in the active chain, it may as well have never happened.

Tip: It may be worth your while to wait for a transaction to make it more than one block deep in to the blockchain before considering it as final. There is always the chance that it will get reorg’d out and you will have to wait/hope for it to be re-mined back in to the longest chain.

Orphan Block Visual Example

Here we can see a reorganisation that took place in the blockchain at the block height of 578141, with some of the transactions from the orphan block being re-mined back in to the chain.

Blocks 578141 as seen in a Bitcoin Neo4j graph database.

FAQ.

How big can chain reorganisations be?

A chain reorganisation can be any number of blocks.

If your node receives a new chain of blocks that’s longer than your current active chain, your node will do a chain reorganisation to adopt the new chain, no matter how long it is.

This is why it’s possible for a miner with a majority of hashing power to replace blocks and transactions in your current longest chain via a 51% Attack. The longest chain always wins.

However, “natural” chain reorganisations (ones that take place due to two blocks being mined at the same time) rarely involve more than the top block in your chain.

Here are most recent chain reorganisations my node has experienced:

Height Length Date
578141 1 28 May 2019
551355 1 24 November 2018
540801 1 10 September 2018
535510 1 06 August 2018
533547 1 25 July 2018
525890 1 04 June 2018
508717 1 11 February 2018
502052 1 01 January 2018
499002 1 13 December 2017
497871 1 06 December 2017

How often do chain reorganisations happen?

Not very often. For your node to experience an honest chain reorganisation, they following needs to take place:

  1. Two blocks are mined at the same time.
  2. Your node receives one of the blocks first, but the other block ends up being mined on top of and becomes the new longest chain.

I don’t know what the mathematical probability of this is, so here’s the frequency of chain reorganisations based on the data from my bitcoin node (which hash been running continously since 17 December 2016):

  • Actual Reorganisations: 31 (1 every 5,281 blocks / 35.1 days)
  • Avoided Reorganisations: 82 (1 every 1,996 blocks / 13.3 days)

Where can you find chain reorganisations?

You can see the chain reorganisations your node has observed with the bitcoin-cli getchaintips command:

[
  {
    "height": 589919,
    "hash": "000000000000000000149b18e74316248d106e42ca410f509305ae58ccda6b13",
    "branchlen": 0,
    "status": "active"
  },
  {
    "height": 578141,
    "hash": "0000000000000000001253a5f37d3763dbe928d21f7d72a708f05268c044179c",
    "branchlen": 1,
    "status": "valid-fork"
  },
  {
    "height": 575695,
    "hash": "0000000000000000002409ed07fdbb1d0359a0c516014115c5451aea724baec8",
    "branchlen": 1,
    "status": "valid-headers"
  },
  ...
  • The brachlen tells you how many blocks were in the competing chain of blocks.
  • The status field indicates the following:
    • active - This is our current active chain (the longest chain).
    • valid-fork - Our node performed a chain reorganisation. We downloaded and validated these blocks and had them as part of our active chain, but we later deactivated them after receiving a new longer chain of blocks.
    • valid-headers - Our node observed a possible chain reorganisation. We downloaded these blocks, but did not validate them as our active chain was equivalent and became longer.
    • headers-only - Our node observed a possible chain reorganisation. We received the block headers for a competing chain but did not download the full blocks.
    • invalid - A branch that contains invalid blocks.

Therefore the branches with the status of valid-fork are the ones with blocks that we originally considered part of our active blockchain, but we later deactivated them after receiving a new longer chain of blocks.

Furthemore the branches with the status of valid-headers are competing chains that we received after already having an equivalent active chain. These could have resulted in a reorganisation, but our chain continued as the longest chain so no reorganisation took place.

It’s unlikely that you will see any chain reorganisations if you have not been running your node for a few weeks or months continuously. When your node downloads the blockchain it will only download the blocks in the longest chain (and not blocks from any branches and old chain reorganisations). Your node needs to experience the chain reorganisations as they take place for them to show up in bitcoin-cli getchaintips.

Summary

Chain reorganisations are a perfectly normal part of a Bitcoin node’s function. Adopting the longest known chain allows nodes across a network to agree on the same blockchain, and chain reorganisations are just a part of this process.

Transactions inside blocks that are deactivated due to a chain reorganisation will become invalid, but they will be recycled in to the memory pool for the opportunity to be mined in to a block on the new longest chain.

By Greg Walker,

Last Updated: 25 Oct 2019
  • 25 Oct 2019: 51% attack (fourth draft - edits, links)
  • 21 Oct 2019: chain reorganisation (fourth draft - edits and neo4j example)
  • 21 Oct 2019: chain reorganisation (linking to the blockchain and not blocks the explorer)
  • 21 Oct 2019: chain reorganisation (third draft)
  • 21 Oct 2019: edits
  • 21 Oct 2019: chain reorganisation (second draft - images, live data)
  • 18 Oct 2019: chain reorganisation (first draft)

Hey there, it's Greg.

I'll let you know about cool website updates, or if something seriously interesting happens in bitcoin.


Don't worry, it doesn't happen very often.