Valid fork in regtest - Change blockchain via RPC?

Question

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?

Answer 1

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

Answer 2

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.

Answer 3

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