Testing blockchain forks

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?

Matthew Mitchell

Posted 2015-03-29T19:52:25.787

Reputation: 253

Answers

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.

Matthew Mitchell

Posted 2015-03-29T19:52:25.787

Reputation: 253

1You 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. – Anonymous – 2015-04-07T02:54:47.700

@MatthewMitchell: What is the rough idea of using an "interface node"? Isn't it sufficient to have 2 nodes only? – Aliakbar Ahmadi – 2015-05-14T15:39:15.263

1@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 – 2015-08-31T17:14:41.827

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.

gavinandresen

Posted 2015-03-29T19:52:25.787

Reputation: 3 254

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 – 2015-04-11T14:35:25.670

@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 – 2015-05-14T15:42:45.543

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.

Nicolas Dorier

Posted 2015-03-29T19:52:25.787

Reputation: 689

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 – 2015-04-06T20:49:58.700