<p>Your understanding is basically correct. Keep in mind two things:</p>
<p>First, chain <strong>length</strong> isn't really the correct metric but <strong>accumulated chainwork</strong>. For practical discussion we can imagine for now they are the same thing.</p>
<p>Second: the entire purpose of Bitcoin full node software is to find the chain with most accumulated work. The whole meaning of its life is to discover that chain and synchronize its database with that chain (specifically, the UTXO set aka list of unspent coins aka &quot;the ledger&quot;).</p>
<p>So it does not matter who mined what block. As long as it is running, the full node will try to stay in sync with its peers by sending locator messages (<code>getheaders</code>) and responding to new block announcements.</p>
<p>When a full node receives a valid block header that has more chainwork than its own tip, it attempts to download whatever blocks are necessary to verify that chain. If those blocks are valid and require &quot;rewinding&quot; the current chain, the node will do so, iteratively.</p>
<p>Consider this set of chain tips:</p>
<pre><code>A-B-C-D-E-F
       \
        G-H-I
</code></pre>
<p>If your node synced blocks <code>A</code> through <code>F</code> then some time later learned about block header <code>I</code>, it will first download and verify headers <code>G</code> through <code>I</code>, then if they are valid download blocks <code>G</code> through <code>I</code>. If those blocks are valid, the node will disconnect <code>F</code> from its own chain, then disconnect <code>E</code>, then connect blocks <code>G</code> through <code>I</code> from the common ancestor <code>D</code>.</p>
<p>To address your points specifically:</p>
<ol start="2">
<li><p>You don't really &quot;request +100 blocks&quot; what you do is tell your peers about your own chain tip and ask them if they know about any chains with greater work.</p>
</li>
<li><p>&quot;orphaned blocks&quot; are blocks with no parent and this does not really ever happen on Bitcoin any more. I think you mean &quot;stale blocks&quot; here, but even then if peers do not respond with a greater-work chain, your node does nothing and assumes it is on the correct chain tip.</p>
</li>
<li><p>You would never &quot;lower&quot; your chain unless you were doing a reorg as I described above. In fact, if there were two blocks at height 10 you still wouldn't do anything until one of those chains got extended to height 11. THEN -- you become aware there is a greater-work chain out there and your node will attempt to download and verify it.</p>
</li>
</ol>

CC BY-SA 4.0
2020-10-31T12:12:45.173Z
2020-10-31T15:55:29.013Z
2020-10-31T15:55:29.013Z
pinhead
<p>i need an expert to clarify is my understanding correct to block reorganization. I can't find answer can persuade me, sound like only i dunno what is block reorganization :(.</p>
<p>say my bitcoin network has total 10 nodes, and 10 of 10 are all miners</p>
<p>say i had successfully mined a block#10, and that is another competitor also mined a same height of block at the same time and then i shut down my node.</p>
<p>after few days, i restart my node, so now what event will be trigger in my bitcoin program? i imagine possible steps would be like this. below &quot;I&quot; refers to my bitcoin node.</p>
<ol>
<li><p>i found my largest chainwork is block#10 with hash 0000123.</p>
</li>
<li><p>i broadcast getheader message to all my peers, with max query blocks = my block height + 100 to grab next 100 block headers after my block.</p>
</li>
<li><p>say 5 of my peers return me result. i wonder now is bitcoin performs PBFT on returned result? say at least 3 peers return me same result, then i assume that this result is correct.</p>
</li>
<li><p>ok, now result return from point 3 told me that there no longer got block added after my blockhash, i know my block has been orphaned.</p>
</li>
<li><p>next, i lower my block height to 9, then i ask my peers again, and peers response me yes that is block#10 which hash is 0000456 and prevhash same to my hash in block#9.</p>
</li>
<li><p>before start to download all blocks start from hash 0000456, i need orphan my block#10, so i remove it from chain and revert the transaction to mempool.</p>
</li>
<li><p>and now i feel safe to keep download until meet most chainwork block.</p>
</li>
</ol>
<p>i need your clarification. thanks.</p>

