9

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?

Improve this question

3 Answers 3

Reset to default
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.

Improve this answer
4
  • 1
    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
    Commented Apr 11, 2015 at 14:35
  • @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
    Commented May 14, 2015 at 15:42
  • Any other commands that are hidden from the help? These seem fairly useful for development purposes.
    – thalisk
    Commented Apr 10, 2020 at 9:04
  • It's worth noting that if you use this method, ZMQ's behavior will not be as described in the docs for proper reorgs (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
    Commented Mar 3, 2021 at 21:29
5

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.

Improve this answer
4
  • 1
    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
    Commented Apr 7, 2015 at 2:54
  • @MatthewMitchell: What is the rough idea of using an "interface node"? Isn't it sufficient to have 2 nodes only?
    – Aliakbar Ahmadi
    Commented May 14, 2015 at 15:39
  • 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
    Commented Aug 31, 2015 at 17:14
  • Nowadays it seems disconnectpeer is replaced by either (i) addnode with command remove or (ii) disconnectnode.
    – thalisk
    Commented Apr 10, 2020 at 9:14
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.

Improve this answer
1
  • 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
    Commented Apr 6, 2015 at 20:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.