Are there any node operating systems that can be considered reproducible?
I've looked into various node operating systems like UmbrellOS, Start9, and RaspiBlitz, but I can't find any info on their reproducibility. Does this mean they might not be reproducible at all?
For those unfamiliar with what reproducibility means: it’s when you can use the build scripts and source code of a binary, compile it, and get the exact same binary that’s officially released. This is crucial for making sure that the binary you’re using is exactly what you get from the source code, with nothing added or taken away.
None of them appear to build reproducible ISO or image file, although Tails is one of few OS that do that[1]. Note that tails doesn't include full node software, although it include Electrum. On application level, Umbrel makes it much more difficult since it use Docker to ship and run the apps[2]. But looking at one of Raspiblitz PR, it seems it download Bitcoin Core from the website[3]. So verify the binary is theoretically possible.
[1] https://tails.net/contribute/build/reproducible/
[2] https://github.com/getumbrel/umbrel-apps
[3] https://github.com/raspiblitz/raspiblitz/pull/2527
I would generally recommend 'building' your node yourself. There are guides like mine here (that I should / will update):
[Guide] FULL NODE OpenSUSE 15.3: bitcoind + electrs + c-lightning + RTL
[Guide] How to run a Bitcoin Core full node for under 50 bucks!
If you want a nice and pretty front-end, those can usually be installed manually on top of the 'manually built' full node, and the installation process on Linux often requires building the binaries from source, anyway. If not required, then at least it will be an option.
To be fully safe, you could even first compile the Linux distro of choice yourself, and then compile Bitcoin Core, as well as all the other components, as shown in the guide above.
I just quickly checked and interestingly, Umbrel does not document an easy way to install the user-interface after the fact anymore (if memory serves correct, it was possible in earlier versions).
Meanwhile, RaspiBlitz has separate repositories for blitz_api and raspiblitz-web for the web UI. Those include regular Linux build instructions from source.
This is very unfortunate
I always thought that most Linux distribution are reproducible?
What exactly is hindering the reproduction of Docker images?
And Umbrell should at least make the system itself reproducible.
Bitcoin Core itself is reproducible as far as I know. but I want to have an operating system that is also reproducible to run Bitcoin Core, LND, and maybe other services like Nextcloud
I guess what you looking for is something like
https://nixbitcoin.org/
Why use nix implementation?
Eelco Dolstra and Andres Löh. 2008. NixOS: a purely functional Linux distribution. In Proceedings of the 13th ACM SIGPLAN international conference on Functional programming (ICFP '08). Association for Computing Machinery, New York, NY, USA, 367378. https://doi.org/10.1145/1411204.1411255
Eelco Dolstra and Andres Löh. 2008. NixOS: a purely functional Linux distribution. SIGPLAN Not. 43, 9 (September 2008), 367378. https://doi.org/10.1145/1411203.1411255
PS.: Nix project actually predates Ubuntu by about a year...
I never check in detail, but i'm under impression most of them aren't reproducibl. But i found this interesting PDF from website you mentioned, https://reproducible-builds.org/_lfs/presentations/2023-09-10-what-s-missing-so-that-debian-is-finally-reproducible.pdf.
I barely use Docker, but i recall one of the reason is not all people who create Docker image pin exact version or certain file name/content depends on current timestamp. And from less technical user perspective (like me), verifying Docker image feels more tricky.
Reproducibility in this context means that you can quickly verify whether precompiled binaries that are made available for ease of installation, have been compiled from the given source files.
While the Linux kernel is fully open source and most Linux distributions are, too, not all of them offer precompiled binaries and / or an easy way to verify those. Your best bet will always be to build from source, which you can do with any open source project, by definition.
That's why I'd recommend you install a safe, long-term stable base distribution like OpenSUSE and then install every single component (Bitcoin Core, C-Lightning, Electrs) from source.
That way you don't just verify that a prebuilt binary matches its source files, you actually built the binary yourself from that source.
Hi ABCbits I saw your slides, particularly this one that mentions
Holger NMUed everything that was built before buildinfo
files existed, however there are cases where packages
without buildinfo files pop up (like packages going through
NEW).
buildinfos.debian.net is just a PoC, but it works around
#862073, #763822, #862538, #929397 (all against
ftp.debian.org well enough.
As a strong supporter of Debian, I really appreciate the growing attention developers are paying to reproducibility. However, Nix and Debian use fundamentally different methods to achieve it. Nix is "Reproducible by Design" while Debian uses "Reproducible by Verification". Still, both try to solve the "it works on my machine" problem by creating a strict mapping between inputs, like source code and build tools and the final, bit-for-bit identical binary output.
Nix treats build processes as pure functions. Just like in mathematics, a pure functions output depends only on explicit inputs, without relying on or altering the outside environment. In practice, Nix achieves this by taking every single input, like the source code, the compiler, and all dependencies and calculating a combined cryptographic hash for them.
This hash becomes the exact directory name where the built software is saved. If you change even a single bit in any input, the hash changes completely, creating a brand-new directory instead of overwriting the old one. This idea, formalized in Eelco Dolstra's doctoral work, guarantees that software builds are perfectly isolated and immutable.
There are also different levels of reproducibility. At the language level, package managers for specific ecosystems like Cargo for Rust, npm for Node.js, and uv for Python share the same goal as Nix, but with varying degrees of strictness. The C and C++ ecosystem is famously fragmented because, unlike Rust or Node.js, it does not have a single, official package manager built into the language. However, industry standards like Conan and vcpkg step in to fill that role. Manifest files across these tools, like Cargo.toml, package.json, or conanfile.txt, are similar to Nix expressions. They let you declare your high-level intent. Lock files then resolve those requirements into specific versions and record their cryptographic hashes. This prevents what the community calls "dependency version drift" where packages update unpredictably across different machines ensuring everyone downloads the exact same files.
The big difference is control. Cargo and uv lock down your source code dependencies, but they do not control the underlying environment. If you build on a Mac and a coworker builds on Linux, or if you have different system-level compilers, the build might still fail or behave differently. Nix essentially acts as a mega-lockfile for the entire operating system. It doesn't just lock down the Python or C++ packages; it locks down the Python interpreter, the C compiler, the system libraries, and the bash shell used to run the build script.
Regarding Nix, I am personally more familiar with using Flakes to manage these environments. However, it is worth noting that Flakes are still officially classified as an experimental feature and are considered unstable, even though they are widely adopted in the community.
All the best.
I must say, I'm not paranoid enough (no offense!) to ask for everything has to be reproducible, which is particularly complicated for the underlying OS. You rarely have, if at all, a reproducible build of your OS.
So, I'm fine to start with a well known OS (RaspiOS, Debian, OpenSuSE, Fedora) and build from there. I'm also pragmatic and don't like to make my life too hard when the risk assessment doesn't require it. In my opinion it depends on what you need or want to protect.
I'm mostly fine e.g. to use Umbrel in a low value and low loss risk environment. From what I observed in Umbrel, used Docker containers are pinned by their hash. If you want to verify how a specific container was built, you're on your own and need to know how to do it. It's not rocket science, but also not something for newbies and requires some knowledge. Being a bit of an IT geek helps somewhat.
I used RaspiBlitz in the past, now made a pause and will likely have a fresh look at it when I find the time. In the past it was my impression that in theory you could build your RaspiBlitz image from the Github sources. It wasn't for the faint of heart, though, but not too complicated either. Definitely not sure, how it's today as I haven't looked at the last releases at all.
I also run a very partial build of Raspibolt, mainly only the Bitcoin Core node part because that's what I needed for a special case. Starting from a headless RaspiOS (mostly Debian-like) I set it up from the pre-compiled ARM64 binary of Bitcoin Core and of course verified the signatures. I have enough Linux knowledge to follow Raspibolt setup instructions with ease.
I didn't build Bitcoin Core from sources, because a) it's reproducible, b) others have verified to reproduce the official binaries and c) under these pre-conditions it's fine and pragmatic for me to only verify checksums and signatures.
Reproducible as in what? All compilation steps are deterministic? Or instructions everywhere like Linux From Scratch.
If these systems are built on Debian then this is a non-issue to be honest.
Edit: Umbrel is running Debian under the hood, so that means all the packages are almost completely reproducible.
Reproducible in this context means for me, I can build the same binary from the source code and from that I can deduce that all of the published source code produces the published binary. My own build matches checksums of the published binary.
This reproducibility gives me confidence that no code other than what the published source code builds has been sneaked in. I know exactly what code is executed. That is the purpose of being reproducible, at least from my perspective.
The thing is I don't want to keep my PC running 24/7 on 100% CPU load to compile everything from source every time it gets an update. The only realistic thing for me is to do occassionaly test compile to check the reproducibility claims and hope that some other people do the same.
It's not required running your machine 24/7 just because you compile updates yourself.
Typically, you'd be able to grab a cup of coffee and come back to everything done.
And if you care about reproducibility, you'd have to check every release anyway, which also takes time. So we're not comparing to an 'auto update' installation that requires no interaction, as that would be incompatible with your goals.
While I don't know what you're working with, I highly doubt that it's unrealistic for you to compile software on your machine.
I might be missing something, but how do you get to that conclusion? And what about Debian makes it inherently possible to have reproducible builds for whatever you install on the system? I could easily falsify that statement by providing a piece of software for Debian as a precompiled binary without granting access to source code, for instance.
You're exaggerating, unless you trying to build all package on your system with relative slow CPU. On related note, you may want to research about Portage. It's package manager that let you build and install package from source code which is mainly used by Gentoo distro.
Or you could limit it to application that holds your money or important personal data (such as Bitcoin Core and password manager you use).
No, I would compile to check reproducibility on first install and then assume that other people do the same as I when they install it, or that parties I trust check the reproducibility.
For example: Most apps on my phones are reproducible compile by F-Droid* , which is established in the Free Software ecosystem for a long time, and if they would compile something malicious in, then someone who do test compiles, could find this and destroy's F-Droid's reputation very fast.
Reproducibility doesn't mean zero trust, because checking reproducibility doesn't guarantee that the source code isn't malicous.
But reproducibility brings accountability that then can justify trust or distrust.
I really much go with this position:
*https://f-droid.org/docs/Reproducible_Builds
Most of the maintainers who each are responsible for updating their own set of packages for Debian have uploaded reproducible builds, and in Debian if you refuse to upload your source code as another package, your software gets chucked into the "nonfree" repository which is not enabled by default.
umbrelOS is to my knowledge based on Debian and available from getumbrel.com.
I'm not aware of any Bitcoin node software in the Debian repository. Electrum wallet in an outdated version is e.g. available but that's not a node.
You could search the Debian software package repositories yourself, couldn't you? Too lazy?
https://www.debian.org/distrib/packages --- scroll down the page for some search options or use the links at the top
https://packages.debian.org/stable/allpackages --- all packages of current stable Debian "trixie"