ZNHOO Whatever you are, be a good one!


  1. Bitcoin Core Installation
  2. Mode
  3. Configuration
  4. Daemon/server
  5. RPC
  6. Testing
    1. Info
    2. Block
    3. Mining
    4. Peer
    5. Transaction
      1. Examine transaction
      2. Confirm a transaction
    6. Stop daemon

This post only focuses only on Bitcoin daemon deployment on Linux. To get Bitcoin outline, concepts, principles, read NextCloud Note.

Bitcoin Core Installation

I choose to install daemon instead of QT GUI.

root@tux ~ / emerge -avt net-p2p/bitcoind net-p2p/bitcoin-cli
root@tux ~ / less /etc/{bitcoin/bitcoin.conf,init.d/bitcoind,conf.d/bitcoind}


  1. Full node (mainnet)

    A full node is a program that fully validates transactions and blocks. Running in full node comes with certain costs (i.e. harward requirements). To store the full blockchain, you need around 145 gigabytes of disk space, 2 gigabytes of RAM, broadband Internet etc.

    Mostly, you should keep your computer running at least 6 hours continuously without interruption.

  2. Prune mode (mainnet)

    Prune mode save diskpace by parameter --prune=<n> which prunes (delete) old blocks. By default, 0 disables pruning blocks; 1 allows manual pruning via RPC; >550 = automatically prune block files to stay under the specified target size in MiB.

  3. Testnet

    Unlike mainnet, the testnet is an alternative blockchain, only to be used to testing. Coins in testnet are separate and distinct from actual bitcoins, and are never supposed to have any value.

    This allows application developers or bitcoin testers to experiment, without having to use real bitcoins or worrying about breaking the main bitcoin chain. What is more, a raw recruit can play around with testnet and switch to real Bitcoin blockchain afterwards.

    The size of testnet blockchain is not trivial. As of January 2018, it is was 14GB, containing data for about 6 years worth of testnet activity.

    We can combine Testnet and Prune together.

  4. Regression Test Mode (Regtest)

    To further simplify the testing process, we can use local Regtest mode, where interaction with random peers and blocks is unnecessary or unwanted. It lets you instantly create a brand-new private block chain with the same basic rules as testnet — but one major difference: you choose when to create new blocks, so you have complete control over the environment. Unlike previous modes, block generation is pretty fast!


Default ports as of 0.16.0:

  mainnet testnet regtest
P2p 8333 18333 18444
RPC 8332 18332 18443

Here is a configration for Regtest mode:

# /etc/bitcoin/bitcoin.conf

# Mode


# Network











# Miscellanous

  1. prune and txindex are incompatible. Turn on prune in mainnet to save disk space.
  2. rpcauth is recommended over rpcuser/rpcpassword. It generates random password if we do not offer one.

    user@tux ~ # /path/to/rpcauth.py <username> [<password>]

    rpcauth is only used by server side. Please write down generated rpcpassword pair as it will be used by client side.

  3. Difference between addnode and connect.

    addnode adds a node to the list of nodes to connect while connect only connects to this very node, ignoring other nodes.

  4. connect= and proxy= will disable listen=1, rejecting incoming connections.
  5. We can connect the Bitcoin network through Tor. A bit further, we set local .onion address so that our own Bitcoin node is reachable through Tor.


root@tux ~ / rc-service bitcoind start
root@tux ~ / ss -npelt
root@tux ~ / ll /var/lib/bitcoin/.bitcoin/
root@tux ~ / gpasswd -a username bitcoin
  1. Bitcoin is running in daemon mode in the background.
  2. We should add username to bitcoin group, otherwise bitcoin_cli cannot run with username account.
  3. From /etc/init.d/bitcoind we find critical parameters are -conf and -datadir.

    Usually, we put -conf under -datadir.

  4. Bitcoin-qt disables -server by default and we can access to RPC through Help -> Debug window -> Console.


Unlike the server side, client side bitcoin_cli does not recognize rpcauth. To authenticate itself, bitcoin_cli read rpcpassword from configuration file or command line option.

