• Stars
    star
    351
  • Rank 117,159 (Top 3 %)
  • Language
    Dockerfile
  • License
    MIT License
  • Created almost 9 years ago
  • Updated 5 months ago

Reviews

There are no reviews yet. Be the first to send feedback to the community and the maintainers!

Repository Details

A bitcoin-core docker image

ruimarinho/bitcoin-core

A bitcoin-core docker image with support for the following platforms:

  • amd64 (x86_64)
  • arm32v7 (armv7)
  • arm64 (aarch64, armv8)

ruimarinho/bitcoin-core ruimarinho/bitcoin-core ruimarinho/bitcoin-core

Tags

Multi-architecture builds

The newest images (Debian-based, 0.19+) provide built-in support for multiple architectures. Running docker pull on any of the supported platforms will automatically choose the right image for you as all of the manifests and artifacts are pushed to the Docker registry.

Picking the right tag

  • ruimarinho/bitcoin-core:latest: points to the latest stable release available of Bitcoin Core. Caution when using in production as blindly upgrading Bitcoin Core is a risky procedure.
  • ruimarinho/bitcoin-core:alpine: same as above but using the Alpine Linux distribution (a resource efficient Linux distribution with security in mind, but not officially supported by the Bitcoin Core team β€” use at your own risk).
  • ruimarinho/bitcoin-core:<version>: based on a slim Debian image, this tag format points to a specific version branch (e.g. 0.20) or release of Bitcoin Core (e.g. 0.20.1). Uses the pre-compiled binaries which are distributed by the Bitcoin Core team.
  • ruimarinho/bitcoin-core:<version>-alpine: same as above but using the Alpine Linux distribution.

What is Bitcoin Core?

Bitcoin Core is a reference client that implements the Bitcoin protocol for remote procedure call (RPC) use. It is also the second Bitcoin client in the network's history. Learn more about Bitcoin Core on the Bitcoin Developer Reference docs.

Usage

How to use this image

This image contains the main binaries from the Bitcoin Core project - bitcoind, bitcoin-cli and bitcoin-tx. It behaves like a binary, so you can pass any arguments to the image and they will be forwarded to the bitcoind binary:

❯ docker run --rm -it ruimarinho/bitcoin-core \
  -printtoconsole \
  -regtest=1 \
  -rpcallowip=172.17.0.0/16 \
  -rpcauth='foo:7d9ba5ae63c3d4dc30583ff4fe65a67e$9e3634e81c11659e3de036d0bf88f89cd169c1039e6e09607562d54765c649cc'

Note: learn more about how -rpcauth works for remote authentication.

By default, bitcoind will run as user bitcoin in the group bitcoin for security reasons and with its default data dir set to ~/.bitcoin. If you'd like to customize where bitcoin-core stores its data, you must use the BITCOIN_DATA environment variable. The directory will be automatically created with the correct permissions for the bitcoin user and bitcoind automatically configured to use it.

❯ docker run --env BITCOIN_DATA=/var/lib/bitcoin-core --rm -it ruimarinho/bitcoin-core \
  -printtoconsole \
  -regtest=1

You can also mount a directory in a volume under /home/bitcoin/.bitcoin in case you want to access it on the host:

❯ docker run -v ${PWD}/data:/home/bitcoin/.bitcoin -it --rm ruimarinho/bitcoin-core \
  -printtoconsole \
  -regtest=1

You can optionally create a service using docker-compose:

bitcoin-core:
  image: ruimarinho/bitcoin-core
  command:
    -printtoconsole
    -regtest=1

Using a custom user id (UID) and group id (GID)

By default, images are created with a bitcoin user/group using a static UID/GID (101:101 on Debian and 100:101 on Alpine). You may customize the user and group ids using the build arguments UID (--build-arg UID=<uid>) and GID (--build-arg GID=<gid>).

If you'd like to use the pre-built images, uou can also customize the UID/GID on runtime via environment variables $UID and $GID:

❯ docker run -e UID=10000 -e GID=10000 -it --rm ruimarinho/bitcoin-core \
  -printtoconsole \
  -regtest=1

This will recursively change the ownership of the bitcoin home directory and $BITCOIN_DATA to UID/GID 10000:10000.

Using RPC to interact with the daemon

There are two communications methods to interact with a running Bitcoin Core daemon.

The first one is using a cookie-based local authentication. It doesn't require any special authentication information as running a process locally under the same user that was used to launch the Bitcoin Core daemon allows it to read the cookie file previously generated by the daemon for clients. The downside of this method is that it requires local machine access.

The second option is making a remote procedure call using a username and password combination. This has the advantage of not requiring local machine access, but in order to keep your credentials safe you should use the newer rpcauth authentication mechanism.

Using cookie-based local authentication

