<h1>Question 1</h1>
<p>The chain with the most work needs to be the tip.  I'm assuming you are working through bitcoind:</p>
<p>So I would simply go through the a list of all blocks received ever (A-E and X-Z) in my array and find the block with the most total work.  You get this info from <code>chainwork</code> in the <code>getblock</code> <a href="https://bitcoin.org/en/developer-reference#getblock" rel="nofollow noreferrer">api call</a> on bitcoind.  Assuming you have that available.</p>
<p>Then the current chain becomes the chain indicated by following <code>prevblockhash</code> backwards from the tip to the Genesis block.  This should then result in a chain Z,Y,X,C,B,A.  Any block not in this chain becomes orphan.</p>
<h1>Question 2</h1>
<p>You can then count forks that your node has seen in a couple of ways:</p>
<ul>
<li>checking any blocks that are referenced by as the <code>previousblockhash</code> by multiple blocks.</li>
<li>by creating your own <code>nextblockhash</code> reference and counting the number of times you have more than one of these in a block.</li>
<li>counting the number of times you have multiple blocks in your array at the same height (though this will overestimate if there are multi-block forks).</li>
</ul>
<p>I don't know exactly what the average fork rate is but there is not a single answer.  As different nodes will see different forks.  Using a public block explorer like <a href="https://blockchain.info/" rel="nofollow noreferrer">blockchain.info</a> might be a good source to get a feel for this.</p>
<p>On <a href="http://blockchain.info/charts/n-orphaned-blocks?timespan=180days&amp;showDataPoints=false&amp;daysAverageString=1&amp;show_header=true&amp;scale=0&amp;address=" rel="nofollow noreferrer">their data</a> I count 78 orphaned blocks in the last 180 days.  At a rate of 0.43 per day that should be close to the rate of forks.  The rate of forking should be lower as I ignore forks longer than 1 block.</p>
<p>You should be able to crawl their <a href="http://blockchain.info/api/blockchain_api" rel="nofollow noreferrer">API</a> in a similar way to suggested above to find the fork rate. You would be dependent on the accuracy of their data which has had issues.</p>

CC BY-SA 3.0
2016-07-13T11:48:32.103Z
2016-07-13T11:48:32.103Z
2020-06-16T11:10:03.350Z
Louis
<p>You can use the <code>getchaintips</code> RPC, which will list all tips of the known block tree, including branches that were never active.</p>

<p>You may see for example:</p>

<pre><code>{
    "height": 420561,
    "hash": "000000000000000001cb02590846299c91794e9b9f422513cff4b9c1dd5c62a",
    "branchlen": 0,
    "status": "active"
},
{
    "height": 419698,
    "hash": "000000000000000004a3a78750438d0491b6335cbbe9c15099a6e55b6943e51a",
    "branchlen": 1,
    "status": "valid-headers"
},
{
    "height": 418868,
    "hash": "000000000000000000ba1d7d93ad1c7f04fb4a430fdee67c44fbdd3236f2b805",
    "branchlen": 1,
    "status": "valid-fork"
},
</code></pre>

<p>Here you can see that the current best valid chain we know of is at height 420561. There are also two forks:</p>

<ul>
<li>One branching off at height 419697 and extending to height 419698. It has status "valid-headers", which means we heard about the headers for this block, but by the time they were verified, we already had an equivalent or better block available, so we did not attempt to download the forked block at height 419698.</li>
<li>One branching off at height 418867 and extending to height 418868. It has status "valid-fork", which means we actually heard about this block at a time when it was the best block, and proceeded to download and validate it, which was succesful. Later the branch was overtaken by the branch that is leading up to our current tip.</li>
</ul>

<p>So this not only allows you to detect reorganizations, but gives information about all historic ones your node observed and/or went through.</p>

CC BY-SA 3.0
2016-08-02T16:13:20.820Z
Excellent. Do you also know what headers-only means?
inersha
CC BY-SA 3.0
2016-08-02T17:33:29.053Z
valid-fork means we received and validated the blocks in this fork. valid-headers means we received the blocks but never bothered to verify them, as they were no longer the best chain when we got them. headers-only means we never even received the blocks.
Pieter Wuille
CC BY-SA 3.0
2016-08-02T18:37:23.717Z
Why would a node receive a block header (headers-only) but not download the rest of the block? Or to put it another way, why would a node download a full block (valid-headers) if the node knows that we already have a valid block at the same height?
inersha
CC BY-SA 3.0
2016-08-02T19:37:32.270Z
@inersha Because it may have learned of a better block that extends another chain after requesting the header, but before receiving the header. In that case we don't bother downloading the rest of the block data.
Pieter Wuille
CC BY-SA 3.0
2016-07-13T14:01:44.993Z
2016-07-13T15:38:23.003Z
2016-07-13T15:38:23.003Z
Pieter Wuille
<p>I'm keeping a simple log of blocks, and storing them in an array. When a new block arrives, I add it to the array.</p>

<p>Let's say this is my block chain array:</p>

<pre><code>E    &lt;- tip
D
C
B
A
</code></pre>

<p>Now, say a new block arrives, extending a branch:</p>

<pre><code>     Z    &lt;- new tip
E    Y
D    X    &lt;- new branch start
     C
     B
     A
</code></pre>

<p>Now the blocks <code>C</code> and <code>D</code> have been replaced in the <em>main chain</em> by <code>X</code> and <code>Y</code>.</p>

