Replace runtime Sjors template-provider with SRI sv2-tp

vnprc-agent commented

2026-07-16 23:11:48 +01:00

Collaborator

Upgrade the runtime Stratum V2 template provider — the sv2-tp process that devenv up runs for local dev and the hashpool-sv2-tp systemd unit runs in production (testnet4) — from the pinned v1.0.6 to the current maintained stratum-mining/sv2-tp release (v1.1.1).

Coupled requirement: Bitcoin Core 30.2 -> 31.1

sv2-tp v1.1.x requires Bitcoin Core v31.0 or later; v1.0.6 is the last sv2-tp release that supports Core v30.2. (Core 31.0's IPC mining interface adopted a new mining.capnp schema — an old client on a new node, or a new client on an old node, fails at Init.makeMining.) The runtime pins bitcoin-node.nix at Core 30.2, so this is a coupled bump: bitcoin-node.nix must move 30.2 -> 31.1 in the same change, or template production hard-fails. Do not land the two pins separately.

Scope

In scope:

sv2-tp.nix: version 1.0.6 -> 1.1.1 + recompute the x86_64-linux-gnu hash.
bitcoin-node.nix: version 30.2 -> 31.1 + recompute the x86_64-linux-gnu hash (mandatory, coupled).
devenv.nix, config/sv2-tp.conf, and the systemd units need no invocation or config-key change — the sv2-tp -datadir -chain -conf and bitcoin -m node -ipcbind=unix command lines and the sv2-tp.conf keys (sv2bind, ipcconnect, debug, loglevel) are unchanged in v1.1.x. Production carries an operational testnet4 datadir migration (Core 30 -> 31), which is human-gated.

Out of scope:

The integration test harness (test/integration-tests, roles/tests-integration) — this issue is only about the runtime template provider.
Non-linux platform hashes (aarch64-linux-gnu, darwin stay sha256-TODO); dev and prod are x86_64-linux.
SRI protocol-crate / roles-workspace bumps (#1).

Note: sv2-tp v1.1.0 renamed -sv2interval to -templateinterval, but this has no runtime effect — the runtime never sets that flag (it appears only in the out-of-scope test harness).

Validation

nix build .#sv2-tp .#bitcoin-node with the new pins/hashes; assert the built versions (sv2-tp v1.1.1, bitcoin-node v31.1) and that the Core multiprocess layout (bin/bitcoin, bin/bitcoin-cli, libexec/bitcoin-node) is intact.
devenv up regtest smoke test: sv2-tp logs Connected to bitcoin-node via IPC with no Init.makeMining / interfaces.cpp errors, and the pool receives templates through a full mining flow.
Production/testnet4 deploy is human-gated (back up the datadir first; confirm Core 31.1 opens it without a reindex demand).

Dev plan: hashpool/dev-plans/upgrade-devenv-sv2-tp.md in the vnprc/notes repo. Residual risk: R3 (coupled major-version runtime dependency bump affecting the live template provider on both dev and production).

Upgrade the **runtime** Stratum V2 template provider — the `sv2-tp` process that `devenv up` runs for local dev and the `hashpool-sv2-tp` systemd unit runs in production (testnet4) — from the pinned `v1.0.6` to the current maintained `stratum-mining/sv2-tp` release (**v1.1.1**). ## Coupled requirement: Bitcoin Core 30.2 -> 31.1 sv2-tp `v1.1.x` requires **Bitcoin Core v31.0 or later**; `v1.0.6` is the last sv2-tp release that supports Core `v30.2`. (Core 31.0's IPC mining interface adopted a new `mining.capnp` schema — an old client on a new node, or a new client on an old node, fails at `Init.makeMining`.) The runtime pins `bitcoin-node.nix` at Core `30.2`, so this is a **coupled** bump: `bitcoin-node.nix` must move `30.2 -> 31.1` in the same change, or template production hard-fails. Do not land the two pins separately. ## Scope In scope: - `sv2-tp.nix`: `version` `1.0.6 -> 1.1.1` + recompute the `x86_64-linux-gnu` hash. - `bitcoin-node.nix`: `version` `30.2 -> 31.1` + recompute the `x86_64-linux-gnu` hash (mandatory, coupled). - `devenv.nix`, `config/sv2-tp.conf`, and the systemd units need **no invocation or config-key change** — the `sv2-tp -datadir -chain -conf` and `bitcoin -m node -ipcbind=unix` command lines and the `sv2-tp.conf` keys (`sv2bind`, `ipcconnect`, `debug`, `loglevel`) are unchanged in v1.1.x. Production carries an operational testnet4 datadir migration (Core 30 -> 31), which is human-gated. Out of scope: - The integration test harness (`test/integration-tests`, `roles/tests-integration`) — this issue is only about the runtime template provider. - Non-linux platform hashes (`aarch64-linux-gnu`, darwin stay `sha256-TODO`); dev and prod are `x86_64-linux`. - SRI protocol-crate / roles-workspace bumps (#1). Note: sv2-tp v1.1.0 renamed `-sv2interval` to `-templateinterval`, but this has **no runtime effect** — the runtime never sets that flag (it appears only in the out-of-scope test harness). ## Validation - `nix build .#sv2-tp .#bitcoin-node` with the new pins/hashes; assert the built versions (`sv2-tp` v1.1.1, `bitcoin-node` v31.1) and that the Core multiprocess layout (`bin/bitcoin`, `bin/bitcoin-cli`, `libexec/bitcoin-node`) is intact. - `devenv up` regtest smoke test: `sv2-tp` logs `Connected to bitcoin-node via IPC` with no `Init.makeMining` / `interfaces.cpp` errors, and the pool receives templates through a full mining flow. - Production/testnet4 deploy is human-gated (back up the datadir first; confirm Core 31.1 opens it without a reindex demand). Dev plan: `hashpool/dev-plans/upgrade-devenv-sv2-tp.md` in the `vnprc/notes` repo. Residual risk: R3 (coupled major-version runtime dependency bump affecting the live template provider on both dev and production).