dvb-WarpPool v1.12.2 — the energy dashboard stays fast even after months of solar data
A small, honest performance patch — relevant if you run your solar/PV system alongside the pool:
- The problem. With solar tracking enabled, the energy dashboard splits consumed energy into “solar” vs. “grid”. The query behind it joined a per-minute solar table to the miner telemetry on a computed key — which SQLite could only resolve as a nested-loop full scan. After a few months of PV history that took several seconds per call, and the dashboard runs it on a ~30s cadence → the log filled with “slow statement” warnings.
- The fix. The split now runs as a correlated per-bucket query, driven off the telemetry and backed by the solar table’s primary-key index. Result: hundreds of times faster (the hourly daily-rebuild ~2000×), and the computed kWh figures are byte-identical — only the speed changes, not a single number.
Honest framing: a pure performance fix for solar pools — no new feature, no hashrate or earnings effect, no behaviour or config change. If you don’t use solar tracking you were never affected and see nothing change (the solar table is empty). If you do run PV, your energy dashboard is snappy again and your log is quiet. 1021 tests green, reproducible build as always.
dvb-WarpPool v1.13.0 — access controls for your Stratum endpoint, built-in backups, and explorer links
This release is all about operations & hardening — every piece optional and off by default:
- Decide who may mine. Four new, individually toggleable gates: a payout-address allowlist (only your own addresses may mine), an IP allow/deny gate over CIDR ranges, a per-IP connection limit, and an automatic ban for a worker that keeps sending rejected shares. Your local network and the pool UI are never affected. Nothing changes for solo-at-home use — these gates are for anyone opening their pool to others, or who just wants one more layer of defense.
- Built-in scheduled backups. The pool can now write its own periodic backups on a schedule (with a retention count) — no external cron, no script needed. Off by default; enable it under
[backup].
- One-click block lookups. Found-block hashes and heights now link straight to a block explorer (mempool.space by default, fully configurable) — one click instead of copy-pasting into a search bar.
Honest framing: a pure operations & hardening release. None of these features touch your hashrate or your block chances, and none is on by default — change nothing and you have exactly the pool you had before. 1037 tests green, reproducible build as always.
dvb-WarpPool v1.14.0 — finally see WHY shares get rejected (per worker, V1 + V2)
A small but practical release: per-worker reject reasons.
- The problem. Until now you only saw a bare number per miner: “X rejected shares”. Whether those came from stale shares at block/job changes, from a too-high difficulty, from ntime drift, or from a real misconfiguration — invisible. A reject rate without the reason is a black box.
- What’s new.
/api/workers now returns a per-worker breakdown by reason (stale-share, low-difficulty, invalid-ntime, duplicate-share, … including the Sv2 pre-checks like job-not-found), sorted by frequency — for both protocols, Stratum V1 and V2. In-memory and additive: the share-validation logic itself is unchanged; it only labels the reject that was already counted.
- Why it helps. The trigger was a concrete case: a NerdAxe (Sv2) showed “over 5% rejects” in its miner software. Measured, pool and miner counters were in exact lockstep (no discrepancy), and the rate was a decaying reconnect effect after box updates — no bug, no money impact. Telling exactly that apart — a benign reconnect blip vs. a real misconfiguration — is what the reason breakdown now makes obvious at a glance.
Also in this release: a faster multi-arch Docker image build (cross-compile instead of arm64 emulation) and a batch of dependency updates (bitcoin, mdns-sd, anyhow, sysinfo + UI).
Honest framing: this is a diagnostics/transparency feature, not a hashrate gain and not a correctness fix — payouts and share scoring are unchanged. It just makes operations more legible: a noisy miner is immediately attributable instead of guessed. 1039 tests green, svelte-check clean, reproducible build as always.
dvb-WarpPool v1.14.1 — no more false “low difficulty” rejects for small miners (V1 + V2)
A small but targeted patch — triggered by a real measurement on a NerdAxe over Stratum V2.
- The problem. Pools continuously adapt per-miner difficulty (VarDiff). So that a share a miner computed against the slightly older, lower difficulty isn’t lost when the difficulty steps up, there’s a short “grace window” in which the previous target still counts. That window used to hold only one previous target. On small miners the share rate fluctuates a lot statistically (Poisson), and VarDiff then steps up several times in quick succession — a share against a two-steps-old target slipped through and was wrongly counted as a “low difficulty” reject.
- New. The grace window now keeps a ring of the last eight targets. If an incoming share meets any of them (within the 60-second window), it’s accepted instead of rejected. Applies to both protocols, Stratum V1 and V2. Purely additive — with a single retarget everything behaves exactly as before.
- Honest framing. This is not a hashrate gain and not a money matter: block chance is unchanged (found blocks are checked against the network difficulty, entirely separate from this pool-target window), and payouts are untouched. It’s a correctness/robustness improvement: small miners’ reject rate becomes honest again, and the operator isn’t chasing a phantom problem.
How did we find it? We actually measured the cause: a new opt-in diagnostic log (enabled only via RUST_LOG, zero overhead in normal operation) breaks down, per rejected share, how far it was below the current target and whether it would have met a recently valid target. That made it immediately clear these were retarget slip-throughs — not broken hashes.
1044 tests green (including new regression tests “share against a two-steps-old target is accepted” for V1 and V2), svelte-check clean, reproducible build as always.
dvb-WarpPool v1.15.0 — internal security audit (25 findings, all fixed) + a hardened block-submit path
This release is the result of a full internal security and correctness audit: 25 confirmed findings, all fixed — and then re-checked by a deliberately skeptical second review pass (which caught three more real touch-ups). The highlights, framed honestly:
- The big one: the block-submit path. When a miner with version-rolling enabled (overt ASICBoost — practically every modern ASIC, plus NerdAxe/NerdQaxe) finds a block, the header used to be reassembled with the un-rolled version. Result: the submitted hash no longer matched the proof-of-work, Bitcoin Core would reject the block as
high-hash, and the block reward would be lost. Now the block-found event carries the exact rolled version and reconstructs the block from the exact job it was mined on. For V1 and V2. Honest: this was a latent bug — a solo pool rarely finds a block, and there hasn’t been a mainnet block yet — so it was found proactively via the audit and fixed before it could ever bite. It changes nothing about hashrate or block chance; it makes sure a block you do find reliably reaches the chain.
- New & user-facing: dismissable health warnings (GitHub #76**).** The “Bitcoin Core is pruned” notice (and any other node warning) used to come back on every reload. Now each warning in the banner has a “Hide permanently” button (when logged in as admin), and a new Admin → Health page lists what you’ve hidden so you can bring it back. Precise: hiding
bitcoin_pruned silences only that notice — new/other warnings still show. Also seedable via config.toml.
- Further hardening from the audit (operator-relevant): 2FA can no longer be reset without a valid code; a read-only API token can no longer read the node’s RPC password; the LAN miner scan now requires admin auth and stays within private IP ranges; transient RPC errors at block-submit time are now retried instead of being wrongly discarded as an auth error. Plus various smaller robustness fixes (atomic energy accounting, notification escaping, reconnect behavior).
All purely additive, no breaking changes. 1083 tests green (including new regression tests for the version-rolling fix, end-to-end and per protocol), svelte-check clean, reproducible build as always. No “battle-tested” claim, no mainnet block yet.
1 Like
dvb-WarpPool has moved: own forge, own registry — git.warppool.org
New here? dvb-WarpPool is an open-source self-hosted Bitcoin solo mining pool (Rust, full operator web UI/PWA in 8 languages, for NerdMiner alongside Bitaxe alongside Avalon Q). Stratum V1/V2/TLS, signed & reproducible builds, AGPL.
The short version: GitHub permanently suspended our account — the project lives on, now on its own infrastructure.
What happened, factually: GitHub’s abuse review classified the project’s CI usage as “incentivized activities / general computing” — the boilerplate applied to crypto-adjacent projects. For context: our CI only ever built and tested software (Rust builds, docs, signed releases). No mining ever ran in CI. The appeal was finally rejected; repos, issues, releases and Docker images went offline from one moment to the next. That’s GitHub’s prerogative on their platform — but it’s also exactly the risk this project has always preached about mining: if you build on someone else’s infrastructure, you can lose it.
So we did what we preach and self-hosted:
- New home: git.warppool.org/dvb-projekt/dvb-WarpPool — a self-hosted Forgejo instance (open-source forge, EU server) with code, releases and its own Docker registry. No third-party host left that can switch the project off via a classifier.
- Nothing was lost: the complete git history (all branches, all 50 release tags) moved 1:1. You can verify that yourself — git is content-addressed, the commit hashes are identical to before.
- Docker images now come from
git.warppool.org/dvb-projekt/dvb-warppool (multi-arch amd64+arm64, cosign-signed). The old ghcr.io paths are dead.
- Umbrel users — one-time switch required: already-running pools keep running untouched. But the Community Store itself was fetched from GitHub — the old entry can no longer deliver updates or fresh installs. Re-add it once: App Store → three-dot menu → Community App Stores → remove the old dvb-projekt entry (github.com…) → add the new URL:
https://git.warppool.org/dvb-projekt/dvb-projekt-Umbrel-Community-App-Store.git — everything works as before afterwards.
- Homepage: warppool.org — overview, features and all downloads in one place.
- Docs: docs.warppool.org
- Bugs & feedback: file an issue at git.warppool.org/dvb-projekt/dvb-WarpPool/issues — registration is open, new accounts get a quick manual approval (spam protection for a small instance). No account wanted? Email dvbprojekt@gmx.de works too.
What does not change: the license (AGPL + commercial option), signed & reproducible builds (now with a project-held cosign key instead of the GitHub-bound keyless flow — the public key lives in the repo), the release cadence, and the code itself. Honest as always: the move cost us the GitHub metadata (old issues/PRs) and the pending PR for the official Umbrel store — we’ll rebuild both as needed. No “battle-tested” claim, no mainnet block yet — a server move doesn’t change that. 
A Bitcoin project that takes self-sovereignty seriously should run its own forge. Now it does.
Homepage: warppool.org · Code: dvb-projekt/dvb-WarpPool: Bitcoin solo/pool mining server — Stratum V1 + V2 - Forgejo: Beyond coding. We forge. · Docs: docs.warppool.org
dvb-WarpPool v1.16.0: block templates straight from Bitcoin Core — over its IPC interface
New in v1.16.0 — one for the plumbing enthusiasts:
The pool can now pull its block templates directly from Bitcoin Core via Core’s IPC mining interface. Until now (and still, by default) it goes the classic route: getblocktemplate over JSON-RPC plus a ZMQ notification when a new block arrives. That works well — but it’s a detour, and Core’s ZMQ queue can lag noticeably under load.
Bitcoin Core v31 ships a native IPC interface (Cap’n Proto) for exactly this. dvb-WarpPool now optionally speaks it directly instead of RPC+ZMQ. In our own benchmark the pool fetches a fresh template in ~5–12 ms that way versus ~90–100 ms over GBT+ZMQ (the gap is mostly the ZMQ queue lag). For a solo pool that means: after a new block on the network you switch to fresh work a touch sooner — i.e. slightly fewer wasted hashes on a stale template right after a block change. Not a hashrate boost, just cleaner plumbing.
Honest context:
- Off by default. Existing setups keep using GBT unchanged — nothing to do. A clean, shared
TemplateSource trait keeps both paths interchangeable.
- Requires Bitcoin Core v31.0. Still on v30? You keep using GBT — perfectly fine.
- Switching is explicit: Admin → Bitcoin Core has a live GBT ⇄ IPC toggle that probes the socket first and falls back to GBT automatically if it isn’t reachable — no shot in the dark.
- Umbrel: the Bitcoin app has exposed the IPC socket since v1.3.0 (settings toggle “IPC Mining Interface”). The pool mounts Core’s data dir read-only to reach the socket — the store app brings that automatically. Don’t want the IPC exposure at all? Just leave the switch on GBT.
Everything else as usual: same license (AGPL + commercial option), signed & reproducible builds, 1098 tests gating every release in CI. No “battle-tested” claim, no mainnet block yet — still saying that out loud.
Full comparison against ckpool/public-pool/mkpool: Comparison (ckpool / public-pool / mkpool) - dvb-WarpPool
Code & releases: dvb-projekt/dvb-WarpPool: Bitcoin solo/pool mining server — Stratum V1 + V2 - Forgejo: Beyond coding. We forge.
dvb-WarpPool v1.16.1 + v1.16.2 — the IPC switch is now easy to find, and the Umbrel status is correct
New here? dvb-WarpPool is an open-source self-hosted Bitcoin solo mining pool (Rust, full operator web UI/PWA in 8 languages, Stratum V1/V2/TLS, signed & reproducible builds, AGPL). Since the move it runs entirely on its own infrastructure (git.warppool.org / docs.warppool.org).
Two small follow-ups to the optional IPC template backend introduced in v1.16.0 (block templates straight from Bitcoin Core over its IPC interface, Core v31):
v1.16.1 — the switch is now in the navigation. The Admin → Bitcoin Core page (with the GBT ⇄ IPC toggle and the bitcoin.conf editor) existed, but wasn’t linked in the admin navigation — you could only reach it by typing the URL. It now has a “Bitcoin Core” tab (in all 8 UI languages), one click away.
v1.16.2 — the stale “IPC is off” warning on Umbrel clears. If you enabled the IPC toggle after the fact, Umbrel sometimes kept showing “
the Umbrel Bitcoin app reports: IPC mining interface is OFF” — even though IPC was live. Reason: Umbrel sets that variable at container start, so toggling later left the banner stale. It’s now gated on the actual socket test: the moment the test returns OK, the warning is gone. (On older builds, restarting the WarpPool app fixed it.)
Plus a docs-accuracy pass across the whole documentation (cleanly caught up after the move to our own forge).
None of this changes behaviour, protocol, or the API — the test suite is unchanged (1098). Honest as always: no “battle-tested”, no mainnet block yet.
Full comparison vs ckpool/public-pool/mkpool: Comparison (ckpool / public-pool / mkpool) - dvb-WarpPool
Code & releases: dvb-projekt/dvb-WarpPool: Bitcoin solo/pool mining server — Stratum V1 + V2 - Forgejo: Beyond coding. We forge.
dvb-WarpPool v1.16.3 — switch the language and literally EVERYTHING is translated now (8 languages)
New here? dvb-WarpPool is an open-source self-hosted Bitcoin solo mining pool (Rust, full operator web UI/PWA, Stratum V1/V2/TLS, signed & reproducible builds, AGPL). Your miners point at your own host instead of a public pool — find a block and the full reward goes straight to your Bitcoin address. It runs entirely on its own infrastructure (git.warppool.org / docs.warppool.org).
The interface has been available in 8 languages for a while — but three admin pages (API Tokens, Audit Log, Notifications) and the relative timestamps (“just now” / “5m ago”) stubbornly stayed German no matter which language you picked. If you run the pool in Spanish, French, Japanese, Chinese, etc., that was a jarring break.
v1.16.3 cleans that up completely:
- The last German strings are translated. Those three pages, the relative times, various fallback texts, the device auto-scan labels and a handful of status/error messages now all route through the translation system — with real translations in all 8 languages (DE/EN/ES/FR/IT/JA/PT-BR/ZH). Switching language now means the entire interface follows (~130 new strings × 8 languages).
- A CI guard keeps it that way. A new automated check fails the build if (a) the 8 language files don’t share the exact same set of strings, (b) a UI string is added without a translation, or (c) hardcoded German creeps back into the source. So this gap simply can’t return.
- Both end-user manuals (Umbrel + general) were updated accordingly (the “this page is in German” notes are gone, since it’s English now) and given richer screenshots.
None of this changes behaviour, protocol, or the API — pure interface polish, test suite unchanged (1098). Honest as always: no “battle-tested”, no mainnet block yet.
Full comparison vs ckpool/public-pool/mkpool: Comparison (ckpool / public-pool / mkpool) - dvb-WarpPool
Code & releases: dvb-projekt/dvb-WarpPool: Bitcoin solo/pool mining server — Stratum V1 + V2 - Forgejo: Beyond coding. We forge.