fort-nix/nix-bitcoin

A collection of Nix packages and NixOS modules for easily installing full-featured Bitcoin nodes with an emphasis on security.

nix-bitcoin is a collection of Nix packages and NixOS modules for easily installing full-featured Bitcoin nodes with an emphasis on security.

Overview

nix-bitcoin can be used for personal or merchant wallets, public infrastructure or for Bitcoin application backends. In all cases, the aim is to provide security and privacy by default. However, while nix-bitcoin is used in production today, it is still considered experimental.

nix-bitcoin nodes can be deployed on dedicated hardware, virtual machines or containers. The Nix packages and NixOS modules can be used independently and combined freely.

nix-bitcoin is built on top of Nix and NixOS which provide powerful abstractions to keep it highly customizable and maintainable. Testament to this are nix-bitcoin's robust security features and its potent test framework. However, running nix-bitcoin does not require any previous experience with the Nix ecosystem.

Get started

• See the examples for an overview of all features.
• To setup a new node from scratch, see the installation instructions.
• To add nix-bitcoin to an existing NixOS configuration, see importable-configuration.nix and the Flake example.

Docs

Hint: To show a table of contents, click the button () in the top left corner of the documents.

• NixOS options search
• Hardware requirements
• Installation
• Configuration and maintenance
• Using services
• FAQ

Features

A configuration preset for setting up a secure node

• All applications use Tor for outbound connections and support accepting inbound connections via onion services.

NixOS modules (src)

• Application services
  • bitcoind
  • clightning with support for announcing an onion service and database replication.
    Available plugins:
    • clboss: automated C-Lightning Node Manager
    • currencyrate: currency converter
    • monitor: helps you analyze the health of your peers and channels
    • rebalance: keeps your channels balanced
    • trustedcoin (experimental): replaces bitcoind with trusted public explorers
    • zmq: publishes notifications via ZeroMQ to configured endpoints
  • clightning-rest: REST server for clightning
  • lnd with support for announcing an onion service and static channel backups
    • Lightning Loop
    • Lightning Pool
    • charge-lnd: policy-based channel fee manager
  • lndconnect: connect your wallet to lnd or clightning via WireGuard or Tor
  • Ride The Lightning: web interface for lnd and clightning
  • mempool: Bitcoin visualizer, explorer, and API service
  • electrs: Electrum server
  • fulcrum: Electrum server (see the module for a comparison with electrs)
  • btcpayserver
  • liquid: federated sidechain
  • JoinMarket
    • JoinMarket Orderbook Watcher
  • bitcoin-core-hwi
• Helper
  • netns-isolation: isolates applications on the network-level via network namespaces
  • nodeinfo: script which prints info about the node's services
  • backups: duplicity backups of all your node's important files
  • operator: configures a non-root user who has access to client tools (e.g. bitcoin-cli, lightning-cli)

Security

See SECURITY.md for the security policy and how to report a vulnerability.

nix-bitcoin aims to achieve a high degree of security by building on the following principles:

• Simplicity: Only services enabled in configuration.nix and their dependencies are installed, support for doas (sudo alternative), code is continuously reviewed and refined.
• Integrity: The Nix package manager guarantees that all dependencies are exactly specified, 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 features, RPC whitelisting and netns-isolation. There's a non-root user operator to interact with the various services.
• Defense-in-depth: nix-bitcoin supports a hardened kernel, services are confined through discretionary access control, Linux namespaces, dbus firewall and seccomp-bpf with continuous improvements.

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

Security fund

The nix-bitcoin security fund is a 2 of 3 bitcoin multisig address open for donations, used to reward security researchers who discover vulnerabilities in nix-bitcoin or its upstream dependencies.
See Security Fund for details.

Developing

See dev/README.

Troubleshooting

If you are having problems with nix-bitcoin check the FAQ or submit an issue.
There's also a Matrix room at #general:nixbitcoin.org and a #nix-bitcoin IRC channel on libera.
We are always happy to help.

nix-bitcoin's Issues

Limit syscalls

Time Horizon: Short term

Description: Limit system calls to further restrict services.

Motivation: Continuation of our hardening efforts.

Implementation: Use systemd's SYSTEM CALL FILTERING and Docker's default syscall whitelist.

Fix spark-wallet price lookup

Spark-wallet with nix-bitcoin-services.allowTor doesn't allow looking up price. Using torsocks to wrap the price request gives an error. Should be fixed ASAP if we merge #52 before.

Upstream issue: shesek/spark-wallet#78

Broken Travis integration

Travis still runs PR jobs, but they aren't shown anymore in Github's PR views, like here.

@nixbitcoin, the breakage coincided with your recent contributions and the new PR labeling automation. Did you change anything?

Improve iOS users' lives

Sadly, the experience on iOS is deplorable. I can run Spark Wallet with Onion Browser, but even that is frustrating because WebRTC doesn't work. Even if Spark Wallet would work flawlessly, it seems to me that it doesn't actually allow users to transfer funds on-chain, only off-chain. In consequence, iOS users have no option to send funds on-chain from their phones using their nix-bitcoin node.

I think that this can be mitigated by adding support to run lnd on clearnet in nix-bitcoin, in parallel or as an alternative to clightning. Sadly, it must be in clearnet as there is not any alternative to Orbot on iOS and it might not ever be one because... Apple. iOS users would then be able to use Zap for both on-chain and off-chain transfers with their nix-bitcoin node.

Failed deploy at Bitcoin daemon banlist importer

After modifying the dbcache in modules/nix-bitcoin.nix
from services.bitcoind.dbCache = 4000;
to services.bitcoind.dbCache = 6000;

nixops deploy -d bitcoin-node fails:

