Version 0.8.26.12 Stops Silent Block Loss

Version 0.8.26.12 closes a way a real solved block could have been lost in silence. Six fixes went out in this release. The one that matters most is the one in the title, so we're leading with it, then covering the other five in the order they appear in the changelog.

The short version: some mining firmware sends back its entire version field on a share submission instead of just the portion the pool allotted it. The pool used to reject those submissions outright, before the code that checks whether a submission solved a block ever got a chance to run. If one of those rejected submissions happened to be a real winner, it would have been thrown away without a trace. That's fixed now. The other five fixes cover visibility into rejected shares, a connection-limit gap on two chains, a dashboard safety warning, and two pieces of Stratum V2 protocol hygiene.

A solo pool exists to catch the block a rig finds and make sure it gets credit for it. A bug that can eat a winning submission without leaving a trace is about as serious as a bug gets here. The earlier a win disappears in the pipeline, the harder it becomes for anyone, on either side of the connection, to ever prove it happened at all. That's what makes the fix below the headline of this release, and why the other five, smaller as they are, are worth walking through in the same level of detail.

Here's all six at a glance:

Fix	Before	After
Version-bits block-loss	A winning submission with full version bits could be silently discarded	Header is rebuilt and validated, then checked for a solved block
Malformed-submit visibility	Bad submissions errored on the wire but left no trace in stats	Now counted as rejected shares, visible to both sides
LTC/DOGE connection limits	No per-address connection cap on this endpoint	Same limits BTC and BCH already enforce
Voltage regulator advisory	Reading was collected and shown, never compared to a threshold	Dashboard now warns when it runs hot
Silent SV2 message drops	Two outbound message failures returned with no record	Both now log type, size, and connection before refusing
SETUP_CONNECTION_ERROR	Unsupported protocol/version got a false success reply	Now gets the specific standard-defined error

The version-bits bug that could lose a solved block

Bitcoin mining hardware doesn't just hash a block header, it also gets to vary a portion of the version field to search for extra nonce space. This is called version-rolling, and it's governed by BIP320, which defines a mask: the pool tells a rig which bits it's allowed to roll, and everything outside that mask is supposed to stay fixed.

Most firmware honors the mask precisely, sending back only the bits it was given. Some doesn't. It sends back the whole version field, including bits the pool never allotted it. That's not necessarily malicious; it's a quirk of how some firmware implements version-rolling, and a rig behaving this way can still be hashing correctly in every way that matters to the miner running it. Previously, the pool treated that field as malformed input and refused it before the submission ever reached the code that checks whether it solved a block. That ordering is the entire bug. A rejected-for-parsing submission and a rejected-because-it-lost submission looked identical from the outside, so there was no way to tell, from the pool's own behavior, that a winner could be sitting inside a batch of refused submissions.

The fix changes the order of operations. A submission with out-of-mask version bits is no longer refused on sight. Instead, the pool recombines the negotiated mask with the rig's reported bits, reconstructs the exact header the hardware actually hashed, and runs that reconstructed header through the same block-check path every other submission goes through, but only after confirming the header is one the network would actually accept. If that confirmation fails, the submission is still refused. Sending an invalid block to the network is a strictly worse failure than the one this fix addresses, so that guard rail stays in place. A submission that fails validation still earns no share credit, exactly as it did before this release.

The only thing that changes is that a submission like this can now win. Rigs that stay within their allotted mask, which is every rig this pool has observed, see no change in behavior.

Rejected shares are now visible instead of vanishing

This fix came out of the same investigation as the one above. A malformed submission has always gotten an error back over the wire; the rig itself was never left hanging. What it didn't do was leave any record in the statistics either side could see. A misconfigured rig could mine into nothing indefinitely, and neither the operator's dashboard nor the pool's own numbers would explain why.

Now, a submission the pool can't parse shows up as a rejected share, the same category any other rejection falls into. The reply sent back to the rig hasn't changed at all, byte for byte. Nothing gets credited that wasn't credited before; this fix creates no new way to earn a share. It just makes a failure mode that used to be invisible show up where you'd expect to find it: in your reject count. If you're running a rig against this pool, a reject count that reflects what's actually happening is the first place you'd look if a payout ever seemed off, and it's exactly the kind of number this release is trying to make trustworthy.

