<p>The longest <em>valid</em> chain is always chosen automatically. Thus the way to make it forcefully switch is using the <code>invalidateblock</code> hidden RPC.</p>

CC BY-SA 3.0
2016-06-01T10:29:57.373Z
2016-06-01T10:29:57.373Z
Pieter Wuille
<p>I re-read the Bitcoin Developer Guide and re-read the help getchaintips section:</p>

<blockquote>
  <p>Each full node in the Bitcoin network independently stores a block chain containing only <strong>blocks validated by that node</strong>. When several nodes all have the same blocks in their block chain, they are considered to be in consensus. The validation rules these nodes follow to maintain consensus are called consensus rules.<br/></p>
</blockquote>

<p>and</p>

<blockquote>
  <p>Possible values for status:<br/>
  [..]<br/>
  "valid-fork":This branch is not part of the active chain, but is <strong>fully validated</strong><br/>
  [..]</p>
</blockquote>

<p><strong>For a)</strong> So in order to achieve a valid-fork status for a previously invalidated block hash node0 needs to reconsider that very block hash in order to have it fully validated on its copy of blockchain. This can be achieved by <code>reconsiderblock &lt;block hash&gt;</code>.</p>

<p><strong>Note:</strong><code>reconsiderblock</code> <em>apparently "closes" the fork since</em> <code>getchaintips</code> <em>returns the same block hash for the active chain tip for both nodes.</em> </p>

<p><strong>For b)</strong> Nothing found out yet. </p>

CC BY-SA 3.0
2015-09-05T02:14:11.170Z
For b: invalidateblock RPC marks a block as unconditionally invalid. The reconsiderblock RPC wipes this invalid state.
Pieter Wuille
CC BY-SA 3.0
2015-05-14T14:25:06.493Z
2015-05-14T15:29:16.297Z
2015-05-14T15:29:16.297Z
Aliakbar Ahmadi
<p>Regarding a) I'm not really familiar how it validates the block, but my guess is no.</p>

<p>as for b) it is possible to give up its own chain of the other chain is the longest valid chain.</p>

<blockquote>
  <p>Blocks in shorter chains (or invalid chains) are not used for anything. When the bitcoin client switches to another, longer chain, all valid transactions of the blocks inside the shorter chain are re-added to the pool of queued transactions and will be included in another block. The reward for the blocks on the shorter chain will not be present in the longest chain, so they will be practically lost, which is why a network-enforced 100-block maturation time for generations exists.</p>
</blockquote>

<ul>
<li><a href="https://en.bitcoin.it/wiki/Block_chain" rel="nofollow">https://en.bitcoin.it/wiki/Block_chain</a></li>
</ul>

CC BY-SA 3.0
2015-05-14T14:27:48.923Z
For b) You quote "When the bitcoin client switches to another, longer chain, all [...]" - But my question is **how** one can conciously, e.g. as per a RPC, switch the chain!?
Aliakbar Ahmadi
CC BY-SA 3.0
2016-03-02T23:30:03.413Z
The longest chain is always selected by the wallet software there is no RPC option to force a chain switch.
Mark S.
CC BY-SA 3.0
2015-05-12T14:57:25.960Z
2015-05-13T17:23:26.637Z
2015-05-13T17:23:26.637Z
Shayan
<p>I've created a regtest network consisting of 2 nodes - node0 &amp; node1.<br/>
I'd like to have a fork on the common blockchain and seemingly achieved it by doing so:</p>

<ol>
<li>nodes start</li>
<li>node0 adds node1 via <code>addnode</code></li>
<li>node0 generates 1 block with hash 4dac...</li>
<li>node1 generates 1 block with hash 5d8b...</li>
<li>node0 invalidates node0's block with hash 5d8b... via <code>invalidate &lt;hash&gt;</code></li>
<li>node1 stops</li>
<li>node0 generates 1 block with hash 64f2...</li>
<li>node1 restarts</li>
<li>node1 generates 1 block with hash 5sfg...</li>
<li>node0: <code>getchaintips</code> returns an array with invalidated block's hash 5d8b... with status </li>
</ol>

<p><strong>Now my questions:<br/></strong>
<strong>a)</strong> How can I achieve a <em>"<code>valid-fork</code>" status</em> in the output of getchaintips for the previously invalidated fork? [SOLVED] <br/></p>

<h2><strong>b)</strong> Is it possible for a node to "conciously"/via RPC give up its own chain and switch to the competing chain?</h2>