[nix-shell:~/nix-bitcoin]$ nixops deploy -d bitcoin-node
building all machine configurations...
bitcoin-node> copying closure...
bitcoin-node> closures copied successfully
bitcoin-node> uploading key ‘bitcoin-rpcpassword’...
bitcoin-node> uploading key ‘spark-wallet-login’...
bitcoin-node> uploading key ‘liquid-rpcpassword’...
bitcoin-node> updating GRUB 2 menu...
bitcoin-node> activating the configuration...
bitcoin-node> setting up /etc...
bitcoin-node> reloading user units for root...
bitcoin-node> setting up tmpfiles
bitcoin-node> warning: the following units failed: bitcoind-import-banlist.service
bitcoin-node> 
bitcoin-node> ● bitcoind-import-banlist.service - Bitcoin daemon banlist importer
bitcoin-node>    Loaded: loaded (/nix/store/8wghr967ycyxj868z3q3slljw1nm7a1g-unit-bitcoind-import-banlist.service/bitcoind-import-banlist.service; enabled; vendor preset: enabled)
bitcoin-node>    Active: failed (Result: timeout) since Thu 2019-10-10 16:43:50 UTC; 2s ago
bitcoin-node>   Process: 10606 ExecStartPre=/nix/store/b3hj3cmsdr7fz1vjrn594zg7m0syq9nv-unit-script-bitcoind-import-banlist-pre-start (code=killed, signal=TERM)
bitcoin-node>  Main PID: 15858 (code=exited, status=0/SUCCESS)
bitcoin-node> 
bitcoin-node> Oct 10 16:43:47 cube-nix-bitcoin b3hj3cmsdr7fz1vjrn594zg7m0syq9nv-unit-script-bitcoind-import-banlist-pre-start[10606]: Loading block index...
bitcoin-node> Oct 10 16:43:48 cube-nix-bitcoin b3hj3cmsdr7fz1vjrn594zg7m0syq9nv-unit-script-bitcoind-import-banlist-pre-start[10606]: error code: -28
bitcoin-node> Oct 10 16:43:48 cube-nix-bitcoin b3hj3cmsdr7fz1vjrn594zg7m0syq9nv-unit-script-bitcoind-import-banlist-pre-start[10606]: error message:
bitcoin-node> Oct 10 16:43:48 cube-nix-bitcoin b3hj3cmsdr7fz1vjrn594zg7m0syq9nv-unit-script-bitcoind-import-banlist-pre-start[10606]: Loading block index...
bitcoin-node> Oct 10 16:43:50 cube-nix-bitcoin b3hj3cmsdr7fz1vjrn594zg7m0syq9nv-unit-script-bitcoind-import-banlist-pre-start[10606]: error code: -28
bitcoin-node> Oct 10 16:43:50 cube-nix-bitcoin b3hj3cmsdr7fz1vjrn594zg7m0syq9nv-unit-script-bitcoind-import-banlist-pre-start[10606]: error message:
bitcoin-node> Oct 10 16:43:50 cube-nix-bitcoin b3hj3cmsdr7fz1vjrn594zg7m0syq9nv-unit-script-bitcoind-import-banlist-pre-start[10606]: Loading block index...
bitcoin-node> Oct 10 16:43:50 cube-nix-bitcoin systemd[1]: bitcoind-import-banlist.service: Start-pre operation timed out. Terminating.
bitcoin-node> Oct 10 16:43:50 cube-nix-bitcoin systemd[1]: bitcoind-import-banlist.service: Failed with result 'timeout'.
bitcoin-node> Oct 10 16:43:50 cube-nix-bitcoin systemd[1]: Failed to start Bitcoin daemon banlist importer.
bitcoin-node> error: Traceback (most recent call last):
  File "/nix/store/jln9i6pa2544wqnjybh0wm3w587zxqm3-nixops-1.7/lib/python2.7/site-packages/nixops/deployment.py", line 743, in worker
    raise Exception("unable to activate new configuration (exit code {})".format(res))
Exception: unable to activate new configuration (exit code 4)

Traceback (most recent call last):
  File "/nix/store/jln9i6pa2544wqnjybh0wm3w587zxqm3-nixops-1.7/bin/..nixops-wrapped-wrapped", line 991, in <module>
    args.op()
  File "/nix/store/jln9i6pa2544wqnjybh0wm3w587zxqm3-nixops-1.7/bin/..nixops-wrapped-wrapped", line 412, in op_deploy
    max_concurrent_activate=args.max_concurrent_activate)
  File "/nix/store/jln9i6pa2544wqnjybh0wm3w587zxqm3-nixops-1.7/lib/python2.7/site-packages/nixops/deployment.py", line 1063, in deploy
    self.run_with_notify('deploy', lambda: self._deploy(**kwargs))
  File "/nix/store/jln9i6pa2544wqnjybh0wm3w587zxqm3-nixops-1.7/lib/python2.7/site-packages/nixops/deployment.py", line 1052, in run_with_notify
    f()
  File "/nix/store/jln9i6pa2544wqnjybh0wm3w587zxqm3-nixops-1.7/lib/python2.7/site-packages/nixops/deployment.py", line 1063, in <lambda>
    self.run_with_notify('deploy', lambda: self._deploy(**kwargs))
  File "/nix/store/jln9i6pa2544wqnjybh0wm3w587zxqm3-nixops-1.7/lib/python2.7/site-packages/nixops/deployment.py", line 1019, in _deploy
    dry_activate=dry_activate, max_concurrent_activate=max_concurrent_activate)
  File "/nix/store/jln9i6pa2544wqnjybh0wm3w587zxqm3-nixops-1.7/lib/python2.7/site-packages/nixops/deployment.py", line 775, in activate_configs
    .format(len(failed), len(res), ", ".join(["‘{0}’".format(x) for x in failed])))
Exception: activation of 1 of 1 machines failed (namely on ‘bitcoin-node’)

Bitcoin Hardware Wallet Integration

Time Horizon: Medium term

Description: Integrate hardware wallets with PSBT in Bitcoin Core 0.18.0