Start by launch the Bitcoin Core daemon:

❯ docker run --rm --name bitcoin-server -it ruimarinho/bitcoin-core \
  -printtoconsole \
  -regtest=1

Then, inside the running bitcoin-server container, locally execute the query to the daemon using bitcoin-cli:

❯ docker exec --user bitcoin bitcoin-server bitcoin-cli -regtest getmininginfo

{
  "blocks": 0,
  "currentblocksize": 0,
  "currentblockweight": 0,
  "currentblocktx": 0,
  "difficulty": 4.656542373906925e-10,
  "errors": "",
  "networkhashps": 0,
  "pooledtx": 0,
  "chain": "regtest"
}

In the background, bitcoin-cli read the information automatically from /home/bitcoin/.bitcoin/regtest/.cookie. In production, the path would not contain the regtest part.

Using rpcauth for remote authentication

Before setting up remote authentication, you will need to generate the rpcauth line that will hold the credentials for the Bitcoind Core daemon. You can either do this yourself by constructing the line with the format <user>:<salt>$<hash> or use the official rpcauth.py script to generate this line for you, including a random password that is printed to the console.

Note: This is a Python 3 script. use [...] | python3 - <username> when executing on macOS.

Example:

❯ curl -sSL https://raw.githubusercontent.com/bitcoin/bitcoin/master/share/rpcauth/rpcauth.py | python - <username>

String to be appended to bitcoin.conf:
rpcauth=foo:7d9ba5ae63c3d4dc30583ff4fe65a67e$9e3634e81c11659e3de036d0bf88f89cd169c1039e6e09607562d54765c649cc
Your password:
qDDZdeQ5vw9XXFeVnXT4PZ--tGN2xNjjR4nrtyszZx0=

Note that for each run, even if the username remains the same, the output will be always different as a new salt and password are generated.

Now that you have your credentials, you need to start the Bitcoin Core daemon with the -rpcauth option. Alternatively, you could append the line to a bitcoin.conf file and mount it on the container.

Let's opt for the Docker way:

❯ docker run --rm --name bitcoin-server -it ruimarinho/bitcoin-core \
  -printtoconsole \
  -regtest=1 \
  -rpcallowip=172.17.0.0/16 \
  -rpcauth='foo:7d9ba5ae63c3d4dc30583ff4fe65a67e$9e3634e81c11659e3de036d0bf88f89cd169c1039e6e09607562d54765c649cc'

Two important notes:

  1. Some shells require escaping the rpcauth line (e.g. zsh), as shown above.
  2. It is now perfectly fine to pass the rpcauth line as a command line argument. Unlike -rpcpassword, the content is hashed so even if the arguments would be exposed, they would not allow the attacker to get the actual password.

You can now connect via bitcoin-cli or any other compatible client. You will still have to define a username and password when connecting to the Bitcoin Core RPC server.

To avoid any confusion about whether or not a remote call is being made, let's spin up another container to execute bitcoin-cli and connect it via the Docker network using the password generated above:

❯ docker run -it --link bitcoin-server --rm ruimarinho/bitcoin-core \
  bitcoin-cli \
  -rpcconnect=bitcoin-server \
  -regtest \
  -rpcuser=foo\
  -stdinrpcpass \
  getbalance

Enter the password qDDZdeQ5vw9XXFeVnXT4PZ--tGN2xNjjR4nrtyszZx0= and hit enter:

0.00000000

Note: under Bitcoin Core < 0.16, use -rpcpassword="qDDZdeQ5vw9XXFeVnXT4PZ--tGN2xNjjR4nrtyszZx0=" instead of -stdinrpcpass.

Done!

Exposing Ports

Depending on the network (mode) the Bitcoin Core daemon is running as well as the chosen runtime flags, several default ports may be available for mapping.

Ports can be exposed by mapping all of the available ones (using -P and based on what EXPOSE documents) or individually by adding -p. This mode allows assigning a dynamic port on the host (-p <port>) or assigning a fixed port -p <hostPort>:<containerPort>.

Example for running a node in regtest mode mapping JSON-RPC/REST (18443) and P2P (18444) ports:

docker run --rm -it \
  -p 18443:18443 \
  -p 18444:18444 \
  ruimarinho/bitcoin-core \
  -printtoconsole \
  -regtest=1 \
  -rpcallowip=172.17.0.0/16 \
  -rpcbind=0.0.0.0 \
  -rpcauth='foo:7d9ba5ae63c3d4dc30583ff4fe65a67e$9e3634e81c11659e3de036d0bf88f89cd169c1039e6e09607562d54765c649cc'

To test that mapping worked, you can send a JSON-RPC curl request to the host port:

curl --data-binary '{"jsonrpc":"1.0","id":"1","method":"getnetworkinfo","params":[]}' http://foo:[email protected]:18443/

