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 ...
Although I believe Fred Tingey's answer is complete, it has the following attributes:
it depends on a config file.
it provides examples for bitcoin-qt on the windows platform, and the OP was asking about bitcoind on the linux platform.
Thus, I wanted to share the following concise bash script which does what the OP wants. As others have partially noted the ...
In order to run multiple nodes in regtest mode on a single machine you will need to sandbox each node.
In this example I have three nodes, they are named Alice, Bob and Cory. Since Bitcoin is a Peer/Mesh network, my goal is to connect each nodes so that changes made to Cory are ultimately visible to Bob (without necessarily requiring a direct connection ...
You need to run more than one node on your machine (you can do that if you give each node a different -port and -rpcport). And you need to tell them how to find each other (using -connect=127.0.0.1:portnumber).
There are examples written in bash and python in the Bitcoin Core source tree:
It appears that Fred Tingey's answer was mostly correct, but contained incorrect port numbers in the samples he provided. If someone were to copy and paste it all it would not have worked correctly.
I've modified his answer, it is awaiting peer review.
The use of Ubuntu, Docker and VirtualBox shouldn't affect your ability to configure regtest.
You may ...
You probably want to run multiple bitcoind instances in regtest to simulate multiple nodes.
Thats pretty easy. You can run a second instance by starting bitcoind with a clean data directory and a different RPC and P2P port.
For that, you could create a 2nd data directory (example: /tmp/datadir2). Create /tmp/datadir2/bitcoin.conf.
Use something similar ...
Depending on your OS you can start a 2nd bitcoin-qt acting on a non-mainnet with ./bitcoin-qt -testnet or ./bitcoin-qt -regtest (from a shell). You can also define a custom datadir and place a bitcoin.conf there (use bitcoin-qt -datadir=<path>).
On OSX/Mac you would need to use Terminal and run something like /Applications/Bitcoin-Qt.app/Contents/...
It seems you're mixing up bitcoind and bitcoin-cli.
bitcoind is the Bitcoin Core daemon. It must be running first before you can do anything. bitcoin-cli is a tool to send RPC commands to a running bitcoind instance.
From the linked documentation page:
bitcoind -regtest -daemon
No need to put a & after the command if you run with -daemon.
Regtest is a network designed solely to be private and for testing only. You can create a private regtest network and do testing and experimentation with it. It is not a public network and has no peers for you to connect to.
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 ...
Nope. Not 1 bit. A balance (in this context) is the sum of all UTXO's for a given address. There is no limit on the number of UTXO's or their total amount (from the perspective of how the blockchain works and the blockchains limitations).
Software interpreting the balance may have limitations on consuming, processing and/or displaying a number beyond a ...
The main difference between signet and regtest is that signet is an actual network, as opposed to a sandboxed environment.
In regtest, the network topology is entirely manual. You spin up nodes, and manually establish connections between them. You have exact control over what blocks are mined and when. This is great for testing things like consensus logic, ...
Even on testnet the difficulty is sufficiently high that it will take you a long time to mine anything using cpu. (Lots of people testing ASICs, presumably.)
Your best bet is probably Testnet in a box. Then you can cpu mine just by using ´setgenerate true´ in Bitcoin Core.
getbalance returns the balance of an account, not an address. https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list
If there's no account by the name of mvt7M16caMH1xoJyfWU5orjArfq97jhZ7k, it will return 0.
Try using getreceivedbyaddress instead.
You only see the balance of blocks that have at least another 100 on top. This is because coinbase outputs only become spendable after 101 confirmations (the maturity period).
After the nodes reconnect, and one block is mined by node0, node1's previous chain is reorganized away, and from that point on, both nodes work on the same chain.
However, whenever a ...
No, there does not such thing as initialfreecoins=10000000. However mining on regtest is not resource hungry and nearly instant. It's the only way to get coins.
To get coins on regtest you first need a address to mine those coins to. An address can be created with
bitcoin-cli -regtest getnewaddress.
To mine and payout to this address use with <address&...
Signet is more comparable to testnet than it is to regtest.
Regtest is for private use and testing things. Even if signet were available, it is still useful to have your own blockchain for testing where you can generate coins, blocks, forks, and reorgs at will. It allows tests to run quickly and for a specific set of conditions to be tested. There is no ...
The regtest system is completely isolated from testnet and only exists on your local machine by default, you won't see the transaction from TPs faucet because it isn't on the same network. Blocks in your regtest setup can be instantly created using bitcoin-cli setgenerate true <number of blocks> each of which will bring into existence 50 BTC in your ...
Very likely you need to tell your PHP JSON RPC client to connect to the right port.
If you start bitcoind without -regtest (= main net), it opens up the RPC server on port 8332.
If you use -regtest, the port will be 18332.
I can't see what kind of PHP JSON RPC client you are using, but there must be a way to tell it should use port 18332.
v0.11.0 and after:
Check and make sure that your daemon version is v0.11.0 or greater. If it is, the generate method should work.
The setgenerate true method should be used.
In a standard network (such as testnet or main), setgenerate true will turn mining on indefinitely. In regtest, it just mines one block. You can also do
os.getpid() in Python is getting the current process id. The processor id is 'random-ish', in that running the entire test several times will result in a different pid, but within the same test the pid will remain constant.
The % operator is the modulus operator, which is essentially chopping off all but the last 3 digits of the processor id.
Oops! Noob mistake.
I thought that testnet and regtest had different version prefixes (not compatible) but they are (the bitcoin wiki and bitcoin developers page doesn't clarify this, though). So I went into a npm package that added dogecoin and litecoin testnets compatibility with bitcoinjs-lib (it's called bitcoinjs-testnets).
But the solution in the ...
I guess you are missing the coinbase immaturity here.
Coinbase transaction can only be spent after 100 blocks.
A single generate will not make the coinbase-transaction appear in listunspent. If you do a generate 101 it will (because you mine 100 blocks on top of your "fee block").
Then you should get something like:
BIP 34 (the BIP that specifies block version 2 and block heights in coinbases) is not activated on regtest and is never activated.
How do block versions work in regtest mode?
Block versions are actually version 0x20000000, not version 1. This version allows for other soft forks like BIPs 65 and 66 be activated. Some other forks (BIP16, CSV, and Segwit) ...
The functional tests test the RPCs. The unit tests test the C++ code directly by calling the functions.
The functional test frameworks uses a version of python-bitcoinrpc which can be found here. This library allows the test framework to call RPC commands as if they were python functions; authproxy handles the conversion to HTTP POST requests for the RPC ...