Motivation: Users may wish to use a hardware wallet with the hardware wallet functionality coming in Bitcoin Core 0.18.0 on top of the full-node that comes with nix-bitcoin.

Possible Implementation: Separate bitcoin service with wallet functionality.

Backup module

Time Horizon: Medium Term

Description: Create a module to backup all critical files (Bitcoin Wallet files, lnd channelstate, clightning hsmsecret, JoinMarket wallet files) and optionally time intensive data like Bitcoin blockchain and electrs database.

Motivation: We want to offer the user an easy way to backup his/her nix-bitcoin node in case of data loss or migration.

Implementation: Shell script, oneshot systemd script, duplicity

Deployment failed while migrating to v0.0.1

At step 6. of the migration guide in the v0.0.1 release notes, after deploying I get the following error.

Any hint at what I may have done wrong while migrating to the new upgrade process?

$ nixops deploy --show-trace
warning: ignoring the user-specified setting 'show-trace', because it is a restricted setting and you are not a trusted user
warning: ignoring the user-specified setting 'show-trace', because it is a restricted setting and you are not a trusted user
error: while evaluating the attribute 'config.deployment' at undefined position:
while evaluating anonymous function at /nix/store/j5nzal9kpz06bqx73gzqskzjcba43ba3-source/lib/options.nix:177:41, called from undefined position:
while evaluating 'scrubOptionValue' at /nix/store/j5nzal9kpz06bqx73gzqskzjcba43ba3-source/lib/options.nix:173:22, called from /nix/store/j5nzal9kpz06bqx73gzqskzjcba43ba3-source/lib/options.nix:177:44:
while evaluating 'isDerivation' at /nix/store/j5nzal9kpz06bqx73gzqskzjcba43ba3-source/lib/attrsets.nix:305:18, called from /nix/store/j5nzal9kpz06bqx73gzqskzjcba43ba3-source/lib/options.nix:174:8:
while evaluating the attribute 'config' at /nix/store/j5nzal9kpz06bqx73gzqskzjcba43ba3-source/lib/modules.nix:96:25:
while evaluating 'yieldConfig' at /nix/store/j5nzal9kpz06bqx73gzqskzjcba43ba3-source/lib/modules.nix:83:29, called from /nix/store/j5nzal9kpz06bqx73gzqskzjcba43ba3-source/lib/modules.nix:82:16:
while evaluating 'mergeModules' at /nix/store/j5nzal9kpz06bqx73gzqskzjcba43ba3-source/lib/modules.nix:233:26, called from /nix/store/j5nzal9kpz06bqx73gzqskzjcba43ba3-source/lib/modules.nix:73:17:
while evaluating 'mergeModules'' at /nix/store/j5nzal9kpz06bqx73gzqskzjcba43ba3-source/lib/modules.nix:237:36, called from /nix/store/j5nzal9kpz06bqx73gzqskzjcba43ba3-source/lib/modules.nix:234:5:
while evaluating 'flip' at /nix/store/j5nzal9kpz06bqx73gzqskzjcba43ba3-source/lib/trivial.nix:138:16, called from /nix/store/j5nzal9kpz06bqx73gzqskzjcba43ba3-source/lib/modules.nix:280:6:
while evaluating 'byName' at /nix/store/j5nzal9kpz06bqx73gzqskzjcba43ba3-source/lib/modules.nix:260:25, called from /nix/store/j5nzal9kpz06bqx73gzqskzjcba43ba3-source/lib/modules.nix:268:21:
while evaluating 'reverseList' at /nix/store/j5nzal9kpz06bqx73gzqskzjcba43ba3-source/lib/lists.nix:393:17, called from /nix/store/j5nzal9kpz06bqx73gzqskzjcba43ba3-source/lib/modules.nix:73:38:
while evaluating anonymous function at /nix/store/j5nzal9kpz06bqx73gzqskzjcba43ba3-source/lib/modules.nix:167:37, called from /nix/store/j5nzal9kpz06bqx73gzqskzjcba43ba3-source/lib/modules.nix:68:19:
while evaluating 'filterModules' at /nix/store/j5nzal9kpz06bqx73gzqskzjcba43ba3-source/lib/modules.nix:157:36, called from /nix/store/j5nzal9kpz06bqx73gzqskzjcba43ba3-source/lib/modules.nix:168:7:
while evaluating anonymous function at /nix/store/j5nzal9kpz06bqx73gzqskzjcba43ba3-source/lib/modules.nix:161:31, called from undefined position:
while evaluating the attribute 'disabled' at /nix/store/j5nzal9kpz06bqx73gzqskzjcba43ba3-source/lib/modules.nix:139:13:
while evaluating the attribute 'disabled' at /nix/store/j5nzal9kpz06bqx73gzqskzjcba43ba3-source/lib/modules.nix:139:13:
while evaluating the attribute 'disabled' at /nix/store/j5nzal9kpz06bqx73gzqskzjcba43ba3-source/lib/modules.nix:139:13:
while evaluating 'loadModule' at /nix/store/j5nzal9kpz06bqx73gzqskzjcba43ba3-source/lib/modules.nix:106:53, called from /nix/store/j5nzal9kpz06bqx73gzqskzjcba43ba3-source/lib/modules.nix:144:22:
while evaluating 'unifyModuleSyntax' at /nix/store/j5nzal9kpz06bqx73gzqskzjcba43ba3-source/lib/modules.nix:172:34, called from /nix/store/j5nzal9kpz06bqx73gzqskzjcba43ba3-source/lib/modules.nix:109:14:
while evaluating 'applyIfFunction' at /nix/store/j5nzal9kpz06bqx73gzqskzjcba43ba3-source/lib/modules.nix:198:29, called from /nix/store/j5nzal9kpz06bqx73gzqskzjcba43ba3-source/lib/modules.nix:109:59:
while evaluating 'isFunction' at /nix/store/j5nzal9kpz06bqx73gzqskzjcba43ba3-source/lib/trivial.nix:333:16, called from /nix/store/j5nzal9kpz06bqx73gzqskzjcba43ba3-source/lib/modules.nix:198:68:
syntax error, unexpected '}', expecting ';', at /nix/store/wgzmgh3cpv04vfg8ca8w9hygc7sa5dck-nix-bitcoin-src/modules/nix-bitcoin.nix:9:1
error: evaluation of the deployment specification failed

