Ship simplepool as a release you can install in one line

[rsantacroce]

Three things, all pointing at the same gap: simplepool was installable only if you already knew how to install it. Plus the payout cadence change.

1. A release path

• scripts/release.sh builds a tarball; .github/workflows/release.yaml publishes one per architecture on a v* tag, with a merged SHA256SUMS.
• The tarball is a git checkout with a prebuilt binary dropped in, not a trimmed runtime bundle. The systemd units, nginx vhost, schema.sql and the dashboard all already expect a checkout at $ROOT, so shipping that shape means the release path and the source path converge after one step instead of forking into two sets of layout assumptions.
• release.sh refuses a dirty tree: the binary is built from the working tree while the source beside it comes from git archive, and on a dirty tree those are two different programs. --allow-dirty to override.
• CI unpacks each tarball and runs build/simplepool --version out of it before publishing — a tarball that doesn't produce a runnable binary never becomes a release.
• Glibc floor stated explicitly: built on Ubuntu 22.04 (2.35), recorded in each tarball's RELEASE file.

2. An installer that survives being piped

• --from-release [tag] — downloads the published build for the machine's arch, verifies it against SHA256SUMS, unpacks. No compiler, no clone. Now the default when there's no checkout to build from; --from-source for the old behaviour.
• curl | sudo bash could not have worked. BASH_SOURCE[0] is not a readable path when piped, so both the sudo re-exec and --help were reading a file that isn't there. Both now handled.
• The default repo pointed at a mirror with no published releases, which would have made --from-release fail on a fresh box. Now LayerTwo-Labs/simplepool.
• A release install skips build-essential/git but still installs the -dev packages, because those are the names that stay put across distro releases (libhiredis-dev everywhere, vs libhiredis0.14 on 22.04 and libhiredis1.1.0 on 24.04).
• Refuses to overlay a tarball onto a git checkout — that produces a tree that is neither.

3. simplepoolctl

status / logs / config / doctor / upgrade / uninstall, reading the same /etc/simplepool/install.env the installer writes, so it needs no configuration of its own. upgrade re-runs the installer non-interactively rather than reimplementing it, so an upgrade cannot drift from a fresh install. doctor checks the things that actually break: binary runs here, addresses set, schema loaded, data dir writable by the service user, bitcoind answers getblockchaininfo, something listening on :3334.

4. Payouts run daily

As requested — but PAYOUT_INTERVAL_MS drove both the payout run and the settlement re-check of an already-broadcast batch. Setting it to 24h naively would have left a real, already-sent payout uncredited for a day, and let a missed BMM request sit unrecovered for the same. Split into three clocks:

after a tick that…	next tick
did nothing, or settled cleanly	PAYOUT_INTERVAL_MS — 24h
broadcast a batch, or is waiting on one	PAYOUT_SETTLE_INTERVAL_MS — 30s
failed to broadcast, or reserve short	PAYOUT_RETRY_INTERVAL_MS — 5m

Long delays are served in hops, because setTimeout wraps past ~24.8 days and would turn a monthly cadence into a spin that broadcasts every tick. payout/test/cadence.test.js pins every row of that table plus the clamp.

5. Docs

• docs/simplepool.html — one self-contained, no-JavaScript, theme-aware page covering both modes end to end: shares, the nonce split, difficulty and vardiff, both coinbase shapes, PPS rate derivation, Thunder payouts, the four audit queries, the data model, config, and what the pool can't do.
• RELEASING.md — the tag flow.
• README gets an Install section; INSTALL.md Part B is reorganised into installer / deploy-script / manual.

Cutting the release after this merges

VERSION is bumped to 0.2.0, so git tag v0.2.0 && git push origin v0.2.0 publishes immediately. The release job fails a tag that disagrees with the Makefile, because the version is compiled into the binary and a release whose own --version differs from its name makes every later "which version is this box running?" answer untrustworthy.

Testing

• make test — all 7 C suites pass
• payout — 56/56 (14 new)
• dashboard — 76 pass, 2 skipped, 0 fail
• scripts/release.sh run end to end; tarball layout verified against what install.sh asserts and what the CI smoke test checks
• docs/simplepool.html rendered and screenshotted in light and dark; no external assets, no scripts, all 21 anchors resolve, tags balanced

Two bugs found and fixed in my own code while reviewing: the installer's cleanup trap expanded a local that was out of scope by exit time, making rm -rf "" fail and take the exit status with it — every successful release install would have ended non-zero; and the setTimeout overflow above.

Not tested end to end: the installer itself has not been run on a real Linux box (no Docker daemon available locally, and it guards against non-Linux). The release download path in particular can only be exercised once a release actually exists — which is the next step after this merges.

🤖 Generated with Claude Code