## Concept explanation A **chain reorganisation** can begin when two different miners produce different but still **valid blocks** at the same **height** before hearing about each other’s work. Because each new block extends the same earlier parent, nodes that hear about one tip first may temporarily treat that branch as their current **best chain**, while other nodes may choose the other branch. This short-lived disagreement does not mean anyone is cheating or that a block is invalid; it just means the network has briefly seen two equally plausible next steps. ## What you see You’re looking at one shared blockchain path that reaches `Block 3`, then splits into two competing tip blocks: `Tip A` and `Tip B`. The highlighted teal path shows which branch a single node currently considers its best chain after hearing one tip first. The other tip stays visible as a side branch, so you can compare both valid options and see how a fork can exist temporarily even when all observed blocks follow the rules. ## Try it yourself - **Click `Tip A`** to simulate a node hearing Miner A’s valid block first and watch that branch become the current best chain. - **Click `Tip B`** to switch the node’s first-heard block and see the highlight move to the other branch. - **Adjust the fork separation slider** to spread the two competing tips farther apart and make the branching structure easier to inspect. - **Move the chain spacing slider** to change the horizontal distance between blocks and notice that the underlying fork logic stays the same. - **Press `Reset view`** to return to the default layout and the original first-heard choice. ## Concept explanation A blockchain node can briefly see multiple valid branches that share the same **ancestor**. To decide which branch to treat as **canonical**, it applies a **fork-choice rule**: follow the branch with greater **cumulative work** or **weight**, not simply the one you noticed first. That means the preferred branch can change over time. If new blocks add enough work to the losing branch, it can overtake the other and become the new canonical history. ## What you see You’re looking at two competing branches splitting from one shared ancestor. Each branch is drawn as a sequence of blocks, and the bars on the right show each branch’s total accumulated work. The branch with the teal glow is the one the node currently considers canonical. When totals are equal, neither side has an advantage yet, so the view shows a tie. ## Try it yourself - **Use the branch selector** to choose which branch receives new work. - **Drag the extra work slider** to add more cumulative work to that branch and watch the totals update. - **Notice when the glowing canonical highlight switches** as soon as one branch’s total exceeds the other. - **Set the slider back to `0`** to see the equal-work tie state again. - **Press `Reset`** and then **repeat with the other branch selected** to confirm that fork choice depends on total work, not branch position on the screen. ## Concept explanation A **reorganisation** happens when a node stops treating one suffix of blocks as the best history and instead accepts a different suffix from a competing branch that has become heavier. The shared prefix before the fork point stays the same, but the previously accepted tail is replaced. Any transactions that were only confirmed in the removed suffix become unconfirmed again and go back to the **mempool**, unless they also appear somewhere on the new canonical suffix. ## What you see You are looking at one node’s current **canonical chain** across the top and a rival branch below it that splits several blocks back. Small colored tokens represent transactions inside each block. After the switch, the rival suffix moves into the canonical position, the old suffix is marked stale, and only the transactions that disappeared from the accepted history animate back into the mempool area. Tokens that appear on both branches stay confirmed, which shows exactly what changes and what does not during a reorg. ## Try it yourself - **Click `Adopt heavier rival branch`** and watch which blocks remain part of the shared history versus which suffix gets replaced. - **Look at the stale red-marked blocks after the switch** to see the blocks that used to be accepted but are no longer canonical. - **Track the colored tokens that drop into the mempool** and notice that these are the transactions removed from the old suffix and not present on the new one. - **Use the `Highlight mode` dropdown** to focus on returned mempool transactions or on transactions that were reconfirmed on the new suffix. - **Hover over a transaction token** and read the token inspector to check whether that transaction stays confirmed, gets reconfirmed on the rival branch, or returns to the mempool. - **Press `Reset example`** and repeat the transition until you can explain which state is preserved, which state is replaced, and why the mempool changes. ## Concept explanation A blockchain transaction becomes harder to reverse as more **confirmations** are added on top of the block that contains it. Each new block means a rival chain would need to fork from before that transaction and then grow long enough to replace the accepted history. That lowers the chance of a successful **reorganisation**-based reversal, but it does not reduce the risk to zero: a sufficiently long competing branch could still overtake the canonical chain. ## What you see You are looking at a blue **canonical chain** and a red competing branch that forks off just before the gold transaction block. The teal dots mark how many confirming blocks sit above the transaction, while the right panel shows how many rival blocks are currently being built and how many would be needed to replace the transaction. The risk meter drops as the transaction gets buried deeper, and rises again if the rival branch gets closer to catching up. ## Try it yourself - **Drag the confirmations slider** to add more blocks above the gold transaction and watch the reverse threshold increase. - **Move the rival branch slider** to grow the red branch and see when it gets close to overtaking. - **Compare `1`, `3`, and `6` confirmations** and notice that the required rival length keeps increasing. - **Turn animation on and off** to focus on the rival branch growth without motion. - **Press Reset** and then test different combinations to see that deeper inclusion lowers risk progressively, but never makes reversal impossible. ## Concept explanation A blockchain can experience an **honest reorganisation** even when nobody is attacking it. If two miners produce valid blocks at nearly the same time, and **network latency** delays how fast those blocks spread, different parts of the network can temporarily believe different tips are the latest block. As more blocks arrive, one branch eventually becomes the accepted continuation and the other is abandoned, creating a short **reorg**. You can think of reorg risk as a timing problem: when propagation delay becomes large compared with the average time between new blocks, temporary disagreement becomes more common. ## What you see You are looking at a network of nodes connected by communication links. Block `A` starts spreading from one side, and block `B` may appear elsewhere before `A` has reached everyone. Blue nodes currently see tip `A`, red nodes see tip `B`, and gray nodes have not received either competing block yet. The status card summarizes how many nodes disagree at this moment, while the timing-pressure bar shows how large latency is relative to block production speed. ## Try it yourself - **Increase the network latency slider** and watch the colored wavefronts take longer to cross the network. - **Lower the average block interval** so the second block appears sooner, then notice how more nodes split across different tips. - **Compare high-latency and low-latency settings** to see when the fork window stays tiny versus when it grows wide enough for many nodes to disagree. - **Press `Reshuffle race`** to generate a new network layout and a fresh pair of honest miners. - **Keep `loop` enabled** and observe how one branch is later abandoned, even though both blocks were mined honestly. - **Watch the “natural reorg chance” readout** as you change the sliders and connect the probability to the latency-to-interval ratio. ## Concept explanation A **reorganisation attack** happens when an adversary secretly mines a competing branch from an earlier block while the honest network continues extending the public chain. The attacker first lets a payment to the merchant appear on the public chain, but privately builds an alternative branch that **excludes** that payment and usually replaces it with a conflicting transaction back to the attacker. If the hidden branch later accumulates more **cumulative work** and is revealed after the merchant has released goods, the network can switch to that heavier branch, reversing the merchant’s payment. That is why double-spend risk depends on both the attacker’s mining share and how many confirmations the merchant waits for. ## What you see You can compare two branches growing in parallel from the same fork point. The top row is the visible public chain, including the merchant payment block and later confirmations. The bottom row is the attacker’s hidden branch, which starts from an earlier block and contains a conflicting spend instead of the merchant payment. The status card tracks the payment’s current confirmation depth, whether goods have been released, and the work gap between branches, so you can see whether the attacker catches up in time or falls behind. ## Try it yourself - **Increase the attacker hash power slider** and watch the hidden branch catch up more often before the merchant releases goods. - **Lower the confirmation policy slider** to see how releasing goods after only `1` or `2` confirmations makes reversals much easier. - **Raise the confirmation policy slider** and notice how extra waiting depth gives the honest chain more time to build a stronger lead. - **Press `Reset race`** several times with the same settings to see that the outcome is probabilistic, not guaranteed. - **Pause the animation** and inspect which transactions appear in each branch, especially the merchant payment on the public branch and the attacker’s conflicting spend on the hidden branch. - **Compare a low attacker share with a high one** to see why reorg attacks become more dangerous as the attacker controls a larger fraction of total hash power. ## Concept explanation In blockchains, **finality** means how confidently you can treat a transaction as permanent. In a **probabilistic finality** design such as Nakamoto-style consensus, each new block adds more weight on top of your transaction, so reversal becomes less likely with depth but is never absolutely impossible under the model. In a **checkpoint-based finality** design, blocks may first be usable yet still tentative, and then a validator vote or checkpoint later makes them effectively irreversible under normal assumptions. The trade-off is that one system gives smooth, fast-growing confidence with some lingering reorg risk, while the other gives a sharper transition from tentative to finalized after a delay. ## What you see You are comparing two side-by-side histories for the same included transaction. The left chain shows confidence building continuously as more blocks bury the `tx`, while the red alternative branch illustrates that a deeper rival chain could still reorganize recent history. The right chain shows a transaction that appears first, remains reorgable for a while, and then gains explicit validator finality when the checkpoint box appears. The status cards and progress bars summarize whether the transaction is **still reorgable**, **likely safe**, or **no longer revertible** under normal assumptions. ## Try it yourself - **Drag the elapsed-time slider** from `0` upward and watch how the left chain becomes safer gradually while the right chain stays tentative until its checkpoint arrives. - **Stop at a small elapsed time** and compare the red alternative branches: both systems can still reorganize, but for different reasons. - **Move the slider to the checkpoint delay** and notice the sudden change on the right side from checkpoint-pending to finalized. - **Keep increasing time after finalization** and see that the checkpoint-based system closes the normal reversion window, while the probabilistic side only keeps reducing risk. - **Use the view-mode dropdown** to emphasize one system at a time and focus on how its safety story is communicated visually. - **Press Reset time** and replay the transition from fresh inclusion to deeper confidence or explicit finality.