greg/nix-bitcoin
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
Fork of https://github.com/fort-nix/nix-bitcoin
343 Commits 8 Branches 0 Tags 4.1 MiB
Nix 84.4%
Shell 11.7%
Python 3.5%
C 0.4%
b5321cf939
Go to file
Jonas Nick b5321cf939
Merge #130: Improve banlist importer 
c36c496507 banlist: fail on unexpected errors (Erik Arvstedt)
e0276503ed fixup! ignore banlist errors (like in master) (Erik Arvstedt)
d64156e485 banlist: don't wait in preStart until bitcoind is ready (Erik Arvstedt)
d87c50a305 banlist: simplify unit, bind to bitcoind, fix wantedBy (Erik Arvstedt)
39885d37c1 banlist: simplify script, remove package (Erik Arvstedt)
55e73f32e3 bitcoind: add cli option (Erik Arvstedt)
8807b9f6b2 bitcoind: remove 'StateDirectory' (Erik Arvstedt)

Pull request description:

  Please see the individual commit messages for more infos.

  This time I've used commit msg titles starting with lower-case letters.
  I think this style is the simplest and cleanest, especially with
  `topic:` prefixes. Let me know if I should reformat this.

  Regarding commit `banlist: simplify script, remove package`:
  I've added the current version of Greg's banlist, but it has 5600 entries instead of the previous 739. Is this ok?

  Rationale for commit `bitcoind: add cli option`:
  For some cases it can be useful when bitcoin-cli is an executable instead of a shell alias.
    - non-interactive ssh commands like `ssh mynode 'bitcoin-cli getnetworkinfo'`.
      This can also be achieved with shell aliases in `environment.shellInit`, but it's good
      practice to avoid aliases in noninteractive shells.
    - Scripts that call `bitcoin-cli`. The banlist importer which uses this is a good example.

ACKs for top commit:
  jonasnick:
    ACK c36c496507

Tree-SHA512: 31dacf5e5b051ada24151c9884a97cfd83883c2b48e3d25e16f228fb575cb915e1093d12d171a44d25064fda7d7b98a27c897cc4bdace527c52fdf652033a160
2019-11-16 20:37:43 +00:00
docs Rename contrib/ to helper/ 2019-11-11 18:45:17 +01:00
helper Add content hashes for pinned channels 2019-11-11 18:45:17 +01:00
modules banlist: fail on unexpected errors 2019-11-14 13:06:21 +01:00
network Set default size of the virtualbox machine disk 2019-11-08 16:01:47 +01:00
pkgs banlist: simplify script, remove package 2019-11-12 19:42:33 +01:00
secrets Check for existing secrets and create them more granularly 2019-08-23 01:18:30 +02:00
.gitignore Add rpc user and password as secrets 2018-11-22 23:51:16 +00:00
.travis.yml Add liquid-swap tool to CI 2019-10-13 20:27:27 +00:00
configuration.nix Instruct user to backup channel.backup 2019-08-25 01:27:02 +02:00
default.nix banlist: simplify script, remove package 2019-11-12 19:42:33 +01:00
LICENSE Add license 2019-01-02 14:03:52 +00:00
overlay.nix Make repository importable as NUR (including an overlay) 2019-03-29 11:12:05 +01:00
README.md Mention problems with hardened kernel and NUCs in README 2019-08-19 20:51:46 +00:00
shell.nix Fix virtualbox deployment for 19.09 2019-11-10 21:06:17 +01:00

README.md

nix-bitcoin

Nix packages and nixos modules for easily installing Bitcoin nodes and higher layer protocols with an emphasis on security. This is a work in progress - don't expect it to be bug free or secure.

The default configuration sets up a Bitcoin Core node and c-lightning. The user can enable spark-wallet in configuration.nix to make c-lightning accessible with a smartphone using spark-wallet. A simple webpage shows the lightning nodeid and links to nanopos letting the user receive donations. It also includes elements-daemon. Outbound peer-to-peer traffic is forced through Tor, and listening services are bound to onion addresses.

A demo installation is running at http://6tr4dg3f2oa7slotdjp4syvnzzcry2lqqlcvqkfxdavxo6jsuxwqpxad.onion. The following screen cast shows a fresh deployment of a nix-bitcoin node.

The goal is to make it easy to deploy a reasonably secure Bitcoin node with a usable wallet. It should allow managing bitcoin (the currency) effectively and providing public infrastructure. It should be a reproducible and extensible platform for applications building on Bitcoin.

Available modules

By default the configuration.nix provides:

  • bitcoind with outbound connections through Tor and inbound connections through a hidden service. By default loaded with banlist of spy nodes.
  • clightning with outbound connections through Tor, not listening
  • includes "nodeinfo" script which prints basic info about the node
  • adds non-root user "operator" which has access to bitcoin-cli and lightning-cli

In configuration.nix the user can enable:

  • a clightning hidden service
  • liquid
  • lightning charge
  • nanopos
  • an index page using nginx to display node information and link to nanopos
  • spark-wallet
  • electrs
  • recurring-donations, a module to repeatedly send lightning payments to recipients specified in the configuration.
  • bitcoin-core-hwi.
    • You no longer need extra software to connect your hardware wallet to Bitcoin Core. Use Bitcoin Core's own Hardware Wallet Interface with one configuration.nix setting.

The data directories of the services can be found in /var/lib on the deployed machines.

Installation

The easiest way is to run nix-shell (on a Linux machine) in the nix-bitcoin directory and then create a NixOps deployment with the provided network.nix in the network directory. Fix the FIXMEs in configuration.nix and deploy with nixops in nix-shell. See install.md for a detailed tutorial.

Security

  • Simplicity: Only services you select in configuration.nix and their dependencies are installed, packages and dependencies are pinned, most packages are built from the nixos stable channel, with a few exceptions that are built from the nixpkgs unstable channel, builds happen in a sandboxed environment, code is continiously reviewed and refined.
  • Integrity: Nix package manager, NixOS and packages can be built from source to reduce reliance on binary caches, nix-bitcoin merge commits are signed, all commits are approved by multiple nix-bitcoin developers, upstream packages are cryptographically verified where possible, we use this software ourselves.
  • Principle of Least Privilege: Services operate with least privileges; they each have their own user and are restricted further with systemd options, there's a non-root user operator to interact with the various services.
  • Defense-in-depth: nix-bitcoin is built with a hardened kernel by default, services are confined through discretionary access control, Linux namespaces, and seccomp-bpf with continuous improvements.

Note that nix-bitcoin is still experimental. Also, by design if the machine you're deploying from is insecure, there is nothing nix-bitcoin can do to protect itself.

Hardware requirements

  • Disk space: 300 GB (235GB for Bitcoin blockchain + some room)
    • Bitcoin Core pruning is not supported at the moment because it's not supported by c-lightning. It's possible to use pruning but you need to know what you're doing.
  • RAM: 2GB of memory. ECC memory is better. Additionally, it's recommended to use DDR4 memory with targeted row refresh (TRR) enabled (https://rambleed.com/).

Tested hardware includes pcengine's apu2c4, GB-BACE-3150, GB-BACE-3160. Some hardware (including Intel NUCs) may not be compatible with the hardened kernel turned on by default (see https://github.com/fort-nix/nix-bitcoin/issues/39#issuecomment-517366093 for a workaround).

Usage

For usage instructions, such as how to connect to spark-wallet, electrs and the ssh Tor Hidden Service, see usage.md.

Troubleshooting

If you are having problems with nix-bitcoin check the FAQ or submit an issue. There's also a #nix-bitcoin IRC channel on freenode. We are always happy to help.

Docs