CoinJoin Integration

Time Horizon: Medium Term

Description: Integrate a CoinJoin service into nix-bitcoin.

Motivation: Running a CoinJoin service 24/7 is desirable to maximize probability of success. Users may not wish to keep their laptops on 24/7, but nix-bitcoin is designed to be on 24/7. So it makes sense to run a CoinJoin service on a nix-bitcoin node.

Possible Implementation:

Option 1: Integrate JoinMarket maker as well as taker, using its command-line UI over ssh.

Option 2: Integrate Wasabi Daemon as-is by pushing users walletfile to nix-bitcoin node as a temporary file with nixops deploy and starting a mix on the nix-bitcoin node (wassabee --mix --wallet <WalletName>). When the user wishes to stop the mix, nix-bitcoin stops the wassabee --mix and automatically deletes the walletfile. When the user starts up his Wasabi GUI, it should display the now post-mix coins.

Possible problems

• User going online while mix is ongoing on nix-bitcoin node
• User stopping wassabee --mix in the middle of a round, possibly causing DOS punishments
• Wasabi GUI not being able to accurately display new state after wassabee --mix on the nix-bitcoin node. This could possibly be fixed by copying the walletfile back to the users computer after he stops the mix.

Option 3: Wait for a fully-featured Wasabi headless daemon (receive, mix and send) and integrate that

Possible problems

• Both Option 2 and Option 3 (ab)use Wasabi as an intermediary wallet for CoinJoining

Option 4: Wait for and integrate Samourai's whirlpool daemon

nix-bitcoin should be directly importable from source archive

See https://gitlab.com/simple-nixos-mailserver/nixos-mailserver/-/blob/master/default.nix which can be imported as:

      imports = [
        (builtins.fetchTarball {
          url = https://gitlab.com/simple-nixos-mailserver/nixos-mailserver/-/archive/c2ee9f217ad35a2d614cd978786b8418805ee4e0/nixos-mailserver-c2ee9f217ad35a2d614cd978786b8418805ee4e0.tar.bz2;
          sha256 = "0wf1554x6qy524isz6zvadj4q7k8f24hqaj09fwaz64xsfgcxz5y";
        })
      ];

nix-bitcoin will be slightly more complicated because (currently) it includes packages in addition to modules, but the general idea should be the same.

Electrs service leaks secret. Need help updating electrs.

services.electrs exposes the bitcoinrpc secret through the process ARGV which is globally readable.
The fix is to use a config file for supplying options, but electrs must first be updated to support this.

Running pkgs/electrs/generate.sh works fine, the hacky sed patches all succeed, but the build fails with:

Building build.rs (electrs)
…
/nix/store/…-binutils-2.31.1/bin/ld: (.text.fallbackSort.isra.2+0x9ff): undefined reference to `bz_internal_error'

(Full build output)

This is what I've found out so far:

• bz_internal_error is an error callback that should be defined by clients of bzip2.
• The error is somehow caused by the dependency on rocksdb. rocksdb defines this fn.
• tikv/tikv#4338 (comment)

I'm not familiar with rust's build architecture and I couldn't solve this in a reasonable amount of time.
@jb55, can you help me with this?

c-lightning plugins

Would be nice to make it easy to load clightning plugins:

• Package pylightning
• Package lightningd/plugins plugins and all the python dependencies required by them
• Add plugins option to clightning module

Add Liquid Swap tool

Nice, https://github.com/Blockstream/liquid-swap actually supports command line only.

VirtualBox Image (50GB) is to small for the Bitcoin Blockchain

Problem
Setting up a nix-bitcoin node in VirtualBox with the provided manual in docs/install.md creates a VirtualBox image with only 50GB of disk space. The Bitcoin blockchain needs more space.

Reproduce
Deploy a nix-bitcoin node and let it sync the blockchain. After a while the VirtualBox disk fills up an bitcoind crashes. (Where are the bitcoind logs located in nix-bitcoin? maybe add log locations to the FAQ?)

df shows a full disk using 100% of the 50GB defined in https://github.com/NixOS/nixpkgs/nixos/modules/virtualisation/virtualbox-image.nix#L13

What doesn't work as a solution
Adding deployment.virtualbox.baseImageSize = 400 * 1024; to network/network-vbox.nix doesn't work. Error thrown:

building all machine configurations...
error: The option `deployment.virtualbox.baseImageSize' defined in `/path/to/nix-bitcoin/network/network-vbox.nix' does not exist.
(use '--show-trace' to show detailed location information)
Traceback (most recent call last):
  File "/nix/store/fhhrm6nm71risrkp383nzdx1zviycfq6-nixops-1.7/bin/..nixops-wrapped-wrapped", line 991, in <module>
    args.op()
  File "/nix/store/fhhrm6nm71risrkp383nzdx1zviycfq6-nixops-1.7/bin/..nixops-wrapped-wrapped", line 412, in op_deploy
    max_concurrent_activate=args.max_concurrent_activate)
  File "/nix/store/fhhrm6nm71risrkp383nzdx1zviycfq6-nixops-1.7/lib/python2.7/site-packages/nixops/deployment.py", line 1063, in deploy
    self.run_with_notify('deploy', lambda: self._deploy(**kwargs))
  File "/nix/store/fhhrm6nm71risrkp383nzdx1zviycfq6-nixops-1.7/lib/python2.7/site-packages/nixops/deployment.py", line 1052, in run_with_notify
    f()
  File "/nix/store/fhhrm6nm71risrkp383nzdx1zviycfq6-nixops-1.7/lib/python2.7/site-packages/nixops/deployment.py", line 1063, in <lambda>
    self.run_with_notify('deploy', lambda: self._deploy(**kwargs))
  File "/nix/store/fhhrm6nm71risrkp383nzdx1zviycfq6-nixops-1.7/lib/python2.7/site-packages/nixops/deployment.py", line 1003, in _deploy
    self.configs_path = self.build_configs(dry_run=dry_run, repair=repair, include=include, exclude=exclude)
  File "/nix/store/fhhrm6nm71risrkp383nzdx1zviycfq6-nixops-1.7/lib/python2.7/site-packages/nixops/deployment.py", line 671, in build_configs
    raise Exception("unable to build all machine configurations")
