user1439: 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?

user21478: 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.

user1439: 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. 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.

user53: 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.

1439: <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>
 21478: <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>
 1439: <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>
 53: <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>
