DigiByte: Why Your Share Wasn't a Block

DigiByte’s MultiShield recalculates the SHA-256 mining target every time a block arrives on any of its five algorithms — on average every 15 seconds. The network difficulty you see on an explorer, a dashboard or a mining report is a snapshot that is already stale. A share that beats that figure is only a valid block if it beats the target in force at the exact second it reaches the pool. This is the most common reason a DigiByte solo miner sees a record share and wins nothing.

Key takeaways

• On DigiByte the SHA-256 target is recomputed whenever a block lands on any of the five algorithms, not only when a SHA-256 block is found.
• In one 90-minute window, SHA-256 block difficulty ranged from 418 million to 1.12 billion — a factor of 2.7.
• Within a single two-minute stretch the live target rose 75%, from 748 million to 1.31 billion.
• A share’s value depends on the target at the second it arrives. The same share can fall short at one moment and win a minute or two later.
• None of this means a block was lost. A share below the live target is never submitted as a block, so there is nothing to orphan, reject or hide.

Why did my share beat the network difficulty and not find a block?

A solo miner on DigiByte sent us a careful, well-researched report. Their miner had produced a share of roughly 997 million difficulty. A mining report generated about an hour later showed a network difficulty of 531 million — making the share almost twice the target. Yet no block appeared. They had checked the pool’s API, confirmed the share was received and accepted, and found no record of it being rejected or stale. By every number they could see, it should have been a block.

The numbers they could see were real. They were also the wrong numbers.

We traced the share in the pool’s logs. It arrived between 06:26:31 and 06:27:31 UTC on 4 October 2026. During that minute the network did not require 531 million. It required 1.13 to 1.21 billion. The share reached between 82.7% and 88.1% of what was needed.

The 531 million figure was the difficulty an hour later, after a spike had passed. And from 06:28:37 — one to two minutes after the share arrived — the target fell below 997 million. The same share, a minute or two later, would have been a block.

Why does DigiByte’s difficulty move so much?

DigiByte splits block production across five independent mining algorithms — SHA-256, Scrypt, Skein, Qubit and Odocrypt — each mining about one block in five, each with its own difficulty. The chain targets a block every 15 seconds overall, so the SHA-256 lane averages one block every 75 seconds.

Each lane’s difficulty is managed by MultiShield, the multi-algorithm extension of DigiShield that DigiByte introduced in 2014. Where Bitcoin retargets once every 2,016 blocks, MultiShield recalculates difficulty every single block.

The detail that catches miners out is that it recalculates every lane on every block, not just the lane that found it. DigiByte’s own consensus code says so in a comment above its difficulty parameters: the difficulty of one algorithm may decrease when a different algorithm is solved. So the SHA-256 target does not sit still between SHA-256 blocks. Every block found on Scrypt, Skein, Qubit or Odocrypt moves it too, and the result is a target that changes roughly every 15 seconds. Our DigiByte explainer covers the full algorithm, read directly from the consensus code.

What did the target actually do during that minute?

Each time a new block arrives, the pool builds a new mining job and records the target that job must meet. These are the exact values the pool’s logs recorded around the share:

The share arrived between 06:26:31 and 06:27:31, while the target stood at 1,205,245,749 and then 1,130,849,418. At 996,739,624 it reached 82.7% to 88.1% of the requirement. The target first fell below the share at 06:28:37.

What drove that wave becomes clear once you add the SHA-256 blocks the chain actually produced in the same window:

Three SHA-256 blocks arrived in 99 seconds — one every 33 seconds, against an expected pace of one every 75. The SHA-256 lane was running well ahead of the other four, and MultiShield raised its difficulty in response, to a peak of 1.31 billion. Then no SHA-256 block came for four minutes and twenty-four seconds. As blocks landed on the other algorithms, the target eased back down, step by step. The share arrived just after the crest, while the target was still descending from it.

The logged values are the network’s real requirement, not an estimate. Each of the four SHA-256 blocks above was mined at exactly the target the pool had recorded moments earlier, matching to the unit. All four are publicly verifiable on any DigiByte explorer.

Why didn’t the difficulty in the report match the target?

Because the report captured a moment an hour later, and on DigiByte an hour is a long time.

Any difficulty figure you look at — on an explorer, a pool dashboard, a mining report or a profitability calculator — is the value at the instant it was read. On Bitcoin that value holds for two weeks. On DigiByte the SHA-256 target is recomputed every time any of the five algorithms finds a block, so a figure taken at 07:34 says almost nothing about what was required at 06:27.

Across the ninety minutes around this share, the difficulty of SHA-256 blocks on the chain ranged from about 418 million to 1.12 billion — a factor of 2.7. A share of 997 million was comfortably a block at the bottom of that range and comfortably short at the top.

