<p>You can use the invalidateblock RPC commands to create blockchain forks.</p>

<p>invalidateblock <em>hash</em> tells a node to consider <em>hash</em> invalid, so just generate a bunch of blocks, invalidate one somewhere down the chain on one of the regtest nodes, and have that node generate a bunch more to create a fork.</p>

<p>See qa/rpc-tests/mempool_resurrect_test.py in the Bitcoin Core tree for a python example.</p>

CC BY-SA 3.0
2015-04-11T14:35:25.670Z
Thanks. I did not know about these RPC commands as they are not listed in the help command. One issue however, is that when you make a block invalid, the transactions would renter the mempool. This wouldn't allow to test scenarios of conflicting transactions being confirmed into forks, unless there was also a command which would remove/replace transactions from the mempool.
Matthew Mitchell
CC BY-SA 3.0
2015-05-14T15:42:45.543Z
@gavinandresen: is there a RPC other than `reconsiderblock` that considers a fork as valid without closing the fork? I have a scenario where I'd like to have 2 valid forks for 2 connected(!) nodes.
Aliakbar Ahmadi
CC BY-SA 4.0
2020-04-10T09:04:31.840Z
Any other commands that are hidden from the help? These seem fairly useful for development purposes.
thalisk
CC BY-SA 4.0
2021-03-03T21:29:10.997Z
It's worth noting that if you use this method, ZMQ's behavior will not be as described in the docs for proper reorgs (https://github.com/bitcoin/bitcoin/blob/master/doc/zmq.md). Say you have chain A -> B -> C, then invalidate C, then generate two new blocks, yielding A -> B -> C' -> D. ZMQ will notify A, B, C, C', and D, whereas the docs imply that in proper reorgs ZMQ would only notify A, B, C, and D.
yungblud
CC BY-SA 3.0
2015-04-09T19:26:20.130Z
2015-04-09T19:26:20.130Z
gavinandresen
<p>Depending on your language and bitcoin library, you can simulate a fake bitcoin peer. This is what I do when I develop with NBitcoin. (C#)</p>

<p>Basically, I setup 2 peers, the "client" and the "server", I then setup the client to "trust" my server node in tests. (meaning it does not verify block correctness and proof of work)</p>

<p>Then I pilot the server's behavior as I want to test any fork scenario.</p>

CC BY-SA 3.0
2015-04-06T20:49:58.700Z
I thought about creating a simulated node, though instead I managed to create a fork by isolating regtest nodes, which I will describe in a separate answer. Thanks.
Matthew Mitchell
CC BY-SA 3.0
2015-03-29T23:45:43.067Z
2015-03-29T23:45:43.067Z
Nicolas Dorier
<p>I managed to test forks by creating 3 reg test nodes. One node is used to interface with my software, and two other nodes are used to hold competing blockchains. The regtest mode starts each node with no connections to begin with, so they are completely isolated. I can use "sendrawtransaction" and "setgenerate" on these isolated nodes to create competing chains. However, the nodes need to sync to test fork scenarios. </p>

<p>It turned out to be easy to synchronise nodes. I sync the competing nodes with the interface node with help of the RPC command "disconnectpeer" which you can find <a href="https://github.com/gavinandresen/bitcoin-git/commit/499ae0b3d77e1c41d79f34329d555980676d1f3a" rel="noreferrer">here</a>. My synchronisation code is as follows in pseudocode:</p>

<pre><code>function sync (node1, node2)

    if node2.height &lt; node1.height then
        sync(node2, node1)
        return

    node1.rpc("addnode", "localhost:" + node2.port, "onetry")

    wait while node1.rpc("get_info")["blocks"] is not node1.height

    node1.height = node2.height
    node1.rpc("disconnectpeer", node1.rpc("getpeerinfo")[0]["id"])
</code></pre>

<p>After the function is complete the nodes will remain isolated once again so that you can work on creating new competing chains.</p>

CC BY-SA 3.0
2015-04-07T02:54:47.700Z
You can also use the RPC commands `invalidateblock` and `reconsiderblock` to aid with testing in this scenario. They allow you to disconnect and reorganize back and forwards in otherwise static situations.
Claris
CC BY-SA 3.0
2015-05-14T15:39:15.263Z
@MatthewMitchell: What is the rough idea of using an "interface node"? Isn't it sufficient to have 2 nodes only?
Aliakbar Ahmadi
CC BY-SA 3.0
2015-08-31T17:14:41.827Z
@AliakbarAhmadi: The idea is that you create two competing blockchains with to nodes and the "interface node" synchronises with either one. Once this interface node is synchronised, it can't make it's own fork (unless you used `invalidateblock` like Gavin suggested) so that's why you have the third node to keep isolated whilst the other two are synchronised. Then you use this third node to create another fork if desired for your test case.
Matthew Mitchell
CC BY-SA 4.0
2020-04-10T09:14:45.087Z
Nowadays it seems `disconnectpeer` is replaced by either (i) `addnode` with command `remove` or (ii) `disconnectnode`.
thalisk
CC BY-SA 3.0
2015-04-06T21:07:23.113Z
2015-04-06T21:07:23.113Z
Matthew Mitchell
<p>I want to test if a service can manage a blockchain fork. However there is no way to get bitcoind to create test forks under the regtest mode. I've tried modifying it to generate blocks with arbitrary prevblock hashes but it is not easy due to the high code complexity. I've managed to get it to create forks on-top of earlier blocks, however, I can't get it to generate blocks for conflicting transactions (double-spends and malleability changes), largely due to all of the "pruning" code. Surely someone has already come up with a solution, as this is a vital thing to test? I can't find anything on-line to help with testing fork scenarios.</p>

<p>I'm thinking that perhaps I should have used another technique? That I should have run 3 bitcoind regtest nodes and isolate them so that I can create multiple blockchains. 2 of them generate competing chains, and the other interfaces with the application. I can generate a fork scenario with the first two nodes, sync one of the nodes to the 3rd node and then sync the other node to generate the fork? I'd need to use a combination of addnode and tcpkill (?) to sync and then re-isolate the nodes. </p>

<p>This seems a ridiculous thing to do to test something so simple, so is there a better way?</p>

<bitcoind><blockchain-fork><regtest><testing><invalidateblock>
Testing blockchain forks
Matthew Mitchell
# Testing blockchain forks

(Asked by: username_0 on 2015-03-29)

I want to test if a service can manage a blockchain fork. However there is no way to get bitcoind to create test forks under the regtest mode. I've tried modifying it to generate blocks with arbitrary prevblock hashes but it is not easy due to the high code complexity. I've managed to get it to create forks on-top of earlier blocks, however, I can't get it to generate blocks for conflicting transactions (double-spends and malleability changes), largely due to all of the "pruning" code. Surely someone has already come up with a solution, as this is a vital thing to test? I can't find anything on-line to help with testing fork scenarios.

I'm thinking that perhaps I should have used another technique? That I should have run 3 bitcoind regtest nodes and isolate them so that I can create multiple blockchains. 2 of them generate competing chains, and the other interfaces with the application. I can generate a fork scenario with the first two nodes, sync one of the nodes to the 3rd node and then sync the other node to generate the fork? I'd need to use a combination of addnode and tcpkill (?) to sync and then re-isolate the nodes.

This seems a ridiculous thing to do to test something so simple, so is there a better way?

**Tags:** bitcoind, blockchain-fork, regtest, testing, invalidateblock


---

## 3 answers

### Answer by username_0 on 2015-04-06. Score: 5 | Accepted answer

I managed to test forks by creating 3 reg test nodes. One node is used to interface with my software, and two other nodes are used to hold competing blockchains. The regtest mode starts each node with no connections to begin with, so they are completely isolated. I can use "sendrawtransaction" and "setgenerate" on these isolated nodes to create competing chains. However, the nodes need to sync to test fork scenarios.

It turned out to be easy to synchronise nodes. I sync the competing nodes with the interface node with help of the RPC command "disconnectpeer" which you can find [here](https://github.com/username_1/bitcoin-git/commit/499ae0b3d77e1c41d79f34329d555980676d1f3a). My synchronisation code is as follows in pseudocode:

```
function sync (node1, node2)

    if node2.height < node1.height then
        sync(node2, node1)
        return

    node1.rpc("addnode", "localhost:" + node2.port, "onetry")

    wait while node1.rpc("get_info")["blocks"] is not node1.height

    node1.height = node2.height
    node1.rpc("disconnectpeer", node1.rpc("getpeerinfo")[0]["id"])

```

After the function is complete the nodes will remain isolated once again so that you can work on creating new competing chains.

> **Comments:**
> **username_6**: You can also use the RPC commands `invalidateblock` and `reconsiderblock` to aid with testing in this scenario. They allow you to disconnect and reorganize back and forwards in otherwise static situations.  
> **username_2**: @username_0: What is the rough idea of using an "interface node"? Isn't it sufficient to have 2 nodes only?  
> **username_0**: @username_2: The idea is that you create two competing blockchains with to nodes and the "interface node" synchronises with either one. Once this interface node is synchronised, it can't make it's own fork (unless you used `invalidateblock` like Gavin suggested) so that's why you have the third node to keep isolated whilst the other two are synchronised. Then you use this third node to create another fork if desired for your test case.  
> **username_3**: Nowadays it seems `disconnectpeer` is replaced by either (i) `addnode` with command `remove` or (ii) `disconnectnode`.  

---

### Answer by username_1 on 2015-04-09. Score: 10

You can use the invalidateblock RPC commands to create blockchain forks.

invalidateblock *hash* tells a node to consider *hash* invalid, so just generate a bunch of blocks, invalidate one somewhere down the chain on one of the regtest nodes, and have that node generate a bunch more to create a fork.

See qa/rpc-tests/mempool\_resurrect\_test.py in the Bitcoin Core tree for a python example.

> **Comments:**
> **username_0**: Thanks. I did not know about these RPC commands as they are not listed in the help command. One issue however, is that when you make a block invalid, the transactions would renter the mempool. This wouldn't allow to test scenarios of conflicting transactions being confirmed into forks, unless there was also a command which would remove/replace transactions from the mempool.  
> **username_2**: @username_1: is there a RPC other than `reconsiderblock` that considers a fork as valid without closing the fork? I have a scenario where I'd like to have 2 valid forks for 2 connected(!) nodes.  
> **username_3**: Any other commands that are hidden from the help? These seem fairly useful for development purposes.  
> **username_4**: It's worth noting that if you use this method, ZMQ's behavior will not be as described in the docs for proper reorgs (https://github.com/bitcoin/bitcoin/blob/master/doc/zmq.md). Say you have chain A -> B -> C, then invalidate C, then generate two new blocks, yielding A -> B -> C' -> D. ZMQ will notify A, B, C, C', and D, whereas the docs imply that in proper reorgs ZMQ would only notify A, B, C, and D.  

---

### Answer by username_5 on 2015-03-29. Score: 1

Depending on your language and bitcoin library, you can simulate a fake bitcoin peer. This is what I do when I develop with NBitcoin. (C#)

Basically, I setup 2 peers, the "client" and the "server", I then setup the client to "trust" my server node in tests. (meaning it does not verify block correctness and proof of work)

Then I pilot the server's behavior as I want to test any fork scenario.

> **Comments:**
> **username_0**: I thought about creating a simulated node, though instead I managed to create a fork by isolating regtest nodes, which I will describe in a separate answer. Thanks.  

---

