Chain Reorganisation

Adopting a new longest chain

Diagram showing a chain reorganisation across nodes on the network.
Recent Chain Reorganisations:
Height Length Date
829,613109 February 2024
827,853128 January 2024
819,343101 December 2023
818,038123 November 2023
815,202104 November 2023
813,210121 October 2023
803,389116 August 2023
800,786129 July 2023
792,379101 June 2023
789,147110 May 2023

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.

*Technically it's the chain with the most amount of work, but the most number of blocks is usually the same thing.

It is strictly necessary that the longest chain is always considered the valid one.
Satoshi Nakamoto, Cryptography Mailing List (Bitcoin P2P e-cash paper)


When does a chain reorganisation take place?

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

Diagram showing two blocks being mined at the same time on the Bitcoin network.
Although uncommon, it's perfectly normal for two blocks to get 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 temporary disagreement about which of these blocks was actually "first" and belongs at the top of everyone's blockchain.

Diagram showing a temporary fork in the blockchain due to two blocks being mined at the same time.
Nodes will temporarily disagree 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's 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 they will perform a chain reorganisation to adopt it.

Diagram showing a temporary fork being resolved when the next block is mined.
Blocks in the old shorter chain are deactivated, and blocks in the new longer chain are activated.

So thanks to chain reorganisations, each node eventually agrees on the same version of the blockchain as everyone else.

Stale Blocks

What happens to the transactions in the old longest chain?

stale – impaired in vigor or effectiveness

If a block is deactivated due to a chain reorganisation ("stale block"), the transactions inside it are no longer part of the blockchain.

Diagram showing a stale block after a chain reorganisation.
A stale block is a block that is no longer part of the longest chain.

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

Diagram showing how the outputs from a transaction in a stale block cannot be spent.
The outputs from transactions in a stale block cannot be spent; it's like the transaction never happened.

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

Diagram showing how competing blocks during a chain reorganisation usually contain similar transactions.
Your transaction is most likely included in the "competing" block after a chain reorganisation.

However, if there are transactions in the stale 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.

Diagram showing a transaction from a stale block being recycled back in to the mempool.
Transactions from stale blocks will be recycled back in to the memory pool if they're not in the competing block.

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

It's worth waiting for a transaction to make it 2+ blocks 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.

A "stale block" is sometimes referred to as an "orphan block", but "stale block" is the more accurate term. An orphan block is when your node receives a block before receiving the parent block that it builds upon, and stale blocks aren't orphans because they have parents.


Here we can see an example of an actual chain reorganisation that took place in the blockchain at block height 578,141.

Diagram showing an actual example of chain reorganisation and transactions from the stale block being re-mined in a later block.
Most of the transactions in the stale block were in the competing block, but some transactions were re-mined in to later blocks.


How big can chain reorganisations be?

A chain reorganisation can be any number of blocks in length.

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 many blocks will be replaced.

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.


How often do chain reorganisations happen?

Not very often. For your node to experience an honest chain reorganisation, the 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 has been running continuously since 17 December 2016):


How can you find chain reorganisations?

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

For example:

    "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"
Diagram showing the difference between valid-fork, valid-headers, and headers-only.

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.

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 continuously for a few weeks or months. When your node downloads the blockchain it will download the blocks in the current longest chain only (and not blocks from any branches or old chain reorganisations). Your node needs to experience chain reorganisations as they happen for them to show up in bitcoin-cli getchaintips.


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.

So basically, if your transaction gets mined in to a block, there's still a chance that it could get thrown back in to the mempool due to a chain reorganisation. However, these natural reorgs typically only happen to the top block on the chain, so you should wait for your transaction to make it 2 blocks deep to help avoid this scenario.