Revert bitcoind-gunix node sourcing #9

Merged

vnprc merged 1 commit from agent/revert-gunix-migration into master

2026-08-08 17:28:40 +01:00

vnprc-agent commented

2026-08-08 03:10:06 +01:00

Collaborator

Owner summary

Undoes the bitcoind-gunix swap (PR #6). Its Cachix has no v31.1 binaries, so
every devenv shell on the dev VM fell back to a tens-of-GB from-source
toolchain build that exceeds the VM's disk — dev work is stalled.
For a running machine: dev shells and deploys fetch the pinned official Core
31.1 binary again, in seconds instead of hours.
Identical: the bitcoin bytes (the restored pin is the same b80d9c3e… hash the
gunix gate enforces), Core 31.1, sv2-tp 1.1.1, and every runtime invocation.
Proof: the tree is byte-identical to pre-migration 7fe5780b (empty diff);
devenv shell completes in 14 s; bitcoin --version reports v31.1.0.
If wrong: revert this commit — that re-lands the migration exactly.

Refs vnprc/hashpool#4

What changed

One commit, a pure git revert of c1eca3c3 (PR #6), touching the same 12
files: restores bitcoin-node.nix (official-binary fetchurl, sha256-pinned)
and the BITCOIN_VERSION download blocks in scripts/build.sh +
scripts/ship.sh; deletes bitcoin-node-gunix.nix; removes the
bitcoind-gunix input from flake.nix, devenv.yaml, and both lockfiles;
drops the README mechanism note.

Faithful-revert note: the dead bitcoind.nix and its update-bitcoind
justfile recipe come back — PR #6 deleted them as ride-along cleanup. They are
restored deliberately so the tree is byte-identical to the regtest-validated
7fe5780b; re-delete them separately or when the migration re-lands.

Why the migration is being backed out

Measured on the dev VM (2026-08-08):

The gunix tarball's flake-side outPath
(/nix/store/wm49ghwqi3wdddalpk2rfd9qkn8vkc4b-bitcoin-31.1-x86_64-linux-gnu.tar.gz)
returns 404 from 0xb10c-bitcoind-gunix.cachix.org, and the VM's only
substituter is cache.nixos.org — nothing substitutes.
nix build --dry-run on the tarball shows a 25-derivation from-source
closure (three cross-GCC 14.3.0 bootstraps, cross binutils/glibc,
bitcoin-31.1-depends, bitcoind). Live devenv shell runs were caught
compiling the cross toolchain; the build needs tens of GB against ~22 G free.
The tarball is input-addressed (no outputHash), so the official release
tarball cannot be nix store add-ed to satisfy it.
The devenv/flake transitive-nixpkgs skew (accepted in PR #6) doubles the
cost: devenv shell and nix build .#bitcoin-node-* each want their own
full toolchain closure.

Validation

On the dev VM, in the change worktree:

git diff 7fe5780b HEAD — empty; the tree is byte-identical to the last
pre-migration state, which vnprc/hashpool#2 validated on regtest.
grep -ri gunix over the tree — no references remain.
devenv shell -- true — completes in 13.9 s (previously: interrupted after
1194 s still compiling GCC).
bitcoin and bitcoin-cli resolve on the shell PATH from the restored
bitcoin-node package; bitcoin --version → v31.1.0.

Not run here: live devenv up mining flow and a production deploy — both are
unchanged from the 7fe5780b state that #2's validation covered.

Residual risk

No new mechanism: this is the exact tree prod pins were last validated at.
Deploy scripts return to the VPS-side bitcoincore.org curl with the /tmp
cache guard. Review finding: neither restored script hash-verifies that
download — checksum enforcement exists only on the nix side
(bitcoin-node.nix's sha256 pin). This matches the pre-#6 state exactly; an
optional follow-up could add sha256sum -c to the curl block. The
migration's goals (pin-free sourcing, byte-parity gate)
remain tracked by vnprc/hashpool#4; the recommended re-land shape is a
fetched adapter variant that reads the expected hash at eval time from the
gunix input's checked-in noncodesigned.SHA256SUMS (gunix ships a parser at
nix/lib/sha256sums.nix), keeping the dev loop cheap while the full
from-source reproduction stays available to build-capable machines.

Merge

Human merge: git merge --no-ff agent/revert-gunix-migration + push. The
owner removed the GPG-signing requirement (2026-08-08), but the secrets repo's
signing-required-branches at origin/master still lists work/hashpool master — a host whose protected-refs-policy hook reads that file will still
demand a signed tip until the removal is pushed.

## Owner summary Undoes the bitcoind-gunix swap (PR #6). Its Cachix has no v31.1 binaries, so every `devenv shell` on the dev VM fell back to a tens-of-GB from-source toolchain build that exceeds the VM's disk — dev work is stalled. For a running machine: dev shells and deploys fetch the pinned official Core 31.1 binary again, in seconds instead of hours. Identical: the bitcoin bytes (the restored pin is the same b80d9c3e… hash the gunix gate enforces), Core 31.1, sv2-tp 1.1.1, and every runtime invocation. Proof: the tree is byte-identical to pre-migration `7fe5780b` (empty diff); `devenv shell` completes in 14 s; `bitcoin --version` reports v31.1.0. If wrong: revert this commit — that re-lands the migration exactly. Refs vnprc/hashpool#4 ## What changed One commit, a pure `git revert` of `c1eca3c3` (PR #6), touching the same 12 files: restores `bitcoin-node.nix` (official-binary fetchurl, sha256-pinned) and the `BITCOIN_VERSION` download blocks in `scripts/build.sh` + `scripts/ship.sh`; deletes `bitcoin-node-gunix.nix`; removes the `bitcoind-gunix` input from `flake.nix`, `devenv.yaml`, and both lockfiles; drops the README mechanism note. Faithful-revert note: the dead `bitcoind.nix` and its `update-bitcoind` justfile recipe come back — PR #6 deleted them as ride-along cleanup. They are restored deliberately so the tree is byte-identical to the regtest-validated `7fe5780b`; re-delete them separately or when the migration re-lands. ## Why the migration is being backed out Measured on the dev VM (2026-08-08): - The gunix tarball's flake-side outPath (`/nix/store/wm49ghwqi3wdddalpk2rfd9qkn8vkc4b-bitcoin-31.1-x86_64-linux-gnu.tar.gz`) returns 404 from `0xb10c-bitcoind-gunix.cachix.org`, and the VM's only substituter is cache.nixos.org — nothing substitutes. - `nix build --dry-run` on the tarball shows a 25-derivation from-source closure (three cross-GCC 14.3.0 bootstraps, cross binutils/glibc, `bitcoin-31.1-depends`, `bitcoind`). Live `devenv shell` runs were caught compiling the cross toolchain; the build needs tens of GB against ~22 G free. - The tarball is input-addressed (no `outputHash`), so the official release tarball cannot be `nix store add`-ed to satisfy it. - The devenv/flake transitive-nixpkgs skew (accepted in PR #6) doubles the cost: `devenv shell` and `nix build .#bitcoin-node-*` each want their own full toolchain closure. ## Validation On the dev VM, in the change worktree: - `git diff 7fe5780b HEAD` — empty; the tree is byte-identical to the last pre-migration state, which vnprc/hashpool#2 validated on regtest. - `grep -ri gunix` over the tree — no references remain. - `devenv shell -- true` — completes in 13.9 s (previously: interrupted after 1194 s still compiling GCC). - `bitcoin` and `bitcoin-cli` resolve on the shell PATH from the restored `bitcoin-node` package; `bitcoin --version` → v31.1.0. Not run here: live `devenv up` mining flow and a production deploy — both are unchanged from the `7fe5780b` state that #2's validation covered. ## Residual risk No new mechanism: this is the exact tree prod pins were last validated at. Deploy scripts return to the VPS-side `bitcoincore.org` curl with the `/tmp` cache guard. Review finding: neither restored script hash-verifies that download — checksum enforcement exists only on the nix side (`bitcoin-node.nix`'s sha256 pin). This matches the pre-#6 state exactly; an optional follow-up could add `sha256sum -c` to the curl block. The migration's goals (pin-free sourcing, byte-parity gate) remain tracked by vnprc/hashpool#4; the recommended re-land shape is a `fetched` adapter variant that reads the expected hash at eval time from the gunix input's checked-in `noncodesigned.SHA256SUMS` (gunix ships a parser at `nix/lib/sha256sums.nix`), keeping the dev loop cheap while the full from-source reproduction stays available to build-capable machines. ## Merge Human merge: `git merge --no-ff agent/revert-gunix-migration` + push. The owner removed the GPG-signing requirement (2026-08-08), but the secrets repo's `signing-required-branches` at origin/master still lists `work/hashpool master` — a host whose protected-refs-policy hook reads that file will still demand a signed tip until the removal is pushed.

vnprc-agent added 1 commit

2026-08-08 03:10:06 +01:00

Revert "Source bitcoin-node from the bitcoind-gunix flake" 58d00684ff

This reverts commit c1eca3c3f3f0448ba0d43a2b90970e731ec03a52 (PR #6),
restoring the tree to 7fe5780b exactly.

The gunix input is unrealizable on the dev VM: the 0xb10c-bitcoind-gunix
Cachix has no v31.1 paths (tarball narinfo 404s), so `devenv shell` falls
back to building gunix's cross toolchain from source — 25 derivations
including three cross-GCC bootstraps — which exceeds this VM's disk and
stalls every dev-shell entry. The gunix tarball is input-addressed, so the
official release tarball cannot be nix-store-added to satisfy it.

This restores the official-binary bitcoin-node.nix path: fetchurl of the
official 31.1 release pinned to the same b80d9c3e hash the gunix gate
enforces — identical bytes, seconds instead of hours. The migration can
re-land as a revert of this commit once realized binaries exist (upstream
cache push, a build-capable machine, or the planned fetched-variant hybrid).

vnprc-agent commented

2026-08-08 03:14:00 +01:00

Author

Collaborator

Read-only review

Reviewed the revert commit (58d00684) and every claim in the PR body. No
blockers. Because the tree is provably byte-identical to 7fe5780b, the
review surface is the body's claims and cross-branch interactions rather than
the diff content itself.

Confirmed:

Pin equivalence — the restored bitcoin-node.nix pin
sha256-uA2cPgTaePtvBWloVnNBjPaG+tupBC2SbRP7h/9QP54= converts
(nix hash convert --to base16) to exactly
b80d9c3e04da78fb6f0569685673418cf686fadba9042d926d13fb87ff503f9e, the same
digest gunix's checked-in noncodesigned.SHA256SUMS publishes for
bitcoin-31.1-x86_64-linux-gnu.tar.gz. Byte-identity of the sourced binary
across the revert is a fact, not an intent.
git diff 7fe5780b HEAD empty; grep -ri gunix clean (the only hit is the
worktree's .git gitdir pointer, whose path contains the branch name).
devenv shell -- true completes in 13.9 s on the dev VM; bitcoin and
bitcoin-cli resolve on PATH from the restored package and
bitcoin --version reports v31.1.0. Note for testers: the multiprocess
layout ships bitcoin / bitcoin-cli / libexec/bitcoin-node — there is
no bitcoind binary, so command -v bitcoind is the wrong smoke test.

Corrected in the body (was a defect): the original body claimed the deploy
scripts' VPS-side curl has "sha256 verification". False — neither restored
script checksums the download (grep -c sha256 = 0 in both); the only hash
gate is the nix-side fetchurl pin. This matches the pre-#6 state exactly, so
nothing regresses, but the claim was corrected rather than left inflated. An
optional follow-up could add sha256sum -c to the curl block.

Cross-branch: git merge-tree agent/revert-gunix-migration agent/nutxx-lookup-cdk-017 merges clean (exit 0) — the two branches'
devenv.nix hunks are disjoint. After this PR merges, merge master into
agent/nutxx-lookup-cdk-017: its worktree still carries the gunix devenv
wiring and will hit the from-source stall until it does.

Known ride-alongs (intentional, stated in body): the dead bitcoind.nix
and its update-bitcoind justfile recipe return for byte-fidelity to the
regtest-validated pre-migration tree.

## Read-only review Reviewed the revert commit (`58d00684`) and every claim in the PR body. No blockers. Because the tree is provably byte-identical to `7fe5780b`, the review surface is the body's claims and cross-branch interactions rather than the diff content itself. **Confirmed:** - Pin equivalence — the restored `bitcoin-node.nix` pin `sha256-uA2cPgTaePtvBWloVnNBjPaG+tupBC2SbRP7h/9QP54=` converts (`nix hash convert --to base16`) to exactly `b80d9c3e04da78fb6f0569685673418cf686fadba9042d926d13fb87ff503f9e`, the same digest gunix's checked-in `noncodesigned.SHA256SUMS` publishes for `bitcoin-31.1-x86_64-linux-gnu.tar.gz`. Byte-identity of the sourced binary across the revert is a fact, not an intent. - `git diff 7fe5780b HEAD` empty; `grep -ri gunix` clean (the only hit is the worktree's `.git` gitdir pointer, whose path contains the branch name). - `devenv shell -- true` completes in 13.9 s on the dev VM; `bitcoin` and `bitcoin-cli` resolve on PATH from the restored package and `bitcoin --version` reports v31.1.0. Note for testers: the multiprocess layout ships `bitcoin` / `bitcoin-cli` / `libexec/bitcoin-node` — there is no `bitcoind` binary, so `command -v bitcoind` is the wrong smoke test. **Corrected in the body (was a defect):** the original body claimed the deploy scripts' VPS-side curl has "sha256 verification". False — neither restored script checksums the download (`grep -c sha256` = 0 in both); the only hash gate is the nix-side fetchurl pin. This matches the pre-#6 state exactly, so nothing regresses, but the claim was corrected rather than left inflated. An optional follow-up could add `sha256sum -c` to the curl block. **Cross-branch:** `git merge-tree agent/revert-gunix-migration agent/nutxx-lookup-cdk-017` merges clean (exit 0) — the two branches' `devenv.nix` hunks are disjoint. After this PR merges, merge `master` into `agent/nutxx-lookup-cdk-017`: its worktree still carries the gunix devenv wiring and will hit the from-source stall until it does. **Known ride-alongs (intentional, stated in body):** the dead `bitcoind.nix` and its `update-bitcoind` justfile recipe return for byte-fidelity to the regtest-validated pre-migration tree.