Exception: unable to build all machine configurations

Support having another username for "operator"

GUI for installation

It would be nice to have a GUI for installation. The installer would be aware of configuration.nix and be able to make changes to that. The FIXMEs would be taken care of the GUI installer.

Based on this issue, seems like no one is really working on it.

Anyone here working on it?

Recurring Lightning Donations

Time Horizon: Short term

Description: Create module to programmatically send lightning donations to Tallycoin users.

Motivation: It may be desirable to make recurring donations to Tallycoin users. Nix-bitcoin nodes are online 24/7 and can therefore programmatically execute this "push payment".

Possible Implementation: Create a module that sends a weekly donation. Recipient and amount are defined in the configuration.nix. The module should pull a lightning invoice for the specified user and amount over the Tallycoin API via torsocks and pay that invoice with lightning-cli pay. It should execute this script on a hard-coded weekly interval.

nix-bitcoin should use acme for SSL certificates

I was able to get this working with the electrs package with the following in my configuration.nix:

        services.nginx.virtualHosts."satoshi.reardencode.com" = {
          forceSSL = true;
          enableACME = true;
        };
        services.nginx.appendConfig = ''
          stream {
            upstream electrs {
              server localhost:50001;
            }
            server {
              listen 50003 ssl;
              proxy_pass electrs;
              ssl_certificate /var/lib/acme/satoshi.reardencode.com/fullchain.pem;
              ssl_certificate_key /var/lib/acme/satoshi.reardencode.com/key.pem;
              ssl_trusted_certificate /var/lib/acme/satoshi.reardencode.com/full.pem;
            }
          }
        '';
      };

Obviously a bunch of those parts would need to be replaced with variables.

Give Option for Remote Builds

Time Horizon: Medium Term

Description: Allow user to forward building to his nix-bitcoin node.

Motivation: If the node is more powerful than the deploy machine this would make for faster builds.

Implementation: https://nixos.org/nix/manual/#chap-distributed-builds

Collaboration with Cryptoanarchy deb repository?

Hi, I work on a very similar project as you do, but focused on packaging for Debian 10. The infrastructure is here: http://github.com/Kixunil/cryptoanarchy-deb-repo-builder/
The output result is here: https://deb.ln-ask.me

I see we have very similar general approach (isolation of services, security, packaging instead of docker craziness...) and I wonder if we can join forces somehow.

But Debian is a completely different OS, how do you want to join forces on that?!

From my experience a lot of work when it comes to packaging is reading enough documentation (sometimes even source code) of the project and turning it into high-level specification, sometimes filing bug reports or documentation requests to various projects.

Can we share a common language for defining this high-level specification of each package? Then we could "compile" it into OS-specific one.

Gains:

• You get one very dedicated contributor
• We all get several new packages (btcpayserver, ridetheln, c-lightning) already
• We all get double the output for the same amount of work - suddenly you can target Debian (which may not be as nice as Nix in certain aspects, but has more users - the reason I started working on that) and I can target Nix as a by product
• You get some freedom-related non-bitcoin packages in the future
• You get access to the SDK I'm planning to develop in the future. The SDK will aim at making it easier to develop new LNP/BP-enabled apps

Costs:

• We need to decide on a common language
• At least one side has to implement a transpiler/compiler
• We either need to align our policies in some aspects or have the language expressive enough to implement different policies (I'd aim for a balanced mix of both approaches)

I've noticed you have "your own" (nix-defined) high-level language that has some features my doesn't (and I want them) and I developed my own, which may have features interesting for you ("compiler" in debcrafter repository)

For instance, I try hard to avoid tedious writing of things that are easy to typo. You define a user for each service manually. Debcrafter assumes a new user named same as the package (I plan to start prefixing them with underscore though), unless there's explicit exception. There's bunch of other similar rules (creation of paths, triggers...) I found the hard way, why such things are important (after spending hours on debugging stupid stuff like a typo in a path). This also affects security (Did I forget to set the appropriate permissions somewhere?) Even after developing Debcrafter, I figured it's still not enough!

My vision is to generate "header files" for statically checked languages (Rust at least) from that specification, so that correctness of various helper "scripts" can be statically checked. I figured, you don't have that problem because nix language is more expressive in this regard. But I wonder what happens if you attempt to use a non-existing variable or one with a wrong type.

I hope this is a good enough high-level overview of what I'm thinking about. I'm not going to make it longer right now, but I'm certain I will need to document my project better if there's any interest from your side. Please let me know. I'm willing to discuss it over an audio/video call if that works for you better. I have a feeling that it'd be more efficient.

Integrate Wasabi Daemon

Time Horizon: Medium Term

Description: Package Wasabi's headless daemon and create a module that allows easy usage. This module should automatically create a "hot" mixing wallet and be able to send to an external xpub.

Motivation: Provide alternative CoinJoin implementation to JoinMarket for different use cases

Implementation: Examples

• @schulterklopfer https://github.com/schulterklopfer/wasabi_docker
• @PulpCattel https://github.com/PulpCattel/Spawn

nixops can be installed from nixpkgs again

@nixbitcoin I don't think it's necessary anymore to install your own nixops from source. Can you check that? If so, we can remove the instructions from the tutorial.

Feedback and minor improvements to the install.md

I've recently deployed a nix-bitcoin node to a VirtualBox following the instructions provided in docs/install.md. I detail some feedback and minor improvements below.

1) to '1.4. Create Host Adapter in VirtualBox':

