Public | Automated Build

Last pushed: 2 years ago
Short Description
A customised version of bititcoind that swaps proof-of-work consensus for central party trust.
Full Description


A customised version of bitcoind that swaps proof-of-work consensus for central party trust.

Getting started

Setting up your client

Using docker run the client (the following assumes that you are using Docker Machine on Windows.) -

docker run -d --name scottcoin scottcoin/scottcoin

This will start the client in the background. Now it is running you can interact with it -

docker exec scottcoin bitcoin-cli getinfo

This will return a JSON object with useful information about the network, including the balance in your wallet!

Before sending or receiving any Scottcoins, you must encrypt your wallet with a unique passphrase. Without this anyone with access to your wallet file can spend your Scottcoins. By adding a passphrase someone will need both the wallet and the passphrase to spend anything. N.B. This clears your wallet balance, so do this before you receive any Scottcoins!

docker exec scottcoin bitcoin-cli encryptwallet <passphrase>

As part of the encryption process, the client will terminate so you'll need to restart it -

docker start scottcoin

N.B. Your wallet is stored in a docker volume called /home/scottcoin/.bitcoin, make sure to retain this volume if you remove the container or delete the Docker Machine VM.

Sending and receiving Scottcoins

Before sending/receiving, let's check what your balance is -

docker exec scottcoin bitcoin-cli getbalance

When money is sent or received transactions are not confirmed immediately, there can be a lag of up to 10 minutes (whilst a block containing your transaction is mined). If you want to see the current unconfirmed balance of your wallet use this command -

docker exec scottcoin bitcoin-cli getunconfirmedbalance

To send Scottcoins to any address -

docker exec scottcoin bitcoin-cli sendtoaddress <address> <amount>

You should find that you get an error -

error: {"code":-13,"message":"Error: Please enter the wallet passphrase with walletpassphrase first."}

This happened because you've not yet entered your wallet passphrase (see above). To interact with the wallet you need to unlock it for a period of time -

docker exec scottcoin bitcoin-cli walletpassphrase <passphrase> 5

To receive Scottcoins, you'll need to generate a one-time address for use by the sending party -

docker exec scottcoin bitcoin-cli getnewaddress

Stopping and starting the server

To stop the server -

docker exec scottcoin bitcoin-cli stop

To start it again -

docker start scottcoin

Project description

Changes from Bitcoin

This project is a modified version of bitcoind that swaps proof-of-work consensus for central party trust. In Bitcoin proof of work allows the network of nodes to reach a consensus on the history of all transactions (the distributed ledger or blockchain) without having any trust in each other. You can read more about that here but for now it is enough to know that this proof of work consensus is phenomenally computationally expensive.

To avoid this computational cost, the Scottcoin network instead relies on a central trusted party to dictate the history of transactions. The technical details of how this is achieved can be found below. It should be noted that in many (every?!) way this errodes the point of bitcoin, a simple database table could achieve much the same result. However, the intention of the project is not to replace bitcoin but to provide a platform on which to increase the understanding of blockchain technologies within the company. To that end, the Scottcoin network succeeds in re-using the fundamental moving parts of the Bitcoin network in a pragmatic way.

In Scottcoin the central mining server creates blocks containing an additional scottsig header field. This field contains an ECDSA signature based on a secret private key. All nodes in the network are configured to validate this header using the public key which is distributed via a back-channel. This means that only one "minting server" can generate valid blocks. All other nodes on the network act as relay nodes, able to send and receive scottcoins, but not mine new blocks.

These changes mean the Bitcoin binary protocol, which is the network protocol used between nodes has been modified to send/receive the new field.

Structure of Scottcoin

Scottcoin is packaged into a Docker image as seen in the diagram below. It contains both our modified bitcoind, as well as the command line interface bitcoin-cli.

There are several environment variables visible in the diagram, all of which have sensible default values but can be configured if required.

Three variables are required to connect the bitcoin-cli to the bitcoind node using the JSON-RPC interface -

  • RPC_USER=scottcoin

  • RPC_PASS=password

  • RPC_PORT=8101

The node needs to know the URL of the network's public key -


Address seeds (addnode) and direct connections (connect) can be used to specify locations of other nodes (e.g. the minting server) -


The behaviour of these flags is documented on the bitcoin wiki.

Command Line Interface

Bitcoin (and by extension Scottcoin) contains an JSON-RPC interface which allows for wallet, transaction and blockchain operations. In scottcoin, RPC listens on port 8101 and it is a standard HTTP service.