There is a further trap. Explorers publish the difficulty of each block as it was mined — the value that applied to the winner. There is no public record of the target in force during the seconds between blocks. The highest target in the log above, 1.31 billion, appears on no explorer anywhere, because no SHA-256 block was mined while it was in force. Yet that is exactly the kind of moment in which a near-miss happens.

Why can the target jump more than MultiShield’s 8% limit?

Our DigiByte explainer notes that MultiShield clamps its retarget: difficulty can fall by up to 16% in a step but rise by at most 8%. Yet after each of the three fast SHA-256 blocks in this window, the target climbed by more than 20% — by 22.9%, 22.7% and 21.7%.

The two facts do not conflict, because MultiShield moves a lane in two separate ways. The 8% and 16% clamps bound the lane’s own averaged retarget. On top of that, a per-algorithm adjustment of 4% shifts the lane according to whether it is running behind or ahead of the other four.

In this window the second mechanism produced a clear sawtooth. Each block on another algorithm lowered the SHA-256 target by roughly 4 to 5%. Each SHA-256 block, arriving while the lane was already ahead, pushed it sharply back up. Read the target log above with that in mind and the pattern is unmistakable: three large steps up, each following a SHA-256 block, then a long staircase down.

How is this different from eCash Real-Time Targeting?

The symptom is identical — a share beats the published difficulty and wins nothing — but the mechanism is not.

On eCash a share’s fate depends on how long ago the last block arrived; we documented that in detail in eCash RTT: Why Your Solo Share Wasn’t a Block. On DigiByte it depends on where the SHA-256 target happened to sit after the most recent block on any algorithm. Both produce near-misses that look, from the miner’s side, exactly like a missed block.

Does this happen on Bitcoin or the other SHA-256 chains?

Not in this form. On most SHA-256 chains the target is fixed for the length of a block interval and changes only when that chain finds its next block.

On Bitcoin and Bitcoin Cash, the difficulty you look up is the one you had to beat. On DigiByte the target that decided your share existed for a few seconds and was never published anywhere.

Was the block lost, orphaned or hidden?

No — because there was never a block.

The pool records a block-solve event every time a share meets the network target of its job. For this share there was none. The pool evaluated it against the live target, found it short, and accepted it as an ordinary share. No block was assembled, no submitblock call was made, and nothing was sent to the network. There was nothing to orphan, reject or lose.

On a non-custodial pool this can be checked from the outside. The miner’s payout address is written into the coinbase transaction of the block template before hashing begins, so any real block appears on-chain in the miner’s own name, permanently. A share that never became a block leaves no such trace — and a real block could not be hidden if it had existed.

What should a DigiByte solo miner actually do?

Mostly nothing — but read your numbers correctly.

• Treat every difficulty figure as a snapshot. A best share above the difficulty on your dashboard or report is not evidence of a missed block. It is evidence the target was higher when your share arrived.
• Your best-share display is computed locally. Miners record the difficulty of a hash the instant it is found, before the pool has answered, and often keep an all-time figure that never resets. It tells you your hardware had a good moment, not whether that moment was a winner.
• Let vardiff manage share difficulty. DigiByte retargets every block, so a fixed share difficulty that suits one hour can be wrong the next. Our DigiByte setup guide covers the configuration.
• Keep latency low. On a 15-second chain, a nearby server shortens the gap between a new job appearing and your miner working on it.
• Check the coinbase, not the counter. To know whether you found a block, look for your address in a coinbase transaction on-chain.

None of this changes your long-run odds. The swings average out over time, which is why probability based on average difficulty — as in our solo odds calculator — remains the right basis for expectations. The swings only decide which individual near-misses become blocks.

Sources

• DigiByte Core consensus parameters — the note that difficulty is updated for every algorithm on every block, and the MultiShield constants nMaxAdjustUpV4 = 8, nMaxAdjustDownV4 = 16 and nLocalTargetAdjustment = 4
• DigiByte Core — pow.cpp, MultiShield difficulty adjustment (GetNextWorkRequiredV4)
• DigiByte (DGB) Explained for Miners — our full profile of MultiShield, read directly from the consensus code
• Measuring expected block timing for Difficulty Adjustment — Josiah Spackman on MultiShield and per-block retargeting

Target values in this article are taken from the pool’s own logs on 4 October 2026, recorded each time a new mining job was built. All four SHA-256 blocks mined in the window — 24,323,739, 24,323,740, 24,323,742 and 24,323,752 — match exactly the target the pool logged moments before each was found, confirming that the logged values are the network’s real requirement. All block difficulties cited are publicly verifiable on any DigiByte explorer.