Mainnet

  • JSON-RPC/REST: 8332
  • P2P: 8333

Testnet

  • Testnet JSON-RPC: 18332
  • P2P: 18333

Regtest

  • JSON-RPC/REST: 18443 (since 0.16+, otherwise 18332)
  • P2P: 18444

Signet

  • JSON-RPC/REST: 38332
  • P2P: 38333

Archived tags

Please note that due to CVE-2018-17144, the following tags are unavailable: 0.14.0, 0.14.1, 0.14.2, 0.15.0, 0.15.0.1, 0.15.1, 0.16.0, 0.16.1 and 0.16.2.

For historical reasons, the following tags are still available and automatically updated when the underlying base image (Alpine Linux or Debian stable) is updated as well:

Docker

This image is officially supported on Docker version 17.09, with support for older versions provided on a best-effort basis.

License

License information for the software contained in this image.

License information for the ruimarinho/docker-bitcoin-core docker project.

More Repositories

1

google-libphonenumber

The up-to-date and reliable Google's libphonenumber package for node.js.
JavaScript
1,337
star
2

bitcoin-core

A modern Bitcoin Core REST and RPC client.
JavaScript
465
star
3

yubikey-handbook

A collection of guidelines, use cases and experiments with the Yubikey
333
star
4

gsts

Obtain and store AWS STS credentials to interact with Amazon services by authenticating via G Suite SAML.
JavaScript
200
star
5

authy-client

A complete Authy client with support for TOTP, OneTouch, Phone Verification and Phone Intelligence APIs
JavaScript
121
star
6

docker-openvpn-monitor

The trusted multi-platform web-based OpenVPN Monitor docker image.
Dockerfile
98
star
7

little-snitch-rules

Rule groups for easy subscriptions for Little Snitch 4.1+
55
star
8

sql-tag

A template tag for writing elegant parameterized SQL queries based on ES2015 tagged template literals
JavaScript
36
star
9

iterm2-city-lights

A City Lights theme for iTerm2 with focus in mind using a gorgeous dark atmosphere.
34
star
10

mota

A Shelly device firmware updater based on zeroconf (or bonjour) discovery for local networks using their built-in Over-The-Air update interface. It is suited for network setups where IoT devices do not have internet connectivity.
Go
31
star
11

url-escape-tag

A template tag for escaping url parameters based on ES2015 tagged templates
JavaScript
14
star
12

docker-openzwave

An OpenZWave docker image with the OpenZWave Control Panel built-in.
Dockerfile
11
star
13

home-assistant-config

πŸ”§πŸ‘ My home automation configuration for Home Assistant
8
star
14

docker-z-way

A Z-Way server docker image.
Dockerfile
7
star
15

docker-miflora-mqtt

Run the miflora-mqtt-daemon in Docker using dynamic environment variables (x86 + ARM support).
Dockerfile
6
star
16

karma-should

Use should.js with karma tests
JavaScript
5
star
17

atlas-scientific-ph-probe-calibration-esp8266

An ESP8266 program for calibrating Atlas Scientific pH Probes interactively
C++
4
star
18

home-assistant-mosquitto-config

πŸ”§ 🐞 A mosquitto config for integrating with Home Assistant's MQTT component.
4
star
19

docker-mosquitto

A mosquitto docker image.
Shell
4
star
20

dotfiles

dotfiles that give your computer personality.
Shell
2
star
21

defaults-deep-safe

A deep version of _.defaults, safe by default
JavaScript
2
star
22

co-authy

[DEPRECATED] An Authy client based on generators
JavaScript
2
star
23

package-list

A thin wrapper around npm to list installed packages during runtime.
JavaScript
1
star
24

educabiz-gallery-downloader

Automate photo gallery downloads on the Educabiz platform
JavaScript
1
star
25

isoc

A list of country names and codes as published by the ISO 3166-1 standard
JavaScript
1
star
26

macOS-scripts

A collection of AppleScripts to automate tasks in different macOS applications.
AppleScript
1
star
27

libphonenumber-hook

πŸ’†β€β™‚οΈA companion serverless function for automatically keeping google-libphonenumber up-to-date with the latest upstream releases.
Go
1
star
28

nsq-dogstatsd

An utility that lets you graph nsq stats on Datadog by sending custom metrics via DogStatsD
Go
1
star
29

homebrew-tap

🍻 Homebrew tap for some of my open source projects
Ruby
1
star
30

brother-mobile-cable-label-downloader

Use industrial-grade telecom, datacom and/or electrical identifications on your consumer-grade Brother label printer.
JavaScript
1
star
31

sequelize-sql-tag

A template tag for writing elegant parameterized SQL queries based on ES2015 tagged template literals using Sequelize
JavaScript
1
star