CC BY-SA 3.0
2015-05-11T12:38:16.530Z
Did you had a look at: https://github.com/bitcoin/bitcoin/blob/master/qa/rpc-tests/getchaintips.py?
Jonas Schnelli
CC BY-SA 3.0
2015-05-14T10:41:02.923Z
@JonasSchnelli: Yes i looked at that code but didn't understand much since I'm not familiar with python..but one difference is there between my scenario and the scenario described inside the code: I have subbranches of same lengths and the code describes branches of different lengths..is this the key point?
Aliakbar Ahmadi
<blockchain><blockchain-fork><regtest>
Valid fork in regtest - Change blockchain via RPC?
Aliakbar Ahmadi
# Valid fork in regtest - Change blockchain via RPC?

(Asked by: username_0 on 2015-05-11)

I've created a regtest network consisting of 2 nodes - node0 & node1.  
I'd like to have a fork on the common blockchain and seemingly achieved it by doing so:

1. nodes start
2. node0 adds node1 via `addnode`
3. node0 generates 1 block with hash 4dac...
4. node1 generates 1 block with hash 5d8b...
5. node0 invalidates node0's block with hash 5d8b... via `invalidate <hash>`
6. node1 stops
7. node0 generates 1 block with hash 64f2...
8. node1 restarts
9. node1 generates 1 block with hash 5sfg...
10. node0: `getchaintips` returns an array with invalidated block's hash 5d8b... with status

**Now my questions:**
**a)** How can I achieve a *"`valid-fork`" status* in the output of getchaintips for the previously invalidated fork? [SOLVED]

## **b)** Is it possible for a node to "conciously"/via RPC give up its own chain and switch to the competing chain?

**Tags:** blockchain, blockchain-fork, regtest

> **Comments:**
> **username_1**: Did you had a look at: https://github.com/bitcoin/bitcoin/blob/master/qa/rpc-tests/getchaintips.py?  
> **username_0**: @username_1: Yes i looked at that code but didn't understand much since I'm not familiar with python..but one difference is there between my scenario and the scenario described inside the code: I have subbranches of same lengths and the code describes branches of different lengths..is this the key point?  

---

## 3 answers

### Answer by username_2 on 2016-06-01. Score: 1

The longest *valid* chain is always chosen automatically. Thus the way to make it forcefully switch is using the `invalidateblock` hidden RPC.


---

### Answer by username_0 on 2015-05-14. Score: 0

I re-read the Bitcoin Developer Guide and re-read the help getchaintips section:

> Each full node in the Bitcoin network independently stores a block chain containing only **blocks validated by that node**. When several nodes all have the same blocks in their block chain, they are considered to be in consensus. The validation rules these nodes follow to maintain consensus are called consensus rules.

and

> Possible values for status:  
> [..]  
> "valid-fork":This branch is not part of the active chain, but is **fully validated**  
> [..]

**For a)** So in order to achieve a valid-fork status for a previously invalidated block hash node0 needs to reconsider that very block hash in order to have it fully validated on its copy of blockchain. This can be achieved by `reconsiderblock <block hash>`.

**Note:**`reconsiderblock` *apparently "closes" the fork since* `getchaintips` *returns the same block hash for the active chain tip for both nodes.*

**For b)** Nothing found out yet.

> **Comments:**
> **username_2**: For b: invalidateblock RPC marks a block as unconditionally invalid. The reconsiderblock RPC wipes this invalid state.  

---

### Answer by username_3 on 2015-05-12. Score: -1

Regarding a) I'm not really familiar how it validates the block, but my guess is no.

as for b) it is possible to give up its own chain of the other chain is the longest valid chain.

> Blocks in shorter chains (or invalid chains) are not used for anything. When the bitcoin client switches to another, longer chain, all valid transactions of the blocks inside the shorter chain are re-added to the pool of queued transactions and will be included in another block. The reward for the blocks on the shorter chain will not be present in the longest chain, so they will be practically lost, which is why a network-enforced 100-block maturation time for generations exists.

* <https://en.bitcoin.it/wiki/Block_chain>

> **Comments:**
> **username_0**: For b) You quote "When the bitcoin client switches to another, longer chain, all [...]" - But my question is **how** one can conciously, e.g. as per a RPC, switch the chain!?  
> **username_4**: The longest chain is always selected by the wallet software there is no RPC option to force a chain switch.  

---

