-
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.