Add vboxmanage hostonlyif create to the manual. Has the same effect as
Open VirtualBox -> File -> Host Network Manager -> Create but doesn't use the GUI which might not be available on headless setups.

2) to '2.2. Install latest Nix in "multi-user mode" with GPG Verification'

Using curl -o install-nix-2.2.1 https://nixos.org/nix/install saves the install script with version 2.2.1 in the filename. This could be confusing in the future when curl https://nixos.org/nix/install gets you a newer version. I'd just write curl -o install-nix https://nixos.org/nix/install in the manual (of course change the filename in the following lines too).

3) to '3.1. Clone this project'

While git clone https://github.com/jonasnick/nix-bitcoin still works, it would be cleaner clone from https://github.com/fort-nix/nix-bitcoin. This seems like a relikt from the recent repository transfer to the fort-nix Organisation. For the unknowing user cloning from jonasnick/nix-bitcoin seems like cloning from a fork.

4) to '3.1 Setup environment'

On low-end machines nix-shell takes quite some time and comes with a high CPU load, while not giving any output (at first). Usually making users skeptical whats being done in the background. Adding a simple "The nix-bitcoin environment is being setup. This might take a while." would be an improvement here I guess. If that's not possible a note in the install.md might be helpful.

check out crate2nix for electrs builds

I'm slowly in the process of upstreaming some of this stuff to nixos/nixpkgs. I noticed electrs was crashing on some blocks for some reason so I updated to the latest version, only to find that the rust packages in whatever rust channel nixpkgs was using was out of date.

there's a handy tool called crate2nix which does fully self contained packaging of cargo projects. I'm giving it a spin now, just thought I'd mention it incase we want to switch to it in here for more reliable builds.

bitcoind should use RPC cookie auth not user/password

--rpccookiefile=<path> should be used to put the cookie file in a path that accessible with components that require bitcoind RPC access

FR: Add mosh

Just a wishlist item. It's really horrible to have to use SSH over Tor. It often takes several 100ms roundtrip.

Add ability to install declaratively into an existing nixos system

I tried to get this working, but ran into an issue I didn't understand.

See https://gitlab.com/simple-nixos-mailserver/nixos-mailserver for an example of a nixos-based project that can be installed via nixops, directly via a local configuration.nix or in a container easily.

I tried this config:

{ config, lib, pkgs, ... }:

{
  containers.nix-bitcoin = {
    config = {
      imports = [
        (builtins.fetchGit {
          url = "https://github.com/fort-nix/nix-bitcoin.git";
          rev = "6c69eb857617e8c6baec09a149bad29e8d829f7c";
        })
      ];
      services.nix-bitcoin.enable = true;
    };
  };
}

And got: error: The option containers.nix-bitcoin.outPath' defined in <unknown-file>' does not exist.

Supported Hardware

Time Horizon: Long term

Description: Compile a list of tested hardware and specific instructions. Choose one hardware platform to focus development on and look into providing plug'n'play versions of that.

Motivation: Focusing on selected hardware will improve UX and reduce development resources in the long term. Having pre-installed, ready-to-use hardware will open nix-bitcoin to a whole new class of users, who need a reasonably secure and fully-featured bitcoin node but lack the knowledge to go through the NixOS install process. Would be most useful in conjunction with https://github.com/jonasnick/nix-bitcoin/issues/38.

Implementation: pcengines apu, Intel NUC, Nodl

Enable Pruning

Time Horizon: Medium term

Description: Enable pruning by pulling blocks that have been pruned but are required by clightning from the Blockstream Explorer

Motivation: Pruning drastically reduces the footprint of the Bitcoin blockchain and therefore improves UX. Clightning might need pruned blocks and could therefore not work on pruned Blockchains. These blocks could be fetched from Blockstream Explorer without drastically changing the security model.

Possible Implementation: Waiting for comment by @jonasnick

Lacking documentation of usage without nixops

The installation instructions use nixops for installation and deployment of the machine.

I'm trying to use the modules without using nixops. And I'm having issues with the secrets file.

Failed to start bitcoind.service: Unit nix-bitcoin-secrets.target not found.
the following new units were started: electrs.service
warning: the following units failed: liquidd.service, nginx.service

