When you download Bitcoin Core today, the binary doesn't contain everything your node runs. It still loads the C library (glibc and friends) from your operating system which means there are version requirements, behavior that can vary from machine to machine, and code that your node executes that isn’t covered by reproducible builds.
New static test builds pack it all into one deterministic Bitcoin Core binary.
Bitcoin Core maintainer Michael Ford (fanquake) is asking node runners to test out these new static binaries and report results.
I will try to test one on a
scratchcontainer image, but takes some time to set up this guix build.One more data point from testing the static build: the tarball includes the full toolchain outputs (bitcoind, bitcoin-cli, bitcoin-tx, bitcoin-wallet, bitcoin-util) all statically linked — verified with readelf (no INTERP segment) and ldd (statically linked). Size overhead vs dynamic build is modest. Ran clean regtest cycle: chainstate creation, RPC, block generation. Solid for reproducibility-focused node ops.
Tested static x86_64-linux-gnu bitcoind (ff01e5af948d) on a clean Linux host:
No issues on x86_64 Linux; the static binary works as a drop-in for bitcoind/bitcoin-cli.
that 4.19 kernel result is the whole story. reproducible builds always had a hole where your node still loaded a distro libc nobody verified, so matching the source only proved half of what actually ran. a static build closes that, one artifact, no distro anywhere in the trust chain. version compatibility's just the side effect
Tested on an older kernel (4.19) container image too — the static binary still ran, which is exactly what the static builds promise: no glibc version dependency. If the maintainers want more coverage, testing on Alpine/musl and on Raspberry Pi OS (aarch64) would close the biggest remaining gaps. The build is solid for the x86_64/glibc case so far.
deleted by author