-
v1.25.7
StableAll checks were successfulCI / Rust clippy (push) Successful in 1m52sCI / Rust fmt (push) Successful in 1m17sCI / Rust test (push) Successful in 6m2sCI / UI (SvelteKit) (push) Successful in 1m20sCI / Security Audit (push) Successful in 1m23sdocs / build (push) Successful in 36sRelease / Docker Multi-Arch (push) Successful in 22m50sRelease / Binary aarch64-unknown-linux-gnu (push) Successful in 12m15sRelease / Binary x86_64-unknown-linux-gnu (push) Successful in 11m6sRelease / Linux .deb + .rpm (amd64) (push) Successful in 11m52sRelease / Linux .deb + .rpm (arm64) (push) Successful in 12m42sRelease / Linux AppImage (aarch64) (push) Successful in 11m36sRelease / Linux AppImage (x86_64) (push) Successful in 10m41sRelease / Cosign sign artifacts (push) Successful in 26sRelease / Forgejo Release (push) Successful in 38sreleased this
2026-08-14 10:47:46 +00:00 | 0 commits to main since this releaseA hardening release, and a thank-you. Credit where it is due: Distortions of
M45Core / StratumStats read our source and reported the denial-of-service
weakness fixed below — exactly the kind of outside scrutiny an open-source
pool hopes for. Thank you.Fixed
- Rejected-share recording can no longer be used to overwhelm the pool.
Every rejected share used to spawn its own detached task that immediately
wrote to SQLite. Junk shares arrive at wire speed on an already-authorized
connection — submit has no rate limit (connect and auth do) — so an
attacker sending stale or invalid shares could pile up unbounded tasks at
the database writer. A rejected share now costs two in-memory counter
increments; a daemon loop flushes the coalesced deltas every 2 seconds as
a single transaction (final flush on shutdown, re-queue on flush errors).
Both Stratum V1 and V2 feed the same buffer. Buffer memory is bounded by
the auth rate limit. The stratum-v1 module doc also claimed submit was
rate-limited; it never was — the doc now describes the real protections. - The 60-second network-stats poll no longer trips over Bitcoin Core's
connection timeout. Core closes idle RPC connections after 30 s
(rpcservertimeout); our HTTP pool kept them for 90 s, so every
getmininginfopoll landed on a dead socket, failed, and burned a retry
(~500 warnings/day on the reference deployment). Pooled connections are
now dropped after 20 s. No correctness impact — the retry always
recovered, including forsubmitblock— just a wasted round trip and a
noisy log, both gone.
dvb-WarpPool v1.25.7 — Downloads
Docker
git.warppool.org/dvb-projekt/dvb-warppool:v1.25.7(multi-arch amd64+arm64, ohne v-Präfix)Native packages
- Linux .deb: amd64 + arm64 →
apt install ./dvb-warppool_*.deb - Linux .rpm: amd64 + arm64 →
dnf install ./dvb-warppool-*.rpm - Linux AppImage: x86_64 + aarch64 portable
- Linux tarballs: x86_64 + aarch64 for manual installs
- macOS .dmg: added shortly after publish (built separately) — or build from source
- Windows .msi: paused since the forge migration (no Windows runner yet)
Signatures
SHA256SUMS+ cosign bundle (SHA256SUMS.bundle, project key)- SBOM (SPDX) for all dependencies
Verify (project public key
cosign.pubin the repo root):cosign verify-blob \ --key cosign.pub \ --bundle SHA256SUMS.bundle \ SHA256SUMS sha256sum --check SHA256SUMSFirst-time setup: run
dvb-warppool-setupfor the first-run wizard.Downloads
-
Source code (ZIP)
2 downloads
-
Source code (TAR.GZ)
2 downloads
- Rejected-share recording can no longer be used to overwhelm the pool.
-
v1.25.6
StableAll checks were successfulCI / Rust clippy (push) Successful in 2m7sCI / Rust fmt (push) Successful in 1m12sCI / Rust test (push) Successful in 5m59sCI / UI (SvelteKit) (push) Successful in 1m13sCI / Security Audit (push) Successful in 1m22sdocs / build (push) Successful in 33sRelease / Docker Multi-Arch (push) Successful in 22m6sRelease / Binary aarch64-unknown-linux-gnu (push) Successful in 12m23sRelease / Binary x86_64-unknown-linux-gnu (push) Successful in 11m3sRelease / Linux .deb + .rpm (amd64) (push) Successful in 11m54sRelease / Linux .deb + .rpm (arm64) (push) Successful in 14m41sRelease / Linux AppImage (aarch64) (push) Successful in 12m35sRelease / Linux AppImage (x86_64) (push) Successful in 11m19sRelease / Cosign sign artifacts (push) Successful in 23sRelease / Forgejo Release (push) Successful in 33sreleased this
2026-08-10 12:08:33 +00:00 | 3 commits to main since this releaseHonest numbers, and no more steering miners away from a perfectly good TLS
port. Both changes fall out of the pool being listed on a public pool
directory: the listing's probe traffic was inflating our public counters, and
the connect dialog was warning against a TLS endpoint that independent
measurement had just rated our best.Fixed
- Worker and wallet totals now count only workers that ever submitted an
accepted share. Pool-directory probes connect on every check with a
freshly generated throwaway address and never submit work — on the
reference deployment that had grown the public counters to 203 workers /
181 wallets, of which only 31 / 9 ever mined. Share sums are unchanged and
still include rejects from zero-accept workers. - The connect dialog no longer shows the self-signed warning when the TLS
certificate is CA-signed. The daemon reports the certificate's signing
state in/api/overview(re-checked per request, so a cert swapped by an
ACME renewal is picked up without a restart), and the dialog now tells
firmwares with a public CA store that no extra file is needed — instead of
sending them to the plaintext port. Self-signed setups keep the existing
warning and certificate download. New hint translated in all 8 languages.
Added
retention.workers_inert_secs(default 7 days): worker rows that never
submitted a single share — accepted or rejected — are evicted after this
short window instead of sitting out the 90-dayworkers_secs. A real miner
stops being inert with its first share; a misconfigured miner whose shares
are all rejected stays visible for debugging. Documented in the
configuration reference, together with a connection-endpoints table in the
public-pool guide.
dvb-WarpPool v1.25.6 — Downloads
Docker
git.warppool.org/dvb-projekt/dvb-warppool:v1.25.6(multi-arch amd64+arm64, ohne v-Präfix)Native packages
- Linux .deb: amd64 + arm64 →
apt install ./dvb-warppool_*.deb - Linux .rpm: amd64 + arm64 →
dnf install ./dvb-warppool-*.rpm - Linux AppImage: x86_64 + aarch64 portable
- Linux tarballs: x86_64 + aarch64 for manual installs
- macOS .dmg: added shortly after publish (built separately) — or build from source
- Windows .msi: paused since the forge migration (no Windows runner yet)
Signatures
SHA256SUMS+ cosign bundle (SHA256SUMS.bundle, project key)- SBOM (SPDX) for all dependencies
Verify (project public key
cosign.pubin the repo root):cosign verify-blob \ --key cosign.pub \ --bundle SHA256SUMS.bundle \ SHA256SUMS sha256sum --check SHA256SUMSFirst-time setup: run
dvb-warppool-setupfor the first-run wizard.Downloads
-
Source code (ZIP)
0 downloads
-
Source code (TAR.GZ)
0 downloads
- Worker and wallet totals now count only workers that ever submitted an
-
v1.25.5
StableAll checks were successfulCI / Rust clippy (push) Successful in 1m40sCI / Rust fmt (push) Successful in 1m13sCI / Rust test (push) Successful in 5m34sCI / UI (SvelteKit) (push) Successful in 1m12sCI / Security Audit (push) Successful in 1m31sdocs / build (push) Successful in 35sRelease / Docker Multi-Arch (push) Successful in 20m20sRelease / Binary aarch64-unknown-linux-gnu (push) Successful in 10m56sRelease / Binary x86_64-unknown-linux-gnu (push) Successful in 10m10sRelease / Linux .deb + .rpm (amd64) (push) Successful in 10m59sRelease / Linux .deb + .rpm (arm64) (push) Successful in 11m51sRelease / Linux AppImage (aarch64) (push) Successful in 10m57sRelease / Linux AppImage (x86_64) (push) Successful in 10m8sRelease / Cosign sign artifacts (push) Successful in 28sRelease / Forgejo Release (push) Successful in 36sreleased this
2026-08-02 08:41:25 +00:00 | 7 commits to main since this releaseThe answer to "why do my Stratum V2 miners sit at 2-4% rejects?" — plus the
reason their connections kept dying. Both verified against the live miners
before tagging: nine block changes without a single reject (previously every
one produced a burst, 9.6 on average), and 75 minutes without one connection
abort (previously five in 68 minutes).Fixed
- Block-change jobs are now future jobs, activated by
SetNewPrevHash.
Every Sv2 job went out as "mine immediately" (min_ntimeset) followed
unconditionally by aSetNewPrevHash. Per spec, "immediately" means against
the prev hash the miner currently knows — on a block change, the old one.
Spec-conformant firmware therefore hashed the new merkle root against the
stale tip until the next 30-second refresh tick, and every one of those
shares came back as low-difficulty. Measured live: all 60 rejects in a
50-minute window sat within 90 seconds of a block change, median 16 s. Now
a block change ships the job as future (min_ntimeempty) and the
SetNewPrevHashactivates it; a template refresh ships an immediately
active job and noSetNewPrevHashat all (sending one there was itself
off-spec). The daemon'sclean_jobsflag — which V1 has always received —
now reaches the Sv2 path too. Stratum V1 never had this problem: its
mining.notifycarries the prev hash inside the job. - Sv2 connections no longer die with
Noise(Aead("Error")). The
encrypted-frame reader had two await points with an AEAD-nonce advance
between them, running insidetokio::select!— and every other branch
firing (the VarDiff idle tick, a job broadcast, a V1 line in the
translator) cancels the in-flight read. If that landed while a frame was
only partially received, the reader lost stream bytes or treated payload
ciphertext as a fresh header, the next tag check failed, and the connection
died — live, sessions lasted anywhere from 2 to 67 minutes, costing the
miner its in-flight work each time. The reader is now cancellation-safe:
bytes land in a persistent buffer, and decryption happens only once the
complete record is buffered. Both the server loop and the translator's
client use it. - The V1↔V2 translator understands future jobs. It paired job and prev
hash strictly by job id, which only ever matched because every push carried
a freshSetNewPrevHash. It now pairs an immediately-active job with the
latest known prev hash and takes its ntime from the job — without this,
refreshes would have stopped reaching V1 miners behind the translator.
Added
- Opt-in diagnostics behind the existing
lowdiff_diaglog target: rejected
shares are re-checked against every job in the history, and every job push
logs the history decision (new_block, ring length, prev-hash heads).
These two lines are how both bugs above were found.
dvb-WarpPool v1.25.5 — Downloads
Docker
git.warppool.org/dvb-projekt/dvb-warppool:v1.25.5(multi-arch amd64+arm64, ohne v-Präfix)Native packages
- Linux .deb: amd64 + arm64 →
apt install ./dvb-warppool_*.deb - Linux .rpm: amd64 + arm64 →
dnf install ./dvb-warppool-*.rpm - Linux AppImage: x86_64 + aarch64 portable
- Linux tarballs: x86_64 + aarch64 for manual installs
- macOS .dmg: added shortly after publish (built separately) — or build from source
- Windows .msi: paused since the forge migration (no Windows runner yet)
Signatures
SHA256SUMS+ cosign bundle (SHA256SUMS.bundle, project key)- SBOM (SPDX) for all dependencies
Verify (project public key
cosign.pubin the repo root):cosign verify-blob \ --key cosign.pub \ --bundle SHA256SUMS.bundle \ SHA256SUMS sha256sum --check SHA256SUMSFirst-time setup: run
dvb-warppool-setupfor the first-run wizard.Downloads
-
Source code (ZIP)
0 downloads
-
Source code (TAR.GZ)
1 download
- Block-change jobs are now future jobs, activated by
-
v1.25.4
StableAll checks were successfulCI / Rust clippy (push) Successful in 1m38sCI / Rust fmt (push) Successful in 1m9sCI / Rust test (push) Successful in 5m23sCI / UI (SvelteKit) (push) Successful in 1m10sCI / Security Audit (push) Successful in 1m19sdocs / build (push) Successful in 35sRelease / Docker Multi-Arch (push) Successful in 20m21sRelease / Binary aarch64-unknown-linux-gnu (push) Successful in 10m59sRelease / Binary x86_64-unknown-linux-gnu (push) Successful in 9m55sRelease / Linux .deb + .rpm (amd64) (push) Successful in 10m54sRelease / Linux .deb + .rpm (arm64) (push) Successful in 11m58sRelease / Linux AppImage (aarch64) (push) Successful in 11m13sRelease / Linux AppImage (x86_64) (push) Successful in 10m3sRelease / Cosign sign artifacts (push) Successful in 26sRelease / Forgejo Release (push) Successful in 37sreleased this
2026-08-01 13:19:43 +00:00 | 11 commits to main since this releaseSame fix as 1.25.3, this time without breaking every Stratum V1 miner.
Fixed
-
The coinbase extranonce gap is now split per protocol. 1.25.3 widened
extranonce2from 4 to 8 bytes for both protocols at once. V1 firmware
generates those bytes itself and ignores theextranonce2_sizefrom the
subscribe reply, so it kept sending 4 — andshare-validatorthrew out every
one of its shares asmalformed. The 12-byte gap was never the problem;
dividing it identically for both protocols was. Only the sum has to match:pool miner total Stratum V1 extranonce18extranonce2412 Stratum V2 prefix 4 8 12 V1 miners therefore see exactly the four bytes they always saw — the growth
is absorbed by the pool's own share, which the miner only passes through.
Sv2 keeps the room a NerdQAxe asks for, so the coinbase no longer outgrows
its own scriptSig length field (the 1.25.3 fix, retained).EXTRANONCE1_SIZE
and the Sv2 channel prefix are now deliberately separate constants, each
warning about the other, because conflating them is what caused this.
Verified against the live miners for 22 minutes before tagging: no malformed
shares, and the reject rate matches 1.25.2 once VarDiff has settled.
dvb-WarpPool v1.25.4 — Downloads
Docker
git.warppool.org/dvb-projekt/dvb-warppool:v1.25.4(multi-arch amd64+arm64, ohne v-Präfix)Native packages
- Linux .deb: amd64 + arm64 →
apt install ./dvb-warppool_*.deb - Linux .rpm: amd64 + arm64 →
dnf install ./dvb-warppool-*.rpm - Linux AppImage: x86_64 + aarch64 portable
- Linux tarballs: x86_64 + aarch64 for manual installs
- macOS .dmg: added shortly after publish (built separately) — or build from source
- Windows .msi: paused since the forge migration (no Windows runner yet)
Signatures
SHA256SUMS+ cosign bundle (SHA256SUMS.bundle, project key)- SBOM (SPDX) for all dependencies
Verify (project public key
cosign.pubin the repo root):cosign verify-blob \ --key cosign.pub \ --bundle SHA256SUMS.bundle \ SHA256SUMS sha256sum --check SHA256SUMSFirst-time setup: run
dvb-warppool-setupfor the first-run wizard.Downloads
-
Source code (ZIP)
0 downloads
-
Source code (TAR.GZ)
0 downloads
-
-
v1.25.3 — WITHDRAWN, do not install
Pre-releaseAll checks were successfulCI / Rust clippy (push) Successful in 2m6sCI / Rust fmt (push) Successful in 1m11sCI / Rust test (push) Successful in 5m29sCI / UI (SvelteKit) (push) Successful in 1m15sCI / Security Audit (push) Successful in 1m23sRelease / Docker Multi-Arch (push) Successful in 20m7sRelease / Binary aarch64-unknown-linux-gnu (push) Successful in 11m8sRelease / Binary x86_64-unknown-linux-gnu (push) Successful in 9m55sRelease / Linux .deb + .rpm (amd64) (push) Successful in 10m41sRelease / Linux .deb + .rpm (arm64) (push) Successful in 11m43sRelease / Linux AppImage (aarch64) (push) Successful in 10m48sRelease / Linux AppImage (x86_64) (push) Successful in 9m49sdocs / build (push) Successful in 34sRelease / Cosign sign artifacts (push) Successful in 25sRelease / Forgejo Release (push) Successful in 36sreleased this
2026-08-01 09:22:51 +00:00 | 13 commits to main since this releaseCaution
Withdrawn — do not install this version
v1.25.3 rejected every share from Stratum V1 miners as malformed. If you
mine with a Bitaxe, NerdMiner, NerdAxe or any other V1 device, this build
throws away all of their work. It was withdrawn on 2026-08-01, a few hours
after it was published.Use v1.25.4
or later. It carries the same Stratum V2 coinbase fix, with the V1 side kept
intact — the two protocols now split the extranonce gap differently instead of
sharing one layout.The downloads and the container image tag
1.25.3have been removed so this
build cannot be installed by accident. The original notes are kept below for
the record.
A Stratum V2 miner asking for more extranonce room than the coinbase had could
produce a block the network would reject. Found while chasing something else.Fixed
- The Sv2 extranonce now fits the coinbase gap exactly — a block found by a
NerdQAxe-class miner would previously have been rejected by the network. An
extended channel handed the miner back whatever size it asked for, checked
only against a 1..16 range and never against the gap the job was actually
built for. Per the specmin_extranonce_sizeis only the miner's lower bound;
the pool sets the real size in its reply. A NerdQAxe asks for 6, the pool's
own prefix takes 4, and the gap held 8 — ten bytes into an eight-byte hole.
The coinbase then came out two bytes longer than its own scriptSig length
field claims, which makes it an invalid transaction: Bitcoin Core's
decoderawtransactionrefuses those exact bytes. Shares were unaffected,
because the miner and the pool concatenate the same way and therefore agree on
the hash — the damage would only have surfaced on a block find, when that
coinbase goes tosubmitblock. Stratum V1 was never exposed: it has always
rejected anextranonce2whose length is not exactlyextranonce2_size. extranonce2grows from 4 to 8 bytes, so the gap is now 12 and miners
asking for 6 fit. Without this, behaving correctly would have meant refusing
those miners outright. V1 miners see the new size in themining.subscribe
reply and adopt it automatically; Sv2 miners get it when they open a channel.- The extranonce sizes are now one constant (
EXTRANONCE1_SIZE,
EXTRANONCE2_SIZE,EXTRANONCE_TOTAL_SIZEinjob-builder) instead of a
literal4, 4repeated across the daemon and the V1 server config. The two
always had to agree; now that is enforced rather than remembered. The share
reconstruction additionally refuses to build a coinbase whose parts do not sum
to the gap — the same guard V1 has had all along.
Added
- Diagnostic: a rejected low-difficulty share is now rebuilt against every job
in the history, not just the one the miner named, behind the existing opt-in
lowdiff_diaglog target. It reports whether another job would have made the
share valid — which separates a misfiled job from a genuine mismatch, two
cases that previously looked identical in the log. Never runs on the accept
path.
dvb-WarpPool v1.25.3 — Downloads
Docker
git.warppool.org/dvb-projekt/dvb-warppool:v1.25.3(multi-arch amd64+arm64, ohne v-Präfix)Native packages
- Linux .deb: amd64 + arm64 →
apt install ./dvb-warppool_*.deb - Linux .rpm: amd64 + arm64 →
dnf install ./dvb-warppool-*.rpm - Linux AppImage: x86_64 + aarch64 portable
- Linux tarballs: x86_64 + aarch64 for manual installs
- macOS .dmg: added shortly after publish (built separately) — or build from source
- Windows .msi: paused since the forge migration (no Windows runner yet)
Signatures
SHA256SUMS+ cosign bundle (SHA256SUMS.bundle, project key)- SBOM (SPDX) for all dependencies
Verify (project public key
cosign.pubin the repo root):cosign verify-blob \ --key cosign.pub \ --bundle SHA256SUMS.bundle \ SHA256SUMS sha256sum --check SHA256SUMSFirst-time setup: run
dvb-warppool-setupfor the first-run wizard.Downloads
-
Source code (ZIP)
0 downloads
-
Source code (TAR.GZ)
0 downloads
- The Sv2 extranonce now fits the coinbase gap exactly — a block found by a
-
v1.25.2
StableAll checks were successfulCI / Rust clippy (push) Successful in 1m42sCI / Rust fmt (push) Successful in 1m13sCI / Rust test (push) Successful in 5m32sCI / UI (SvelteKit) (push) Successful in 1m11sCI / Security Audit (push) Successful in 1m18sdocs / build (push) Successful in 37sRelease / Docker Multi-Arch (push) Successful in 20m24sRelease / Binary aarch64-unknown-linux-gnu (push) Successful in 11m3sRelease / Binary x86_64-unknown-linux-gnu (push) Successful in 9m55sRelease / Linux .deb + .rpm (amd64) (push) Successful in 10m51sRelease / Linux .deb + .rpm (arm64) (push) Successful in 11m55sRelease / Linux AppImage (aarch64) (push) Successful in 10m54sRelease / Linux AppImage (x86_64) (push) Successful in 9m54sRelease / Cosign sign artifacts (push) Successful in 1m20sRelease / Forgejo Release (push) Successful in 36sreleased this
2026-07-31 10:42:26 +00:00 | 19 commits to main since this releaseA phone-sized fix: the connect dialog can be scrolled again.
Fixed
- The connect dialog now scrolls when it is taller than the screen. On a
phone it could not be scrolled at all, and the lower half — the username
format, the password and the hint below them — was simply unreachable. The
dialog had neither a height cap nor a scroll area of its own, and it sits in a
centred overlay that is pinned to the viewport, so content taller than the
screen ran off the top and the bottom at once: you saw the middle with both
ends cut off and nothing to scroll. It now caps at the screen height and
scrolls inside, measured against the browser's visible area rather than the
nominal one, so on iOS the last row no longer hides behind the collapsing
toolbar. Unchanged on a desktop-sized window, where the dialog fits anyway.
Reported by Oliver from an Umbrel box on an iPhone.
dvb-WarpPool v1.25.2 — Downloads
Docker
git.warppool.org/dvb-projekt/dvb-warppool:v1.25.2(multi-arch amd64+arm64, ohne v-Präfix)Native packages
- Linux .deb: amd64 + arm64 →
apt install ./dvb-warppool_*.deb - Linux .rpm: amd64 + arm64 →
dnf install ./dvb-warppool-*.rpm - Linux AppImage: x86_64 + aarch64 portable
- Linux tarballs: x86_64 + aarch64 for manual installs
- macOS .dmg: added shortly after publish (built separately) — or build from source
- Windows .msi: paused since the forge migration (no Windows runner yet)
Signatures
SHA256SUMS+ cosign bundle (SHA256SUMS.bundle, project key)- SBOM (SPDX) for all dependencies
Verify (project public key
cosign.pubin the repo root):cosign verify-blob \ --key cosign.pub \ --bundle SHA256SUMS.bundle \ SHA256SUMS sha256sum --check SHA256SUMSFirst-time setup: run
dvb-warppool-setupfor the first-run wizard.Downloads
-
Source code (ZIP)
0 downloads
-
Source code (TAR.GZ)
0 downloads
- The connect dialog now scrolls when it is taller than the screen. On a
-
v1.25.1
StableAll checks were successfulRelease / Docker Multi-Arch (push) Successful in 20m48sRelease / Binary aarch64-unknown-linux-gnu (push) Successful in 11m9sRelease / Binary x86_64-unknown-linux-gnu (push) Successful in 10m4sRelease / Linux .deb + .rpm (amd64) (push) Successful in 10m52sRelease / Linux .deb + .rpm (arm64) (push) Successful in 11m46sRelease / Linux AppImage (aarch64) (push) Successful in 11m4sRelease / Linux AppImage (x86_64) (push) Successful in 10m4sCI / Rust clippy (push) Successful in 1m45sCI / Rust fmt (push) Successful in 1m10sCI / Rust test (push) Successful in 5m29sCI / UI (SvelteKit) (push) Successful in 1m12sCI / Security Audit (push) Successful in 1m18sdocs / build (push) Successful in 33sRelease / Cosign sign artifacts (push) Successful in 24sRelease / Forgejo Release (push) Successful in 35sreleased this
2026-07-31 08:11:15 +00:00 | 21 commits to main since this releaseTwo Sv2 miners now really do give you twice the coverage — and the connect
dialog finally says which channel type to pick.Added
- The connect dialog now answers the standard-vs-extended channel question.
It was the most common follow-up about Stratum V2, and the one place a miner
looks for it said nothing. A line under the Sv2 address recommends an
extended channel for this pool and says why: the pool hands over the
coinbase halves and the merkle path with every job, so the miner can check
for itself what it is hashing and that the reward output is the one it
configured. On a standard channel it gets a finished merkle root and has to
take the pool's word for it — which is why standard is the right pick only
when the Sv2 endpoint is a node the miner runs itself. In all eight UI
languages. The manuals carry the same explanation plus the honest
counter-argument (extended costs bigger jobs and per-job merkle work on a
small MCU), and the troubleshooting chapter gained a full entry with the
comparison table and the per-firmware specifics: in AxeOS the choice appears
as SV2 Channel Type once the pool is set to V2, a Bitaxe Max (BM1397)
cannot use standard channels at all, and NerdQAxe firmware currently opens an
extended channel regardless of the setting.
Fixed
- Every Stratum V2 connection now gets its own extranonce prefix. The
prefix counter lived on the per-connection channel registry, which starts at
zero every time, so the first channel of every connection was handed
00 00 00 00. Several directly connected Sv2 miners therefore searched one
and the same extranonce space: they found the same shares, and their work
overlapped instead of splitting. Nothing was lost or unsafe — the shares were
real work — but two miners did not give you twice the coverage. Stratum V1 was
never affected; its counter has always been global. Anyone running more than
one Sv2 miner should update. Found and reported by John11, who noticed
that several of his miners kept showing the same best-share difficulty and
suspected they were being given identical work. He was right, and the report
was precise enough to find it in a morning.
dvb-WarpPool v1.25.1 — Downloads
Docker
git.warppool.org/dvb-projekt/dvb-warppool:v1.25.1(multi-arch amd64+arm64, ohne v-Präfix)Native packages
- Linux .deb: amd64 + arm64 →
apt install ./dvb-warppool_*.deb - Linux .rpm: amd64 + arm64 →
dnf install ./dvb-warppool-*.rpm - Linux AppImage: x86_64 + aarch64 portable
- Linux tarballs: x86_64 + aarch64 for manual installs
- macOS .dmg: added shortly after publish (built separately) — or build from source
- Windows .msi: paused since the forge migration (no Windows runner yet)
Signatures
SHA256SUMS+ cosign bundle (SHA256SUMS.bundle, project key)- SBOM (SPDX) for all dependencies
Verify (project public key
cosign.pubin the repo root):cosign verify-blob \ --key cosign.pub \ --bundle SHA256SUMS.bundle \ SHA256SUMS sha256sum --check SHA256SUMSFirst-time setup: run
dvb-warppool-setupfor the first-run wizard.Downloads
-
Source code (ZIP)
0 downloads
-
Source code (TAR.GZ)
0 downloads
- The connect dialog now answers the standard-vs-extended channel question.
-
v1.25.0
StableAll checks were successfulCI / Rust clippy (push) Successful in 1m51sCI / Rust fmt (push) Successful in 1m13sCI / Rust test (push) Successful in 5m57sCI / UI (SvelteKit) (push) Successful in 1m15sCI / Security Audit (push) Successful in 1m22sdocs / build (push) Successful in 40sRelease / Docker Multi-Arch (push) Successful in 21m52sRelease / Binary aarch64-unknown-linux-gnu (push) Successful in 11m28sRelease / Binary x86_64-unknown-linux-gnu (push) Successful in 10m15sRelease / Linux .deb + .rpm (amd64) (push) Successful in 11m8sRelease / Linux .deb + .rpm (arm64) (push) Successful in 12m7sRelease / Linux AppImage (aarch64) (push) Successful in 11m6sRelease / Linux AppImage (x86_64) (push) Successful in 10m11sRelease / Cosign sign artifacts (push) Successful in 27sRelease / Forgejo Release (push) Successful in 37sreleased this
2026-07-29 16:50:26 +00:00 | 27 commits to main since this releaseA way out of the pool UI to the project site.
Added
- A link from the pool UI to the project site. Until now there was no way
out: the wordmark points at the dashboard, and every other outbound link
leads to the forge or the documentation. Two unobtrusive places now carry
it. The footer's middle cell credits the software as "Powered by
dvb-WarpPool" and links there — deliberately not the operator's brand name
on the left, which on someone else's installation is a different thing
entirely and would otherwise be the same link twice. That left cell now
stays empty when the operator kept the default brand name, since the credit
beside it already says the same word. The connect dialog gets one line
under the credentials, at the moment a newcomer is most curious what this
actually is. "Powered by" stays English in all eight locales — it reads as
a fixed footer formula internationally.
dvb-WarpPool v1.25.0 — Downloads
Docker
git.warppool.org/dvb-projekt/dvb-warppool:v1.25.0(multi-arch amd64+arm64, ohne v-Präfix)Native packages
- Linux .deb: amd64 + arm64 →
apt install ./dvb-warppool_*.deb - Linux .rpm: amd64 + arm64 →
dnf install ./dvb-warppool-*.rpm - Linux AppImage: x86_64 + aarch64 portable
- Linux tarballs: x86_64 + aarch64 for manual installs
- macOS .dmg: added shortly after publish (built separately) — or build from source
- Windows .msi: paused since the forge migration (no Windows runner yet)
Signatures
SHA256SUMS+ cosign bundle (SHA256SUMS.bundle, project key)- SBOM (SPDX) for all dependencies
Verify (project public key
cosign.pubin the repo root):cosign verify-blob \ --key cosign.pub \ --bundle SHA256SUMS.bundle \ SHA256SUMS sha256sum --check SHA256SUMSFirst-time setup: run
dvb-warppool-setupfor the first-run wizard.Downloads
-
Source code (ZIP)
1 download
-
Source code (TAR.GZ)
1 download
- A link from the pool UI to the project site. Until now there was no way
-
v1.24.0
StableAll checks were successfulCI / Rust clippy (push) Successful in 1m38sCI / Rust fmt (push) Successful in 1m11sCI / Rust test (push) Successful in 5m20sCI / UI (SvelteKit) (push) Successful in 1m10sCI / Security Audit (push) Successful in 1m21sdocs / build (push) Successful in 37sRelease / Docker Multi-Arch (push) Successful in 19m46sRelease / Binary aarch64-unknown-linux-gnu (push) Successful in 10m44sRelease / Binary x86_64-unknown-linux-gnu (push) Successful in 9m36sRelease / Linux .deb + .rpm (amd64) (push) Successful in 10m27sRelease / Linux .deb + .rpm (arm64) (push) Successful in 11m19sRelease / Linux AppImage (aarch64) (push) Successful in 10m27sRelease / Linux AppImage (x86_64) (push) Successful in 9m30sRelease / Cosign sign artifacts (push) Successful in 34sRelease / Forgejo Release (push) Successful in 35sreleased this
2026-07-24 11:04:07 +00:00 | 32 commits to main since this releaseTaproot wallets can prove ownership now.
Added
- BIP-322 ownership verification for Taproot (bc1p) addresses. The owner
area — the privacy toggle and per-address notification target (including the
new personal-best / top-100 moment pushes) — is unlocked by proving control
of the payout address with a signed message, no account, no funds moved. That
proof only had a format for legacy and SegWit-v0 addresses (BIP-137), so
Taproot addresses could mine but never unlock it. They now verify via BIP-322
"simple" (key-path), the format Sparrow produces for Taproot. Dispatch is
strict by address type: a P2TR address is checked only via BIP-322, every
other type only via BIP-137 — no cross-accept. The Schnorr check runs solely
against the output key taken from the claimed address, and both the message
and the address are bound into the signature's sighash, so a signature can
never be replayed across addresses or messages. Only a single-element key-path
witness (SIGHASH_DEFAULT or ALL) is accepted; script-path, annex, and weaker
sighash types are rejected. The owner-area hints now name a BIP-322-capable
wallet (Sparrow) for Taproot in all eight languages.
dvb-WarpPool v1.24.0 — Downloads
Docker
git.warppool.org/dvb-projekt/dvb-warppool:v1.24.0(multi-arch amd64+arm64, ohne v-Präfix)Native packages
- Linux .deb: amd64 + arm64 →
apt install ./dvb-warppool_*.deb - Linux .rpm: amd64 + arm64 →
dnf install ./dvb-warppool-*.rpm - Linux AppImage: x86_64 + aarch64 portable
- Linux tarballs: x86_64 + aarch64 for manual installs
- macOS .dmg: added shortly after publish (built separately) — or build from source
- Windows .msi: paused since the forge migration (no Windows runner yet)
Signatures
SHA256SUMS+ cosign bundle (SHA256SUMS.bundle, project key)- SBOM (SPDX) for all dependencies
Verify (project public key
cosign.pubin the repo root):cosign verify-blob \ --key cosign.pub \ --bundle SHA256SUMS.bundle \ SHA256SUMS sha256sum --check SHA256SUMSFirst-time setup: run
dvb-warppool-setupfor the first-run wizard.Downloads
-
Source code (ZIP)
0 downloads
-
Source code (TAR.GZ)
0 downloads
- BIP-322 ownership verification for Taproot (bc1p) addresses. The owner
-
v1.23.0
StableAll checks were successfulRelease / Docker Multi-Arch (push) Successful in 19m53sRelease / Binary aarch64-unknown-linux-gnu (push) Successful in 10m56sRelease / Binary x86_64-unknown-linux-gnu (push) Successful in 9m34sRelease / Linux .deb + .rpm (amd64) (push) Successful in 10m27sRelease / Linux .deb + .rpm (arm64) (push) Successful in 11m37sRelease / Linux AppImage (aarch64) (push) Successful in 10m38sRelease / Linux AppImage (x86_64) (push) Successful in 9m31sCI / Rust clippy (push) Successful in 1m40sCI / Rust fmt (push) Successful in 1m11sCI / Rust test (push) Successful in 5m15sCI / UI (SvelteKit) (push) Successful in 1m9sCI / Security Audit (push) Successful in 1m18sdocs / build (push) Successful in 34sRelease / Cosign sign artifacts (push) Successful in 27sRelease / Forgejo Release (push) Successful in 35sreleased this
2026-07-24 06:51:00 +00:00 | 35 commits to main since this releaseThe pool tells you the truth, and celebrates the moments.
Added
- Honest odds panel on the public wallet page. The old "Est. time to block"
tile showed a single mean ("~12,000 years") — the average of an exponential
distribution presented as a forecast, which reads as "never" and hides the one
property that makes solo mining rational: it is memoryless. The wallet page
(/users/<address>) now shows the real distribution instead — chance in the
next 24 hours, chance within a year, the 50/50 point, and an honest "luck so
far" line (expected blocks from your accepted work, and the probability a
miner with your history would still have none). Odds under 1 % render as
"1 in N", percentages are floored (never rounded past their true value), and a
memorylessness footnote ships in all eight locales. All probabilities are
computed server-side by a tested Poisson kernel and exposed as anodds
object on/api/users/{address}(null when the wallet is offline). The
expected-blocks figure is fed by a new tiny per-wallet accumulator
(wallet_lifetime) written batched alongside the existing aggregation, so it
stays correct across difficulty retargets. - Moment notifications for verified wallets. Solo mining lives on three
moments; the pool pushed only one (block found). Wallets with a verified
notify_targetnow also get a push when they set a new personal best share
(across all their rigs, not per-rig) and when they first enter the pool's
all-time top 100 — a genuine entry only (the leaderboard was already full and
the address held no prior spot; climbing higher does not re-fire). Each moment
has its own per-address cooldown (30 min personal-best, 60 min top-100) to
avoid spam, and block shares suppress the moment pushes so a found block is a
single headline, not three messages. No new configuration — this rides the
existing owner-verified notification target.
dvb-WarpPool v1.23.0 — Downloads
Docker
git.warppool.org/dvb-projekt/dvb-warppool:v1.23.0(multi-arch amd64+arm64, ohne v-Präfix)Native packages
- Linux .deb: amd64 + arm64 →
apt install ./dvb-warppool_*.deb - Linux .rpm: amd64 + arm64 →
dnf install ./dvb-warppool-*.rpm - Linux AppImage: x86_64 + aarch64 portable
- Linux tarballs: x86_64 + aarch64 for manual installs
- macOS .dmg: added shortly after publish (built separately) — or build from source
- Windows .msi: paused since the forge migration (no Windows runner yet)
Signatures
SHA256SUMS+ cosign bundle (SHA256SUMS.bundle, project key)- SBOM (SPDX) for all dependencies
Verify (project public key
cosign.pubin the repo root):cosign verify-blob \ --key cosign.pub \ --bundle SHA256SUMS.bundle \ SHA256SUMS sha256sum --check SHA256SUMSFirst-time setup: run
dvb-warppool-setupfor the first-run wizard.Downloads
-
Source code (ZIP)
0 downloads
-
Source code (TAR.GZ)
0 downloads
- Honest odds panel on the public wallet page. The old "Est. time to block"