● liquidd.service - Elements daemon providing access to the Liquid sidechain
   Loaded: loaded (/nix/store/wpqkdnanpjsyfx3ipgsqazp7vb9xa4m6-unit-liquidd.service/liquidd.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Sat 2020-04-04 17:01:26 WEST; 1min 25s ago
  Process: 18950 ExecStartPre=/nix/store/0wg86bgi1lc79xxk96kfgr16z1qhkgp1-unit-script-liquidd-pre-start (code=exited, status=0/SUCCESS)
  Process: 18968 ExecStart=/nix/store/g1fzhfv7dyvsxh7bmm7x0zckg3pvr8lj-elementsd-0.18.1.3/bin/elementsd -datadir=/media/bitcoin/liquid -pid=
/media/bitcoin/liquid/liquidd.pid (code=exited, status=1/FAILURE)
 Main PID: 18968 (code=exited, status=1/FAILURE)
       IP: 40B in, 60B out
      CPU: 840ms

Apr 04 17:01:26 bitcoin-nuc systemd[1]: liquidd.service: Consumed 840ms CPU time, received 40B IP traffic, sent 60B IP traffic.
Apr 04 17:01:26 bitcoin-nuc systemd[1]: liquidd.service: Service RestartSec=100ms expired, scheduling restart.
Apr 04 17:01:26 bitcoin-nuc systemd[1]: liquidd.service: Failed to schedule restart job: Unit nix-bitcoin-secrets.target not found.
Apr 04 17:01:26 bitcoin-nuc systemd[1]: liquidd.service: Failed with result 'exit-code'.
Apr 04 17:01:26 bitcoin-nuc systemd[1]: liquidd.service: Consumed 840ms CPU time, received 40B IP traffic, sent 60B IP traffic.

● nginx.service - Nginx Web Server
   Loaded: loaded (/nix/store/cnbizbzr8k9laz5ma8r5razgwhh0k0jy-unit-nginx.service/nginx.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Sat 2020-04-04 17:01:30 WEST; 1min 21s ago
  Process: 18908 ExecStartPre=/nix/store/px157sy1ki33siw77ab4g0jykfq5zasm-unit-script-nginx-pre-start (code=exited, status=1/FAILURE)
       IP: 0B in, 0B out
      CPU: 29ms

Apr 04 17:01:30 bitcoin-nuc systemd[1]: nginx.service: Service RestartSec=10s expired, scheduling restart.
Apr 04 17:01:30 bitcoin-nuc systemd[1]: nginx.service: Failed to schedule restart job: Unit nix-bitcoin-secrets.target not found.
Apr 04 17:01:30 bitcoin-nuc systemd[1]: nginx.service: Failed with result 'exit-code'.
warning: error(s) occurred while switching to the new configuration

Make Electrs Reachable over SSL

Time Horizon: Short term

Description: Make electrs accessible over SSL by using NGINX as an SSL Endpoint as detailed in https://github.com/romanz/electrs/blob/master/doc/usage.md#ssl-connection.

Motivation: Allow the user to connect over Android Electrum app, which can only connect over SSL protocol. Connection security is already provided by Tor HS.

Possible Implementation: This would require creating an SSL certificate and an appropriate NGINX configuration block with a nix derivation.

Run services using clightning under different users

Currently these services run under the clightning user because clightnings RPC socket is only readable by the owner. However, there's a flag now to set the permissions on the RPC socket, which would allow making it group readable:

lightning --rpc-file-mode <arg>                Set the file mode (permissions) for the JSON-RPC socket (default: "0600")

Add default monitoring configuration

I don't think that nix-bitcoin should go so far as to install a complete monitoring and visualization stack, but some basic service status alerting could be really useful.

One example of how this can be achieved is:

https://gitlab.com/simple-nixos-mailserver/nixos-mailserver/-/blob/master/default.nix#L576

Hardening

• Harden pkgs
  • is c-lightning built with all hardening flags?
  • use reproducible builds where possible (for example, building and verifying bitcoind with gitian)
• Better verification
  • sign repository and add tools for easy verification
  • verify developer signatures on GitHub repositories of pkgs (for example, romanz's signature on electrs tags)
  • Use sha256 where possible
    • fetchgit doesn't take sha256, only sha1? there's a nixpkgs version that takes sha256...
      • https://stackoverflow.com/questions/31659527/what-is-the-meaning-of-sha256-in-nixpkgs-fetchgit-where-does-the-value-come-fro
• Principle of least privilege
  • allow group to read only one file
    • bitcoin-cli: rpc cookie, lightgning-clirpc file, lncli macaroon and tlscert
  • daemons (bitcoin,clightning) shouldn't be able to read,write stuff to user operator
  • user bitcoind can only run bitcoind, etc.
    • setfacl?
• Other
  • nixops automatically trusts fingerprint... even if it changes???
    • Warning: Permanently added '151.217.30.41' (ED25519) to the list of known hosts.
  • nixpkgs both has fetchgit or fetchFromGit

Restrict directory access for services

We're already restricting access relatively okay by giving every service its own user. However there's at least one problem: the classic way to gain persistence as an unprivileged user is to add something similar to a .bashrc file into the users home which is then executed every time the user logs in. We should make that impossible by not giving access to the users home directory. This would in principle work right now already through systemd's ProtectHomes, except that the users home directories are often set to the services data directory, instead of /home.

Is it possible to build this nix configuration in a nixos/nix docker container ?

This is a request for information.

I have a small familiarity with nix but not a big one.

I was wondering if is possible to build this configuration.nix into a nixos/nix container

I did try to follow the guides here but after running "nix-shell" i was stuck

I would have hoped to run nix-build but that is not even available inside the container.

thanks

Add Electrs .onion to Webindex

Time Horizon: Short term

Description: Show electrs Tor HS .onion in the webindex

Motivation: This would allow users to more easily find their electrum server Tor HS .onion and use that to connect with an Electrum wallet.

Possible Implementation: Display along with lightning nodeid and nanopos link.

Integrate Samourai Dojo

Samourai Dojo is required for Samourai Wallet users to avoid using Samourai's backend servers. It would be great to see it supported along with electrs.

https://github.com/Samourai-Wallet/samourai-dojo/blob/develop/README.md

WoT verify pinned nixpkgs

Time Horizon: Short term

Description: Update both nixpkgs and nixpkgs-unstable only to signed commits by trusted maintainers whose keys have been verified through the WoT or in person.

Motivation: Continuation of nix-bitcoin hardening efforts.

Implementation: Find trustworthy maintainers who regularly commit signed commits to either nixpkgs or nixpkgs-unstable, verify their PGP keys through WoT or in person, write standard to only pin those commits, follow the standard.

Add nix-bitcoin to recurring donations module

Time Horizon: Short Term

Description: Create nix-bitcoin BTCPayserver and add it as default option for recurring donations module in configuration.nix.

Motivation: This could help fund bounties and infrastructure for nix-bitcoin development.

banlist should honor dataDir setting

In pkgs/banlist/banlist.sh there is:

echo "Importing node banlist into bitcoind"
# banlist taken from https://people.xiph.org/~greg/banlist.cli.txt
$1/bin/bitcoin-cli -datadir=/var/lib/bitcoind setban 100.34.232.70/32 add 31557600

But in nix-bitcoin/modules/bitcoind.nix I can see there is a

dataDir = mkOption {
        type = types.path;
        default = "/var/lib/bitcoind";
        description = "The data directory for bitcoind.";

Problem is that I have/want to have services.bitcoind.dataDir configured to a different directory than /var/lib/bitcoind.

Bitcoin Core 18.0 Update

With the recent release of Bitcoin Core 18.0: What is the nix-bitcoin update schedule for things like Bitcoin Core and e.g. c-lightning?

How could one help to update Bitcoin Core in nix-bitcoin?

Enable validatepegin for Liquid

Would be cool to have a bool flag in the liquid config that when true (and perhaps if bitcoind.enable is true), it adds the validatepegin=1 and the necessary mainchainrpc* fields to have Liquid validate pegins.

feedback for install.md on own hardware

I installed nix-bitcoin on my own hardware following the second tutorial starting here. I have a few notes below:

{
  bitcoin-node =
    { config, pkgs, ... }:
    { deployment.targetHost = 1.2.3.4;
    };
}

deployment.targetHost expects a string (e.g. deployment.targetHost = "1.2.3.4";)

---

Copy contents of NixOS machine's hardware-configuration.nix to file.

Better: Copy contents of NixOS machine's /etc/nixos/hardware-configuration.nix to file.

---

7. Add boot option to hardware-configuration.nix
   Option 2: Set grub device for Legacy Boot (MBR)
   boot.loader.grub.device = "/dev/sda":

Should be boot.loader.grub.device = "/dev/sda"; <-- note the ; not : at the end

Incorrect password attempt from 127.0.0.1

I'm getting a ton of these log messages in my bitcoind logs:

Jul 10 08:53:20 dasilva-nix bitcoind[31937]: 2019-07-10T08:53:20Z ThreadRPCServer incorrect password attempt from 127.0.0.1:51402
Jul 10 08:53:20 dasilva-nix bitcoind[31937]: 2019-07-10T08:53:20Z ThreadRPCServer incorrect password attempt from 127.0.0.1:51406
Jul 10 08:53:20 dasilva-nix bitcoind[31937]: 2019-07-10T08:53:20Z ThreadRPCServer incorrect password attempt from 127.0.0.1:51412
Jul 10 08:53:20 dasilva-nix bitcoind[31937]: 2019-07-10T08:53:20Z ThreadRPCServer incorrect password attempt from 127.0.0.1:51418
Jul 10 08:53:21 dasilva-nix bitcoind[31937]: 2019-07-10T08:53:21Z ThreadRPCServer incorrect password attempt from 127.0.0.1:51420
Jul 10 08:53:21 dasilva-nix bitcoind[31937]: 2019-07-10T08:53:21Z ThreadRPCServer incorrect password attempt from 127.0.0.1:51426
Jul 10 08:53:21 dasilva-nix bitcoind[31937]: 2019-07-10T08:53:21Z ThreadRPCServer incorrect password attempt from 127.0.0.1:51438
Jul 10 08:53:22 dasilva-nix bitcoind[31937]: 2019-07-10T08:53:22Z ThreadRPCServer incorrect password attempt from 127.0.0.1:51442
Jul 10 08:53:22 dasilva-nix bitcoind[31937]: 2019-07-10T08:53:22Z ThreadRPCServer incorrect password attempt from 127.0.0.1:51446
Jul 10 08:53:22 dasilva-nix bitcoind[31937]: 2019-07-10T08:53:22Z ThreadRPCServer incorrect password attempt from 127.0.0.1:51452

Would this be the clightning node trying to connect to bitcoind with a wrong password? Or electrs?

Consider replacing nixops with krops

I just learned about krops (https://tech.ingolf-wagner.de/nixos/krops/) which is simpler than nixops and sufficient for most applications.

• pro
  • native file encryption
  • build happens on target
    • easier for macOS users
    • easier to deploy to arm
    • using no substitutes won't slow down your personal computer
• con
  • no easy virtualbox tutorial anymore
    • but we could provide a build with nixos-generate

Harden Nginx and Tor

Time Horizon: Short term

Description: Apply nix-bitcoin-services.defaultHardening to both network facing services Nginx and Tor. Additionally make Nginx run as unprivileged user nginx instead of root.

Motivation: Continuation of nix-bitcoin hardening efforts.

Implementation:

Control VM

Time Horizon: Long term

Description: Segment nix-bitcoin into two virtual machines. One running nix-bitcoin and all its modules, and the other running a command-and-control environment with git, gnupg, pre-configured vim, and nixops.

Motivation: Including a control VM in the nix-bitcoin setup would allow shipping ready-to-use .iso's. A user could install that on supported hardware and start using nix-bitcoin immediately. Updating, verifying and deploying should be possible from this control VM. This also alleviates the problems with processor architecture and makes nix-bitcoin accessible to users of all operating systems, not just Linux, as long as they have an ssh client.

Implementation: Use libvirt @clefru

electrs breaks when the datadir variable is set

I set the electrs.dataDir variable to some other location and I'm getting these logs in electrs:

Jul 10 08:55:55 dasilva-nix s4j86k2qkxz8473v1gy7xh3q5jfxp743-unit-script-electrs-pre-start[1425]: chmod: cannot access '/media/bitcoin-extra/electrs/startscript.sh': No such file or directory

So I suppose this startscript.sh script is somehow hard-coded into a path, but then the datadir is used to invoke it. Why isn't that script really hardcoded and just put in some hardcoded location?

Integrate Blockstream Satellite

Time Horizon: Medium Term

Description: Create a package containing all necessary software and drivers to connect to a Blockstream Satellite Hardware Kit. Create a module that allows for plug'n'play usage.

Motivation: Nix-bitcoin nodes should stay online when internet goes out

Implementation: NixOS module and package