No description
Find a file
Erik Arvstedt 4aaef5fdf4
services: use wants dependency where possible
Let A be a service that depends on another service B.
When A can gracefully handle failures and restarts of B, use
```
wants = [ "B.service" ];
after = [ "B.service" ];
```
instead of
```
requires = [ "B.service" ];
after = [ "B.service" ];
```
in the definition of A.

This way, A keeps running when B is stopped or restarted after a failure.
With `requires`, A is instead stopped when B is stopped or restarted due to a failure.

This brings two benefits:

1. Improved uptime
Examples:
- RTL keeps running when one lightning node has failed
- btcpayserver keeps running and accepting on-chain payments when the lightning node has crashed

2. Avoids a systemd bug where depending units (`A.service` in the
above example) are not restarted when their dependency fails
(issue github/systemd#18856, no full link to avoid spamming the issue).
In real world nix-bitcoin deployments, this issue was only likely to
appear when clightning failed during activation, causing depending
units (like `RTL`) to stop and not be restarted.
All services depending on `clightning` have now been changed to use
`wants`, thereby avoiding the bug.

Services `electrs` and `lightning-loop` fail when their respective
dependencies stop, so these services have not been changed.
I also haven't changed services `joinmarket` and
`joinmarket-yieldgenerator`. Further manual testing is needed to
determine if they can be switched to `wants`.
2025-01-29 20:44:26 +01:00
dev update-flake.sh: add workflow for updating the NixOS version 2024-12-14 10:52:26 +01:00
docs lndconnect: add clnrest 2024-11-27 21:35:46 +01:00
examples fix test persistentContainerExample 2025-01-22 20:41:52 +01:00
helper update-flake.sh: add workflow for updating the NixOS version 2024-12-14 10:52:26 +01:00
modules services: use wants dependency where possible 2025-01-29 20:44:26 +01:00
pkgs update nixpkgs 2025-01-21 16:51:29 +00:00
test services: use wants dependency where possible 2025-01-29 20:44:26 +01:00
.cirrus.yml update to NixOS 24.11 2024-12-14 10:52:26 +01:00
default.nix delete modules/default.nix 2022-08-28 23:49:12 +02:00
flake.lock update nixpkgs 2025-01-21 16:51:29 +00:00
flake.nix flake: update extra-container 2024-12-14 10:52:27 +01:00
LICENSE Add license 2019-01-02 14:03:52 +00:00
overlay.nix simplify overlay.nix 2020-01-09 10:43:29 +01:00
README.md README: remove clightning-rest 2024-11-27 21:35:46 +01:00
SECURITY.md spark-wallet: remove package and module 2023-06-02 10:50:11 +00:00
shell.nix Clean up development shell.nix 2020-03-30 10:49:15 +02:00

nix-bitcoin logo


CirrusCI status GitHub tag (latest SemVer) GitHub commit activity GitHub contributors GitHub downloads


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

Docs

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

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)

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.
We are always happy to help.