An example cURL command would be something like this -

docker exec scottcoin curl --user user --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getinfo", "params": [] }' -H 'content-type: text/plain;' localhost:8101

This is the command for a basic getinfo request, which is relatively long-winded and requires a password input after every command. To simplify the commands, included in Bitcoin is a command line interface (CLI) to control many of the functions of running a Bitcoin node. This CLI uses the parameters of the bitcoin.conf to save manual input, thus limiting the only typed parameters to the functions themselves. For example, the equivalent to the above cURL command would be -

docker exec scottcoin bitcoin-cli getinfo

Both commands would return a JSON object such as the one below -

    "version" : 110200,
    "protocolversion" : 70002,
    "walletversion" : 60000,
    "balance" : 0.00000000,
    "blocks" : 11,
    "timeoffset" : 0,
    "connections" : 1,
    "proxy" : "",
    "difficulty" : 0.00000000,
    "testnet" : false,
    "keypoololdest" : 1457542478,
    "keypoolsize" : 101,
    "paytxfee" : 0.00000000,
    "relayfee" : 0.00005000,
    "errors" : ""

For a full list of all the commands in the CLI use the following -

docker exec scottcoin bitcoin-cli help

Running the minting node

If you want to run your own Scottcoin network, you can create a minting node with a private and public keypair N.B. This will create a separate network! This will not be compatible with the existing Scottcoin network due to having different private and public keys.

To generate a keypair on Linux use -


On Windows you need to run this command from within a scottcoin container by either starting a container in bash -

docker run -it --entrypoint=/bin/bash scottcoin/scottcoin

or by opening the bash terminal for an already running scottcoin container -

docker exec -it <container-name> bash

This creates and ecdsa.priv. The contents of need to be hosted on a public server whilst the ecdsa.priv needs to be placed in the root of the volume you mount at /home/scottcoin/.bitcoin (detailed below).

In order to keep your own Scottcoin network isolated you'll need to consistently override several environment variables on each node.

  • CERTIFICATE_URL should be included on every node and points to the server hosting the public key.

  • ADDRESS_SEED should be included as blank on a mint (or relay) node in order to isolate. On a client node it should contain the url of the mint (or relay if you have one).

  • CONNECT_TO is used only on the minting node in order to connect it directly to the relay, if you have one.

These environment variables will be omitted from the following code snippets to keep them to a readable length. However they should be included (where appropriate) following a -e flag.

Setting up a minting server is similar to creating a client node, but you need some extra flags in the docker run command -

docker run -d --name scottcoin-signing -v scottcoin:/home/scottcoin/.bitcoin -e CERTIFICATE_POLL_DELAY=<Number> scottcoin/scottcoin
  • -v scottcoin:/home/scottcoin/.bitcoin - mount a volume named "scottcoin" at /home/scottcoin/.bitcoin. The "scottcoin" volume should already contain the ecdsa.priv in its root directory.

  • -e CERTIFICATE_POLL_DELAY=<Number> - The frequency at which blocks are created, the default is 10 minutes but can be changed if necessary.

For additional security, it is recommended that you run a "relay" node to separate the minting node from the client nodes. To start a relay:

docker run -d --name scottcoin -p 8100:8100 scottcoin/scottcoin

where the -p 8100:8100 exposes a port for the client nodes to connect to via ADDRESS_SEED and the minting node to connect to via CONNECT_TO.

To introduce coins into the network -

docker exec scottcoin-signing bitcoin-cli generate <N>
docker exec scottcoin-signing bitcoin-cli sendtoaddress <address> <N>

Where N is the number of coins you wish to mint. Our modified bitcoind has its block reward set to 1, meaning one block gives a single coin as mining reward. If you wish to take coins out of circulation, they can be "burnt" -

docker exec scottcoin-signing bitcoin-cli sendtoaddress <burn address> <coin amount>

Where a burn address such as 1111111111111111111114oLvT2 may be used.

The Scottcoin network uses the above burn address to burn reward-coins when blocks have been generated. This can be modified by passing -e BURN_ADDRESS=... to your docker run command.

You may notice the following error at the beginning of your minting server's logs -

error: {"code":-6,"message":"Insufficient funds"}

This is because when a server is first started, we attempt to burn generated coins immediately. We can't because we only have one block containing coins that aren't mature enough to spend. After this, you should find that you can generate blocks and burn/spend without error.

Ready made test network

A ready-made self-contained network for testing purposes can be launched from the test directory using docker-compose.

Docker Pull Command
Source Repository