We accept payment in bitcoin: Part Three, our testnet. With blackjack

In the last article, I told you how to install bitcoind (at least on Ubuntu Linux) and how to connect to testnet. But testnet is a good solution when you conduct tests on a ready-made website that has already been deployed on a server on the Internet. But for local development this is far from the most convenient solution.

You can read the first parts here and here.

And here we will need the third operating mode of bitcoind -regtest (Regression Test Mode). By Essentially, it’s your own small, pocket-sized bitcoin. With few exceptions, the behavior of the software will be fully correspond to the combat one. But, firstly, you do not need to download the blockchain (even the test one, much more compact). Further, by and large, you don’t even need an Internet connection; all operations will happen entirely locally.  

We will need bitcoind installed, which is logical, and a little patience. You need to run at least 2 copies of bitcoind so that they interact with each other, simulating network operation. And finally, we will need to do mining. But don't be alarmed, in the case of Regression Test the difficulty is automatically set to zero and we will not need megawatts of energy and a farm of the latest generation ASICs. 

To begin with, let's create 2 directories in which data, configuration files and debug logs will be stored. In all In the examples I will use /home/developer as the root path. So, run the commands below:

mkdir -p /home/developer/bitcoin-service
mkdir -p /home/developer/bitcoin-client

Names bitcoin-service and bitcoin-client are taken just for convenience. You can even call them MYCOOLBITCOINNET - the main thing is mandatory use them in all further actions.

For now we will assume that bitcoin-client is a certain “client” who will pay us something during tests, and bitcoin-service is, accordingly, our “store”, then Yes, he will accept payment.

Now we need to create files in each of the created directories bitcoin.conf with the following content:

# As with s testnet, we need to enable interaction with the daemon.
# The option below allows bitcoind to listen on the JSON-RPC port
server=1
rpcuser=username
rpcpassword=userpassword
# specify the RPC port.. It should be different for each service!
# By default this is port 8332, but I highly recommend using other values
rpcport=18332
# Specify the operating mode - Regression Test Mode
regtest=1
# I will describe the following parameters later, it is only important that they are also different
port=18333
addnode=localhost:28333
# And in these places we need to specify bitcoin-service and bitcoin-client, respectively.
datadir=/home/developer/bitcoin-service
pid=/home/developer/bitcoin-service/.pid

Now a few words about ports. The rpcport parameter specifies which The port will be listening for RPC connections. In addition to what logic dictates - different demons should have be different ports, running two on the same port simply won’t work technically. This makes it easier for convenience In total, indicate for example 18332 for the first and 28332 for the second.  

Now a few words about the port and addnode. The first one - port - specifies which port the daemon will listen on while waiting for network connections from other demons - we remember, bitcoin is a p2p network. It should also be different for different running demons. A the addnode parameter, in turn, tells which connections will be established immediately after the daemon starts. In combat networks and testnet networks this is implemented by a special node search mechanism. And since we launch the demons in full local mode, this mechanism will not help us in any way. 

Therefore we will have to specify connections in the file configurations. Therefore, if for bitcoin-service we specified port 18333 and for bitcoin-client 28333, then the parameter addnode will look like this for bitcoin-service localhost:28333, and localhost:18333 for bitcoin-client.

Something like this:

#/home/developer/bitcoin-service/bitcoin.conf:
port=18333
addnode=localhost:28333
#/home/developer/bitcoin-client/bitcoin.conf:
port=28333
addnode=localhost:18333

And, of course, the datadir and pid parameters must point to the corresponding directories:

#/home/developer/bitcoin-service/bitcoin.conf:
datadir=/home/developer/bitcoin-service
pid=/home/developer/bitcoin-service/.pid

#/home/developer/bitcoin-client/bitcoin.conf:
datadir=/home/developer/bitcoin-client
pid=/home/developer/bitcoin-client/.pid

The first of them, datadir, says where a copy of our test blockchain, debug logs and other useful and not so useful information related to life activities bitocoind, and the second, let’s say, helps the daemon not get lost among a bunch of other processes in the system. 

Now we can finally launch our testnet and enjoy our personal bitcoin.. To do this we need to execute commands, it is important to run them in different terminal windows:

bitcoind -conf=/home/developer/bitcoin-service/bitcoin.conf --printtoconsole
bitcoind -conf=/home/developer/bitcoin-client/bitcoin.conf --printtoconsole

The -conf=... parameter specifies which configuration file we want to use, and --printtoconsole says that we will use all debugging information watch on the screen, without having to monitor the logs. Usually this is not necessary, but when you first start It's better to make sure everything is done correctly. If among the incomprehensible letters and numbers there is no terrible word Error - this means we can assume that everything went well, and our local bitcoin network is working and we can move on to next steps.

If in the case of a combat network and testnet, calling the daemon is quite simple: bitcoin-cli [command], then under the hood something like this happens: bitcoin-cli checks the default path, according to which usually contains the configuration file. For Linux this will be $HOME/.bitcoin/bitcoin.conf, and gets from it connection parameters are the same rpcport, rpcuser and rpcpassword. And already using them, connects to bitcoind for execution of the command. However, not only do we now have configuration files located in places other than standard, and also 2 copies of bitcoind are running simultaneously. The logical question that arises is how can we connect to the one we are interested in and execute the command on it? 

There are several options. First, you can specify connection parameters on the command line:

bitcoin-cli -rpcuser=username -rpcpassword=userpassword -rpcport=18332 getwalletinfo

This, of course, is suitable for a one-time check, but It is not very convenient to use such a design all the time. Well, to understand who we connected to, only by the address port - too risky. 

Second option, more readable:

bitcoin-cli -conf=/home/developer/bitcoin-service/bitcoin.conf getwalletinfo

Here we indicate the location configuration file from which the connection parameters will be taken. Also bulky, but a little more convenient. 

Well, the third option is to write a couple of bash scripts that will substitute all the parameters we need, and then with their help contact demons. Create a file for example bitcoin-service.sh:

#!/usr/bin/env bash
echo "Bitcoin SERVICE node:"
bitcoin-cli -conf=/home/developer/bitcoin-service/bitcoin.conf $@

And allow its execution:

chmod +x bitcoin-service..sh

The same file should be made for the second one demon, logically calling it bitcoin-client.sh. Now we can execute any command simply by typing:

./bitcoin-service.sh getwalletinfo

It's a shame, but the balance of our wallet is 0.0 BTC, this can be seen from the line "balance": 0.00000000. It's time to fix it:

./bitcoin-service.sh generate 1000

This command will make us fabulously rich. It forces bitcoind to generate 1000 new blocks, with the corresponding reward for mining. As a result, for example, I was able to quickly mine 14716.40625000.

Now we can stop our test bitcoin daemons and run them in a more convenient mode:

bitcoind -conf=/home/developer/bitcoin-service/bitcoin.conf --daemon

bitcoind -conf=/home/developer/bitcoin-client/bitcoin.conf --daemon

The daemons will run in the background, not displaying tons of useless information on the screen. 

Now we can transfer coins from one demon to another. Let's get the bitcoin address:

./bitcoin-client.sh getnewaddress
Bitcoin CLIENT node:
2Mw8q4gVeyb7kTGmGNmyVqRp4yaNCF6Niw6

#And now let’s send some test coins:
./bitcoin-service.sh sendtoaddress 2Mw8q4gVeyb7kTGmGNmyVqRp4yaNCF6Niw6 500
Bitcoin SERVICE node:
eec8a8efdd40d21564de027b8c9fa97b2abfb35befa5cd543f8be1f16016ef8f

We received the transaction number, that means everything went well. Let's check what we got:

./bitcoin-client.sh getwalletinfo

And here a not very pleasant surprise awaits us, the balance is still equal to 0. And this happens because our new transaction is not included in the block, and accordingly is not confirmed. But in the line “unconfirmed_balance” we see 500.00000000. Well, it’s okay, we already know how to mine.

# One block will be enough for now
./bitcoin-client.sh generate 1

At this point the preparation can be considered complete, and I would finally like to obtain some more practically valuable result. 

In the following articles I will discuss how we can use the resulting test system for development, and we will finally move on to the actual implementation of the payment gateway.