<p>The same rules apply as during normal active-chain selection:</p>
<ol>
<li>Ignore all known-invalid blocks and their descendants</li>
<li>Of what remains, keep only the tips with the most chainwork</li>
<li>If there are multiple of those max-chainwork valid tips, pick the one which was received first.</li>
</ol>
<p>So in your example it would depend on how much chainwork <code>genesis+1</code> has. If it's more than 6, <code>1</code> would win. If it's less than 6, <code>1b</code> would win. If it is equal to 6, it will depend on whether <code>1</code> or <code>1b</code> was received first.</p>

CC BY-SA 4.0
2022-12-19T07:34:30.823Z
Follow up question:

Suppose I called `invalidateblock` on block `3`. `genesis+1+2`'s chainwork is 6. If block `1b`'s chainwork is 7, would the active chain tip now be `1b`?
kcalvinalvin
CC BY-SA 4.0
2022-12-19T14:03:00.940Z
@kcalvinalvin Yes, the history is not relevant in determining what the new best block becomes, given the set of blocks, their validity, their chainwork, and their time of receiving, you can always determine what the active chaintip becomes.
Pieter Wuille
CC BY-SA 4.0
2022-12-17T15:58:01.903Z
2022-12-17T15:58:01.903Z
Pieter Wuille
<p>I'm currently implementing the rpc call <code>invalidateblock</code> on btcd, an alternate Bitcoin full node implementation. I'm trying to figure out how Bitcoin Core handles branch selection on reorganizations with <code>invalidateblock</code>.</p>
<p>Say there's 3 chaintips like so:</p>
<pre><code>genesis -&gt; 1  -&gt; 2  -&gt; 3  (active)     (chainwork=8)
       \-&gt; 1a             (valid-fork) (chainwork=4)
       \-&gt; 1b             (valid-fork) (chainwork=6)
</code></pre>
<p>Blocks at height 1 were received in the order of: <code>1, 1a, 1b</code>. Block <code>1</code> was received most recently and block <code>1b</code> was received last.</p>
<p>If I call <code>invalidateblock</code> on block 2, which block will become the active chaintip?</p>

<bitcoin-core><json-rpc><chain-reorganization><invalidateblock>
InvalidateBlock RPC call behavior with Bitcoin Core
kcalvinalvin
# InvalidateBlock RPC call behavior with Bitcoin Core

(Asked by: username_0 on 2022-12-17)

I'm currently implementing the rpc call `invalidateblock` on btcd, an alternate Bitcoin full node implementation. I'm trying to figure out how Bitcoin Core handles branch selection on reorganizations with `invalidateblock`.

Say there's 3 chaintips like so:

```
genesis -> 1  -> 2  -> 3  (active)     (chainwork=8)
       \-> 1a             (valid-fork) (chainwork=4)
       \-> 1b             (valid-fork) (chainwork=6)

```

Blocks at height 1 were received in the order of: `1, 1a, 1b`. Block `1` was received most recently and block `1b` was received last.

If I call `invalidateblock` on block 2, which block will become the active chaintip?

**Tags:** bitcoin-core, json-rpc, chain-reorganization, invalidateblock


---

## 1 answers

### Answer by username_1 on 2022-12-17. Score: 5 | Accepted answer

The same rules apply as during normal active-chain selection:

1. Ignore all known-invalid blocks and their descendants
2. Of what remains, keep only the tips with the most chainwork
3. If there are multiple of those max-chainwork valid tips, pick the one which was received first.

So in your example it would depend on how much chainwork `genesis+1` has. If it's more than 6, `1` would win. If it's less than 6, `1b` would win. If it is equal to 6, it will depend on whether `1` or `1b` was received first.

> **Comments:**
> **username_0**: Follow up question:  Suppose I called `invalidateblock` on block `3`. `genesis+1+2`'s chainwork is 6. If block `1b`'s chainwork is 7, would the active chain tip now be `1b`?  
> **username_1**: @username_0 Yes, the history is not relevant in determining what the new best block becomes, given the set of blocks, their validity, their chainwork, and their time of receiving, you can always determine what the active chaintip becomes.  

---

