<p>One block. A node will always follow the valid blockchain that has the most cumulative work, even if it is more by just the work done for a single block. There's no reason to delay changing to the other branch if it has more cumulative work. The split should be resolved as soon as possible; by switching when one branch is observed to have more cumulative work than the other, the split can be resolved as quickly as possible.</p>

CC BY-SA 4.0
2021-08-23T15:02:44.567Z
Thanks, I understand that clients will defer to the valid blockchain containing the most work, even if by a fraction, but from my reading I took it that a fork of the chain which falls behind it's competitor by a sufficient amount is deemed 'stale' and may be discarded by nodes. This would make sense as it would theoretically prevent an adversary carrying out a 51% attack in an attempt to revive a historic fork in the chain and thereby invalidating a large amount of transactions (I understand this would be a mammoth task but still technically possible)
nohatsatthetable
CC BY-SA 4.0
2021-08-25T05:20:14.173Z
There’s no such consideration, a reorg can be infinitely deep no matter how old the chain being reactivated is. If this were not the case the network would fail consensus depending on what blocks you had seen or not seen.
Claris
CC BY-SA 4.0
2021-08-23T00:31:31.427Z
2021-08-23T00:31:31.427Z
Ava Chow
<p>so when two equally valid blocks are discovered at roughly the same time, a conflict occurs, nodes <em>should</em> wait for the strongest fork of the chain to emerge and develop before placing trust in the transactions within it. My question is how many additional blocks, above and beyond those of it's rival, must a fork of the chain achieve before nodes consider the rival fork to be stale and discard it? Is does this depend on the configuration of the node?</p>
<p>note that I'm not asking how many confirmations one should wait for before trusting a chain, but rather how many additional blocks are required before other nodes consider the competitor stale and actually discard it.</p>
<p>Thank you!</p>

<blockchain><chain-reorganization><best-chain><stale-block>
How many blocks extra does one need before it's competitor is deemed stale?
nohatsatthetable
# How many blocks extra does one need before it's competitor is deemed stale?

(Asked by: username_0 on 2021-08-21)

so when two equally valid blocks are discovered at roughly the same time, a conflict occurs, nodes *should* wait for the strongest fork of the chain to emerge and develop before placing trust in the transactions within it. My question is how many additional blocks, above and beyond those of it's rival, must a fork of the chain achieve before nodes consider the rival fork to be stale and discard it? Is does this depend on the configuration of the node?

note that I'm not asking how many confirmations one should wait for before trusting a chain, but rather how many additional blocks are required before other nodes consider the competitor stale and actually discard it.

Thank you!

**Tags:** blockchain, chain-reorganization, best-chain, stale-block


---

## 1 answers

### Answer by username_1 on 2021-08-23. Score: 2 | Accepted answer

One block. A node will always follow the valid blockchain that has the most cumulative work, even if it is more by just the work done for a single block. There's no reason to delay changing to the other branch if it has more cumulative work. The split should be resolved as soon as possible; by switching when one branch is observed to have more cumulative work than the other, the split can be resolved as quickly as possible.

> **Comments:**
> **username_0**: Thanks, I understand that clients will defer to the valid blockchain containing the most work, even if by a fraction, but from my reading I took it that a fork of the chain which falls behind it's competitor by a sufficient amount is deemed 'stale' and may be discarded by nodes. This would make sense as it would theoretically prevent an adversary carrying out a 51% attack in an attempt to revive a historic fork in the chain and thereby invalidating a large amount of transactions (I understand this would be a mammoth task but still technically possible)  
> **username_2**: There’s no such consideration, a reorg can be infinitely deep no matter how old the chain being reactivated is. If this were not the case the network would fail consensus depending on what blocks you had seen or not seen.  

---

