<p>There is no limit to how far a node will reorg given a chain with a larger proof of work, as long as the chain also starts from the hardcoded genesis block (which means they cannot be completely &quot;non-overlapping&quot;).</p>
<p>As far as I can tell, the propagation of the new chain would go something like this*: The nodes first coming into contact with the &quot;magic node&quot; will start downloading and validating this new chain, until they validate far enough that its proof of work has exceeded their original chain's POW. This might take minutes to days depending on the distribution of mining difficulty in this new chain, how many transactions are in each block (if any) and also on the node's processing power and bandwith. At this point the node will start relaying this new chain to its peers and they would start validating it. Thus the new chain will slowly but surely propagate through the network until all nodes are synced.</p>
<p>* Based on some assumptions about how Bitcoin nodes should work.</p>

CC BY-SA 4.0
2022-01-03T01:45:14.650Z
Got it. I'm interested in the technical details of "coming into contact" ... My understanding is that the bitcoin nodes only validate against a peer header chain upon initial start or restart... then they depend on receiving propagated blocks from neighbors. So there seems to be an edge case if no node in the network reboots (and thus no node ever loads the new header chain from the "magic node")
user491880
CC BY-SA 4.0
2022-01-03T02:13:52.043Z
A node must be able to accept conflicting chain headers at any time there might be a reorganization, not just when it's restarted.
Vojtěch Strnad
CC BY-SA 4.0
2022-01-02T15:39:49.183Z
2022-01-03T00:18:42.610Z
2022-01-03T00:18:42.610Z
Vojtěch Strnad
<p>Let's say the current chain consensus has a total POW of X... this is agreed upon by all 10k+ BTC nodes.</p>
<p>A new &quot;magic&quot; node joins and it has mined a chain (privately) with total POW = 2*X. The new nodes chain is on the order of hundreds of thousands of blocks as is the current consensus chain...but they are totally non-overlapping, how would the &quot;magic nodes&quot; new higher POW chain propagate through the network (or would it?)</p>

<consensus><p2p><chain-reorganization>
How do bitcoin nodes rollback state when a higher POW chain is introduced
user491880
# How do bitcoin nodes rollback state when a higher POW chain is introduced

(Asked by: username_0 on 2022-01-02)

Let's say the current chain consensus has a total POW of X... this is agreed upon by all 10k+ BTC nodes.

A new "magic" node joins and it has mined a chain (privately) with total POW = 2\*X. The new nodes chain is on the order of hundreds of thousands of blocks as is the current consensus chain...but they are totally non-overlapping, how would the "magic nodes" new higher POW chain propagate through the network (or would it?)

**Tags:** consensus, p2p, chain-reorganization


---

## 1 answers

### Answer by username_1 on 2022-01-02. Score: 1

There is no limit to how far a node will reorg given a chain with a larger proof of work, as long as the chain also starts from the hardcoded genesis block (which means they cannot be completely "non-overlapping").

As far as I can tell, the propagation of the new chain would go something like this\*: The nodes first coming into contact with the "magic node" will start downloading and validating this new chain, until they validate far enough that its proof of work has exceeded their original chain's POW. This might take minutes to days depending on the distribution of mining difficulty in this new chain, how many transactions are in each block (if any) and also on the node's processing power and bandwith. At this point the node will start relaying this new chain to its peers and they would start validating it. Thus the new chain will slowly but surely propagate through the network until all nodes are synced.

\* Based on some assumptions about how Bitcoin nodes should work.

> **Comments:**
> **username_0**: Got it. I'm interested in the technical details of "coming into contact" ... My understanding is that the bitcoin nodes only validate against a peer header chain upon initial start or restart... then they depend on receiving propagated blocks from neighbors. So there seems to be an edge case if no node in the network reboots (and thus no node ever loads the new header chain from the "magic node")  
> **username_1**: A node must be able to accept conflicting chain headers at any time there might be a reorganization, not just when it's restarted.  

---

