A blockchain reorganization, often called a reorg, occurs when a node changes the branch it treats as the accepted chain. Recent blocks on the previous branch leave that accepted history, and blocks from another branch take their place.
For someone reading a wallet, payment report, or data export, the practical problem is reconciliation. A transaction previously reported inside a block may appear in a different block, become unconfirmed, or conflict with a transaction on the newly accepted branch.
This guide uses Bitcoin to show how to reconstruct that change. It focuses on preserving transaction identity and correcting a ledger, rather than choosing a universal number of confirmations or predicting an attack.
What changes during a blockchain reorganization?
Two valid blocks can temporarily compete at the same height. In Bitcoin, nodes follow the valid chain with the greatest accumulated proof of work. “Longest chain” is a common shorthand, but counting blocks alone is not the full rule.
The Bitcoin developer guide’s block-forking section explains this branch selection and why block height is not a unique identifier. Keep the block hash as well as its height when recording inclusion.
A reorg does not edit the bytes inside an old block. It changes which branch supplies the accepted transaction history. The old block may still be known to an observer, but its previous position in the active chain no longer establishes current inclusion.
This is why a screenshot from earlier in the day and a live explorer can both accurately describe what their observer saw at different times. To resolve the difference, compare the branch and observation time before accusing either source of inventing a transaction.
Worked example: remove two blocks and add three
Assume a fictional Bitcoin-style chain shares a common block C at height 1,000. The node first accepts branch A, with blocks A1 at 1,001 and A2 at 1,002.
It later learns of branch B: B1 at 1,001, B2 at 1,002, and B3 at 1,003. For this example, all blocks are valid and have equal per-block work. Branch B therefore has more accumulated work beyond C.
- The common ancestor remains C at height 1,000.
- The node disconnects A2 and A1 from its active history.
- It connects B1, B2, and B3 in order.
- The new active tip is B3, at height 1,003.
The displaced portion of the old branch is two blocks deep. Three replacement blocks were connected. Calling this a “five-block reorg” by adding the removed and added counts would confuse two different measurements.
A1 and B1 have the same height but different hashes. A spreadsheet keyed only by height could overwrite one with the other without preserving evidence of the change. A better record retains each block’s identity and marks which observation treated it as active.
Do not generalize the example’s simple block-count comparison across difficulty boundaries or other networks. Equal work per block is an explicit simplifying assumption here.
Follow each transaction through the change
Suppose payment P appears in A1 and also in B2. It has not become two payments. Its block inclusion has changed. Update its active block reference while preserving the same transaction identity.
Payment Q appears only in A2. After the switch, it is no longer included in the active history. It may remain eligible for later inclusion if valid under the new state and accepted by the relevant node’s policy. It is not automatically destroyed.
A third transaction could instead conflict with something on branch B. That is a different outcome from simply waiting for another block. A reconciliation should distinguish re-included, pending or otherwise unconfirmed, and conflicted observations.
Bitcoin Core’s listsinceblock reference illustrates the reporting nuance: a wallet’s removed array can contain a transaction subsequently re-added to the active chain. A “removed” record therefore needs to be interpreted alongside current status, not as a permanent deletion verdict.
Reconcile a receipt ledger without counting twice
Consider a simple internal ledger of cumulative incoming receipts, with no outgoing payments in this example. Before the branching point, it records 10.00 BTC of receipts.
- Old branch: P contributes 0.30 BTC and Q contributes 0.20 BTC. The observed total becomes 10.50 BTC.
- New branch: P is included again, Q is absent, and a different payment R contributes 0.10 BTC.
- The newly accepted receipt total is 10.00 + 0.30 + 0.10 = 10.40 BTC.
If a system merely appends the new observations to the old ones, it computes 10.00 + 0.30 + 0.20 + 0.30 + 0.10 = 10.90 BTC. It has counted P twice and left Q in the accepted total.
A reconciliation can instead reverse the old branch’s effects, then apply the new branch: 10.50 − 0.30 − 0.20 + 0.30 + 0.10 = 10.40 BTC. Another implementation can update transaction records idempotently, meaning processing the same event again does not create another payment.
Keep Q’s prior observation in the audit trail with its new status. Removing its active-chain contribution is not a reason to erase the history of what your system saw. This arithmetic is an application example, not a description of Bitcoin’s internal storage format.
Build an evidence record for a blockchain reorganization
A compact reconciliation record should identify the network, observer, observation timestamp, old tip hash, new tip hash, and common ancestor. For affected receipts, preserve transaction ID, output index where relevant, amount, previous block hash, and current inclusion status.
Bitcoin Core’s getchaintips documentation distinguishes active, valid-fork, invalid, and other branch states. A branch known to a node is not necessarily fully validated or selected. Record the actual status rather than interpreting every listed tip as a competing accepted chain.
An explorer can assist with inspection; the blockchain explorer guide covers the underlying evidence fields. Avoid treating a page’s visible height alone as sufficient proof that a particular block remains active.
For a human-reviewed spreadsheet, separate an observation log from the current accepted-state view. The first tells the story of what changed. The second answers which receipts the report currently includes.
Separate a branch change from its cause
A short competing-branch event does not by itself establish malicious behavior. Conversely, calling every reorg “normal” without checking its depth and surrounding evidence can hide an important incident.
Describe the observed facts first: the network, displaced blocks, new branch, affected transactions, and the sources that agree. Attribution requires additional evidence. A different block hash could also reflect a wrong network, stale cache, or inconsistent endpoint rather than a confirmed reorg.
Applications should apply their own documented acceptance and incident procedures. The Bitcoin confirmations article explains how block depth is reported; it does not make one depth suitable for every payment, bridge, or business obligation.
Frequently asked questions
Is a blockchain reorganization the same as a software hard fork?
No. A reorg describes a change in the accepted branch under the rules a node is applying. A hard fork concerns incompatible rule changes. Both can involve branching, but the cause and operational implications should not be assumed identical.
Why is block height insufficient to identify a payment’s block?
Different branches can each contain a block at the same height. The block hash distinguishes them. Save the hash with the height so a later check can determine whether that specific block remains part of the accepted chain.
Does a blockchain reorganization erase every displaced transaction?
No. A transaction may already appear on the replacement branch, remain eligible for later inclusion, or conflict with the new state. Inspect each affected transaction rather than applying one outcome to every transaction in the displaced blocks.
Can the same transaction appear in removed and current results?
Yes. A reporting interface may preserve its previous removal while also showing its later active-chain inclusion. Bitcoin Core explicitly documents this possibility for listsinceblock. Reconcile identity and present status before interpreting a removed entry as a lost payment.
How should reorg depth be described?
State the number of blocks displaced from the previously accepted branch and identify the common ancestor. If useful, report the number of replacement blocks separately. This avoids ambiguity when the new branch extends farther than the old one.
Does the chain with the most blocks always win in Bitcoin?
The relevant criterion is accumulated proof of work among valid chains. Block count is a useful simplification only when the compared blocks contribute equal work. Invalid blocks do not become acceptable merely because a branch contains more of them.
Does a blockchain reorganization automatically prove a double-spend attack?
No. Competing blocks and delayed propagation can lead to branch changes without proving malicious intent. A double-spend allegation needs evidence of conflicting spends and context. Report the branch change separately from any proposed explanation or attribution.
Why can a wallet balance change after a blockchain reorganization?
The wallet may update which incoming or outgoing transactions belong to the accepted history and which are unconfirmed or conflicted. Different balance categories can respond differently. Inspect the affected transaction records rather than interpreting the total without its components.
Should an application delete its old observations?
Preserving an audit trail is generally more informative. Mark the old inclusion as displaced, update the current-state calculation, and retain the evidence needed to explain the correction. Blindly appending replacement events can double-count payments, while deleting history can hide the cause.
Can the same reconciliation rule be used on every chain?
The recordkeeping principles travel well, but branch-selection and finality rules are network-specific. Identify the chain and relevant protocol guarantees first. A Bitcoin example is not a universal model for when a different network considers a transaction final.
Explore the CrowdSent platform overview if you want to learn more about its approach to market research.
Educational information only. Examples are hypothetical and are not investment recommendations.