# enable bitcoin group without re-login.
user@tux ~ # newgrp - bitcoin

We could tell it to share configuration with server:

user@tux ~ # bitcoin-cli -conf=/etc/bitcoin/bitcoin.conf [-rpcuser=user -rpcpassword=password] help
# generate bitcoin.conf symlink
user@tux ~ # mkdir -p ~/.bitcoin; ln -sv /etc/bitcoin/bitcoin.conf ~/.bitcoin/bitcoin.conf
user@tux ~ # bitcoin-cli [-rpcuser=user -rpcpassword=password] help

Alternatively, we set separate client configration file without symlink. You are recommended to use this method:

# ~/.bitcoin/bitcoin.conf


For client options, check man page.


In this section, I will discuss more Bitcoin details with Regtest mode.


user@tux ~ # bitcoin-cli help
user@tux ~ # bitcoin-cli help getblockchaininfo
user@tux ~ # bitcoin-cli getblockchaininfo | getwalletinfo | getnetworkinfo | getpeerinfo
user@tux ~ # bitcoin-cli logging "[\"all\"]"


user@tux ~ # bitcoin-cli getblockhash 50
user@tux ~ # bitcoin-cli getblock <returned hash> [0 | 1 | 2]

To examine a block information, we should first get its hash value. To get the block hash, we use height vlue which means distance from the genesis block.


Mining is just generating in Regtest mode.

user@tux ~ # bitcoin-cli generate 101
user@tux ~ # bitcoin-cli getbalance

A Regtest blockchain with 101 blocks is created, which takes less than a second. Each confirmed block reward is 50 bitcoins (no transaction fees). However, a block must have 100 confirmations before that reward can be spent, so we generate 101 blocks to get access to the coinbase transaction from block 1.

user@tux ~ # bitcoin-cli generate 1
user@tux ~ # bitcoin-cli getbalance


Thgough we use Regest locally, connecting to peer is necessary when you want to test transactions. To do this, we just file run another Regtest instance locally with different port, conf and datadir.

If you'd like, the extra Regtest instance could be moved into virtual machine as long as Hostonly network is correctly configured. Please be noted that, launch virtual machine before host Regtest instance which otherwise does not know about Hostonly interface IP.

In order that two nodes notice each other, we should use parameter addnode/connect or command line option thereof.

user@tux ~ # bitcoin-cli getaddednodeinfo | getpeerinfo


Once we have established connection to peers, we can send bitcoins around. Fristly, we should generate a new address to receive payments.

user@tux ~ # bitcoin-cli getnewaddress
user@tux ~ # bitcoin-cli listreceivedbyaddress 1 true

Send 10 bitcoins to the address using sendtoaddress RPC command which automatically selects an unspent transaction output (UTXO) from which to spend the satoshis. To check UTXO, we use listunspent.

user@tux ~ # bitcoin-cli getbalance
user@tux ~ # bitcoin-cli listunspent
user@tux ~ # bitcoin-cli sendtoaddress $NEW_ADDRESS 10.00 "first spending" "send to myself" true

Examine transaction

user@tux ~ # bitcoin-cli gettransaction <transaction hash returned> true
user@tux ~ # bitcoin-cli getrawtransaction <transaction hash returned> true
user@tux ~ # bitcoin-cli decoderawtransaction <hex string returned>
user@tux ~ # bitcoin-cli listunspent 0
user@tux ~ # bitcoin-cli listreceivedbyaddress 1 true
user@tux ~ # bitcoin-cli listtransactions "" 2

Confirm a transaction

Up to now, the transaction is not yet confirmed! We should mine 100 blocks to confirm it.

user@tux ~ # bitcoin-cli generate 100

If the input is from coinbase transaction, you can't spent it until it get 100 confirmations, avoiding blockchain fork issue. Hence, 1 confirmation is not enough!

Similary, we can send bitcoins the other Regtest node.

Stop daemon

We can stop the daemon:

user@tux ~ # bitcoin-cli stop

However, we'd better use OpenRC or Systemd service.