Litecoin and Dogecoin get the same connection limits Bitcoin and Bitcoin Cash already had

The Litecoin and Dogecoin stratum endpoint had been running without the per-address connection limits that the Bitcoin and Bitcoin Cash endpoints already enforce. In practice, that meant a single source could open as many connections as it wanted against that endpoint, consuming the pool's time answering them with nothing forcing a cap.

The endpoint now enforces the same limits the other two chains have had all along; those limits had been switched off on this one. A per-address cap doesn't stop anyone from mining normally; it stops one source from opening far more connections than any real rig setup would ever need. Connected miners today sit far below the limit that's now enforced, so this closes an abuse vector without touching anyone actually mining. Share accounting and payouts aren't part of this at all.

The dashboard now warns about a hot voltage regulator, and fixed a false alarm on small fleets

Rigs report a voltage regulator temperature alongside chip temperature, and the pool has always received and displayed that number. What it never did was compare it against anything. On this class of hardware, the regulator can hit its thermal limit before the chip does, which means watching chip temperature alone can miss a real problem entirely. Sometimes the component actually in danger is the one nobody was watching. The dashboard now flags it when a rig's regulator reading crosses that line. Rigs that don't report a regulator temperature at all are unaffected: there's nothing to compare. This is a warning, not a control: the pool never changes a rig's settings, it only tells you what it sees.

The same update fixed a related false positive in the efficiency comparison that measures a rig against others of the same model. With only two rigs of a given model connected, that comparison had no meaningful middle to measure against, and could flag a perfectly healthy rig as an outlier because the sample was too small. It now requires at least three rigs of the same model before making that comparison at all. Both changes are display and advice only; nothing here reaches into a rig's settings, its shares, or a payout.

Two Stratum V2 messages that used to fail silently now leave a record

There are two specific situations where the pool declines to send an outbound Stratum V2 message: the frame is too large for the size ceiling, or its header can't be serialized. In both cases, the pool used to return without sending anything and without recording anything. From the other end of the connection, and from the pool's own logs, that looked exactly like the pool having nothing to say. There was no way to distinguish "nothing happened" from "something failed to send." For anyone debugging from the other end, those two situations call for completely different responses, and only one of them was visible.

Both cases now record the message type, its size, and which connection it was headed for before the pool refuses to send it. Neither of these conditions is reachable by the traffic the pool builds today, and that's precisely the point of logging them: if either one ever fires, it's a signal worth investigating, not noise to filter out. Both checks still run before any encryption step, so a refusal here never consumes an encryption counter and never leaves a connection out of step with the other side. None of this touches how shares are counted or how anyone gets paid.

A connection asking for an unsupported protocol now gets told so, instead of a fake all-clear

If a connection asked the pool for a Stratum V2 protocol or version the pool doesn't serve, it used to get back a reply that said everything was fine, then find that nothing actually worked. That left it retrying against a pool that looked healthy from the outside while never making progress, a frustrating state to debug from the far end because every signal says the connection succeeded.

The pool now sends the specific SETUP_CONNECTION_ERROR the standard defines for exactly this case, naming the reason the connection can't proceed. This only touches connections that were already headed for failure. Every rig mining today already negotiates its protocol and version cleanly, so nothing about how it mines, earns shares, or gets paid changes here.

Full details on all six fixes, plus everything else in this release, are in the full changelog.

The version-bits fix and the visibility fix above both came out of the same review: shares that get thrown away are worth checking, because every so often one of them was a winner. Neither fix changes what a correctly-behaving rig sees today; both change what happens the day something in the pipeline goes wrong, which is the whole point of shipping them before that day arrives rather than after.

That's also the thinking behind Glass Ledger, the custody work we publish so operators can check their own numbers instead of taking our word for them. A discarded share and an unverifiable payout are different problems, but they come from the same instinct: build the pool so a miner never has to just trust what the dashboard tells them.