<p><strong>Questions:</strong></p>

<ol>
<li>Is there a way to detect that the latest block has extended a branch?

<ul>
<li><em>In other words, how can I detect whether blocks lower down in the array need to be replaced?</em></li>
</ul></li>
<li>How frequently does this happen?</li>
</ol>

<p><strong>EDIT:</strong> Initial solution is to check if the <code>previousblockhash</code> of the new block is equal to the hash of the tip in the array. If not, update the old tip, and keep working down through the array updating each block until their is a match for the <code>previousblockhash</code>.</p>

<blockchain-fork><bitcoin-cli>
How to detect a fork with bitcoin-cli?
inersha
# How to detect a fork with bitcoin-cli?

(Asked by: username_0 on 2016-05-27)

I'm keeping a simple log of blocks, and storing them in an array. When a new block arrives, I add it to the array.

Let's say this is my block chain array:

```
E    <- tip
D
C
B
A

```

Now, say a new block arrives, extending a branch:

```
     Z    <- new tip
E    Y
D    X    <- new branch start
     C
     B
     A

```

Now the blocks `C` and `D` have been replaced in the *main chain* by `X` and `Y`.

**Questions:**

1. Is there a way to detect that the latest block has extended a branch?
   * *In other words, how can I detect whether blocks lower down in the array need to be replaced?*
2. How frequently does this happen?

**EDIT:** Initial solution is to check if the `previousblockhash` of the new block is equal to the hash of the tip in the array. If not, update the old tip, and keep working down through the array updating each block until their is a match for the `previousblockhash`.

**Tags:** blockchain-fork, bitcoin-cli


---

## 2 answers

### Answer by username_2 on 2016-07-13. Score: 6 | Accepted answer

You can use the `getchaintips` RPC, which will list all tips of the known block tree, including branches that were never active.

You may see for example:

```
{
    "height": 420561,
    "hash": "000000000000000001cb02590846299c91794e9b9f422513cff4b9c1dd5c62a",
    "branchlen": 0,
    "status": "active"
},
{
    "height": 419698,
    "hash": "000000000000000004a3a78750438d0491b6335cbbe9c15099a6e55b6943e51a",
    "branchlen": 1,
    "status": "valid-headers"
},
{
    "height": 418868,
    "hash": "000000000000000000ba1d7d93ad1c7f04fb4a430fdee67c44fbdd3236f2b805",
    "branchlen": 1,
    "status": "valid-fork"
},

```

Here you can see that the current best valid chain we know of is at height 420561. There are also two forks:

* One branching off at height 419697 and extending to height 419698. It has status "valid-headers", which means we heard about the headers for this block, but by the time they were verified, we already had an equivalent or better block available, so we did not attempt to download the forked block at height 419698.
* One branching off at height 418867 and extending to height 418868. It has status "valid-fork", which means we actually heard about this block at a time when it was the best block, and proceeded to download and validate it, which was succesful. Later the branch was overtaken by the branch that is leading up to our current tip.

So this not only allows you to detect reorganizations, but gives information about all historic ones your node observed and/or went through.

> **Comments:**
> **username_0**: Excellent. Do you also know what headers-only means?  
> **username_2**: valid-fork means we received and validated the blocks in this fork. valid-headers means we received the blocks but never bothered to verify them, as they were no longer the best chain when we got them. headers-only means we never even received the blocks.  
> **username_0**: Why would a node receive a block header (headers-only) but not download the rest of the block? Or to put it another way, why would a node download a full block (valid-headers) if the node knows that we already have a valid block at the same height?  
> **username_2**: @username_0 Because it may have learned of a better block that extends another chain after requesting the header, but before receiving the header. In that case we don't bother downloading the rest of the block data.  

---

### Answer by username_1 on 2016-07-13. Score: 1

# Question 1

The chain with the most work needs to be the tip. I'm assuming you are working through bitcoind:

So I would simply go through the a list of all blocks received ever (A-E and X-Z) in my array and find the block with the most total work. You get this info from `chainwork` in the `getblock` [api call](https://bitcoin.org/en/developer-reference#getblock) on bitcoind. Assuming you have that available.

Then the current chain becomes the chain indicated by following `prevblockhash` backwards from the tip to the Genesis block. This should then result in a chain Z,Y,X,C,B,A. Any block not in this chain becomes orphan.

# Question 2

You can then count forks that your node has seen in a couple of ways:

* checking any blocks that are referenced by as the `previousblockhash` by multiple blocks.
* by creating your own `nextblockhash` reference and counting the number of times you have more than one of these in a block.
* counting the number of times you have multiple blocks in your array at the same height (though this will overestimate if there are multi-block forks).

I don't know exactly what the average fork rate is but there is not a single answer. As different nodes will see different forks. Using a public block explorer like [blockchain.info](https://blockchain.info/) might be a good source to get a feel for this.

On [their data](http://blockchain.info/charts/n-orphaned-blocks?timespan=180days&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&address=) I count 78 orphaned blocks in the last 180 days. At a rate of 0.43 per day that should be close to the rate of forks. The rate of forking should be lower as I ignore forks longer than 1 block.

You should be able to crawl their [API](http://blockchain.info/api/blockchain_api) in a similar way to suggested above to find the fork rate. You would be dependent on the accuracy of their data which has had issues.


---