CC BY-SA 4.0
2020-10-31T11:57:54.603Z
Similar question answered here: https://bitcoin.stackexchange.com/a/98681/3667
pinhead
CC BY-SA 4.0
2020-11-01T00:31:32.873Z
thanks, it is very informative
Atlas Chiew
<chain-reorganization><best-chain><stale-block>
Is block reorg works in this way?
Atlas Chiew
# Is block reorg works in this way?

(Asked by: username_0 on 2020-10-31)

i need an expert to clarify is my understanding correct to block reorganization. I can't find answer can persuade me, sound like only i dunno what is block reorganization :(.

say my bitcoin network has total 10 nodes, and 10 of 10 are all miners

say i had successfully mined a block#10, and that is another competitor also mined a same height of block at the same time and then i shut down my node.

after few days, i restart my node, so now what event will be trigger in my bitcoin program? i imagine possible steps would be like this. below "I" refers to my bitcoin node.

1. i found my largest chainwork is block#10 with hash 0000123.
2. i broadcast getheader message to all my peers, with max query blocks = my block height + 100 to grab next 100 block headers after my block.
3. say 5 of my peers return me result. i wonder now is bitcoin performs PBFT on returned result? say at least 3 peers return me same result, then i assume that this result is correct.
4. ok, now result return from point 3 told me that there no longer got block added after my blockhash, i know my block has been orphaned.
5. next, i lower my block height to 9, then i ask my peers again, and peers response me yes that is block#10 which hash is 0000456 and prevhash same to my hash in block#9.
6. before start to download all blocks start from hash 0000456, i need orphan my block#10, so i remove it from chain and revert the transaction to mempool.
7. and now i feel safe to keep download until meet most chainwork block.

i need your clarification. thanks.

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

> **Comments:**
> **username_1**: Similar question answered here: https://bitcoin.stackexchange.com/a/98681/3667  
> **username_0**: thanks, it is very informative  

---

## 1 answers

### Answer by username_1 on 2020-10-31. Score: 2 | Accepted answer

Your understanding is basically correct. Keep in mind two things:

First, chain **length** isn't really the correct metric but **accumulated chainwork**. For practical discussion we can imagine for now they are the same thing.

Second: the entire purpose of Bitcoin full node software is to find the chain with most accumulated work. The whole meaning of its life is to discover that chain and synchronize its database with that chain (specifically, the UTXO set aka list of unspent coins aka "the ledger").

So it does not matter who mined what block. As long as it is running, the full node will try to stay in sync with its peers by sending locator messages (`getheaders`) and responding to new block announcements.

When a full node receives a valid block header that has more chainwork than its own tip, it attempts to download whatever blocks are necessary to verify that chain. If those blocks are valid and require "rewinding" the current chain, the node will do so, iteratively.

Consider this set of chain tips:

```
A-B-C-D-E-F
       \
        G-H-I

```

If your node synced blocks `A` through `F` then some time later learned about block header `I`, it will first download and verify headers `G` through `I`, then if they are valid download blocks `G` through `I`. If those blocks are valid, the node will disconnect `F` from its own chain, then disconnect `E`, then connect blocks `G` through `I` from the common ancestor `D`.

To address your points specifically:

2. You don't really "request +100 blocks" what you do is tell your peers about your own chain tip and ask them if they know about any chains with greater work.
3. "orphaned blocks" are blocks with no parent and this does not really ever happen on Bitcoin any more. I think you mean "stale blocks" here, but even then if peers do not respond with a greater-work chain, your node does nothing and assumes it is on the correct chain tip.
4. You would never "lower" your chain unless you were doing a reorg as I described above. In fact, if there were two blocks at height 10 you still wouldn't do anything until one of those chains got extended to height 11. THEN -- you become aware there is a greater-work chain out there and your node will attempt to download and verify it.


---

