Update DGB v9.26.3 nodee fail to pass the correct difficulty for MiningCore mining pool to calculate

[FullyElectric]

all miners share submunition gets rejected .. however DGB node v8.26.x and v8.22.x both works, not rejection however it seems i am mining on a split chain .. this issue started 2 days ago, and i had to install the latest v9.26.3 however now i am getting rejections with the latest version .. how to fix any one of the above issues would be great,
Thanks.

error example
[2026-07-02 15:01:04.4270] [I] [dgb-sha256-1] [0HNMO998TF4DK] Share rejected: low difficulty share (2.8062642962580604E-10) [NerdQAxe++/BM1370/V1.0.37.2-LTS]
[2026-07-02 15:01:20.1713] [I] [dgb-sha256-1] [0HNMO998TF4DK] Share rejected: low difficulty share (3.324377898368114E-10) [NerdQAxe++/BM1370/V1.0.37.2-LTS]
[2026-07-02 15:01:59.7546] [I] [dgb-sha256-1] [0HNMO998TF4DK] Share rejected: low difficulty share (2.683682843127444E-10) [NerdQAxe++/BM1370/V1.0.37.2-LTS]

[JaredTate]

You most likely have been running an old v7 node. 95% of the chain was on the correct main chain v8 nodes. The issue you are experiencing is likely due to the version mask & ASICboost on some closed-source SHA-256 miners. This is how we fixed it on DigiHash:

DigiByte v9.26.x SHA256 ASICBoost Fix

What Happens

After upgrading a DigiByte SHA256 pool from v8.26.2 to v9.26.x, some miners may connect to the pool but stop sending shares.

This can happen with miners or firmware that use ASICBoost / version rolling.

The miner may look connected, but the pool gets no useful work from it.

Why It Happens

DigiByte v9.26.x adds a new required version bit for DigiDollar.

That bit is:

0x00800000

The old SHA256 ASICBoost mask was:

1fffe000

That old mask lets miners change the new DigiDollar bit.

That is the problem.

The pool must not let miners change that bit. If a miner changes or clears it, the pool checks the share using the wrong block version. Then good miner work can look bad to the pool.

The Fix

Change the SHA256 ASICBoost version mask from:

"version_mask": "1fffe000"

to:

"version_mask": "1f7fe000"

This new mask still allows ASICBoost / version rolling, but it protects the DigiDollar bit so miners cannot change it.

DigiHash V2 File

On DigiHash V2, edit this file:

/home/digihash/digihashv2/coins/digibyte.sha256.json

The important SHA256 settings should look like this:

{
  "algorithm": "sha256d",
  "version-rolling": true,
  "allowAsicboost": true,
  "version_mask": "1f7fe000"
}

Do not change the algorithm name. It must stay:

sha256d

Restart The Pool

After changing the config, restart the pool.

For DigiHash V2:

sudo pm2 restart DigiHashv2

You do not need to change the DigiByte data directory.

You do not need to change the SHA256 digibyted config.

Miner Compatibility Note

The old mask had 16 rollable bits.

The new safe mask has 15 rollable bits.

If the pool tells miners:

version-rolling.min-bit-count: 16

some strict firmware may refuse to mine because only 15 safe bits are available.

For strict miners, the pool should advertise 15 bits, or not require a 16 bit minimum.

Short Version

For DigiByte v9.26.x SHA256 mining pools:

Use version_mask: 1f7fe000
Do not use version_mask: 1fffe000

This keeps ASICBoost working and stops miners from changing the new DigiDollar version bit.

[FullyElectric]

checking my logs i do see the bad version info you stated .. i was running 8.22.2 when i went to 9.26.3 and i built a totally new node and point my pool to that new DGB node, doing upgrades this way allows me to just re-point to the previous node quickly if any issues, let me add that new version number and see if that sorts this on v9.26.3 ..Thank you.

$ grep version-rolling dgb-sha256-1.log

[2026-07-02 14:58:04.6112] [I] [dgb-sha256-1] [0HNMO998TF4DK] Using version-rolling mask 1fffe000
[2026-07-02 14:58:29.0668] [I] [dgb-sha256-1] [0HNMO998TF4EB] Using version-rolling mask 1fffe000
[2026-07-02 15:00:11.0328] [I] [dgb-sha256-1] [0HNMO998TF4EK] Using version-rolling mask 1fffe000
[2026-07-02 15:27:07.9674] [I] [dgb-sha256-1] [0HNMO9M60MQUC] Using version-rolling mask 1fffe000
[2026-07-02 15:27:20.9766] [I] [dgb-sha256-1] [0HNMO9M60MQUD] Using version-rolling mask 1fffe000
[2026-07-02 15:27:32.2035] [I] [dgb-sha256-1] [0HNMO9M60MQUF] Using version-rolling mask 1fffe000

[FullyElectric]

Hi Setting new mask in MiningCore pool software is done at a global level for all sha256d coins .. this means BTC, BCH, FB etc.. will all be affected? since all of them works with the old mask "1fffe000" .. adding this new mask "1f7fe000" will the other coins be impacted in a negative way? or will i have to build a dedicated pool just for DGB now?

$ grep -R 1fffe000
src/Miningcore/Blockchain/Bitcoin/BitcoinConstants.cs: public const uint VersionRollingPoolMask = 0x1fffe000;

BTW would it not just be easier for DGB v9.26.3 just support the old mask like v8.x ?

[FullyElectric]

Confirmed .. changing MiningCore to the new mask 1f7fe000 works ... however ALL other sha256 coins on the same pool in now rejecting shares .. so this is not really a fix unless you only have a dedicated DGB pool.

[2026-07-02 21:54:22.0090] [I] [dgb-sha256-1] [0HNMOGHHSBBLT] Using version-rolling mask 1f7fe000
[2026-07-02 21:54:22.0357] [I] [dgb-sha256-1] [0HNMOGHHSBBLT] Setting static difficulty of 8192
[2026-07-02 21:54:40.3485] [I] [dgb-sha256-1] [0HNMOGHHSBBLT] Share accepted: D=8192
[2026-07-02 21:54:40.6954] [I] [dgb-sha256-1] [0HNMOGHHSBBLT] Share accepted: D=8192
[2026-07-02 21:54:40.8218] [I] [dgb-sha256-1] [0HNMOGHHSBBLT] Share accepted: D=8192
[2026-07-02 21:54:48.3287] [I] [dgb-sha256-1] [0HNMOGHHSBBLT] Share accepted: D=8192

BTC/BCH/etc... all affected by this new mask..

2026-07-02 21:56:34.4787] [I] [bitcoin-cash-1] [0HNMOGHHSBBLR] Share rejected: duplicate share [bitaxe/BM1370/v2.12.2]
[2026-07-02 21:56:34.5367] [I] [bitcoin-cash-1] [0HNMOGHHSBBLS] Share rejected: duplicate share [bitaxe/BM1370/v2.11.0-5-g8dc659c-dirty]
[2026-07-02 21:56:34.5367] [I] [bitcoin-cash-1] [0HNMOGHHSBBLR] Share rejected: duplicate share [bitaxe/BM1370/v2.12.2]
[2026-07-02 21:56:34.5954] [I] [bitcoin-cash-1] [0HNMOGHHSBBLS] Share rejected: duplicate share [bitaxe/BM1370/v2.11.0-5-g8dc659c-dirty]
[2026-07-02 21:56:34.6057] [I] [bitcoin-cash-1] [0HNMOGHHSBBLR] Share rejected: duplicate share [bitaxe/BM1370/v2.12.2]
[2026-07-02 21:56:34.6697] [I] [bitcoin-cash-1] [0HNMOGHHSBBLS] Share rejected: duplicate share [bitaxe/BM1370/v2.11.0-5-g8dc659c-dirty]
[2026-07-02 21:56:34.7193] [I] [bitcoin-cash-1] [0HNMOGHHSBBLS] Share rejected: duplicate share [bitaxe/BM1370/v2.11.0-5-g8dc659c-dirty]

..

can DGB v9.26.3 just add back support for the old mask !! this way no one will need to make any other changes after the upgrade!!

[2026-07-02 22:00:02.1901] [I] [bitcoin-cash-1] [0HNMOGHHSBBLB] Share rejected: rolling-version mask violation [NerdQAxe++/BM1370/v1.0.34-rc2.1-5-g69631cd-dirty]
[2026-07-02 22:00:05.6951] [I] [bitcoin-cash-1] [0HNMOGHHSBBLB] Share rejected: rolling-version mask violation [NerdQAxe++/BM1370/v1.0.34-rc2.1-5-g69631cd-dirty]
[2026-07-02 22:00:08.4811] [I] [bitcoin-cash-1] [0HNMOGHHSBBLB] Share accepted: D=16384
[2026-07-02 22:00:46.6834] [I] [bitcoin-cash-1] [0HNMOGHHSBBLB] Share rejected: rolling-version mask violation [NerdQAxe++/BM1370/v1.0.34-rc2.1-5-g69631cd-dirty]
[2026-07-02 22:00:54.8691] [I] [bitcoin-cash-1] [0HNMOGHHSBBLB] Share accepted: D=16384
[2026-07-02 22:01:15.6723] [I] [bitcoin-cash-1] [0HNMOGHHSBBLB] Share rejected: rolling-version mask violation [NerdQAxe++/BM1370/v1.0.34-rc2.1-5-g69631cd-dirty]
[2026-07-02 22:01:56.0359] [I] [bitcoin-cash-1] [0HNMOGHHSBBLB] Share accepted: D=16384
[2026-07-02 22:02:09.5315] [I] [bitcoin-cash-1] [0HNMOGHHSBBLB] Share accepted: D=16384
[2026-07-02 22:02:23.3848] [I] [bitcoin-cash-1] [0HNMOGHHSBBLB] Share accepted: D=16384
[2026-07-02 22:02:25.5095] [I] [bitcoin-cash-1] [0HNMOGHHSBBLB] Share rejected: rolling-version mask violation [NerdQAxe++/BM1370/v1.0.34-rc2.1-5-

[JaredTate]

@FullyElectric Thank you very much for sharing your feedback! This was all very helpful. I sincerely apologize for the trouble. We should have used a bit less than 13 to signal DigiDollar, but we can't change it now with more than 800+ downloads of v9.26.x out there. Bit 23 has to stay.

We have been able to confirm a fix for SHA256 ASICboost miners on multiple other mining pools now. This issue only affects SHA256 and not DigiByte's other 4 mining algos. During DigiDollar testing over the past several months, none of us had ASICboost sha26 miners to test with and overlooked the version mask conflict. So once again, sorry for the trouble.

Fixing SHA256 Mining on DigiByte v9.26.x (Bit 23 / Version Rolling)

Who this is for: pool operators and miner firmware devs.
What it fixes: SHA256 miners (NerdAxe, NerdQAxe, Bitaxe, S19-class) losing ~half
their shares on DigiByte v9.26.x pools — Difficulty too low rejects, vanishing
hashrate, duplicate-share storms.

---

1. The problem — 30 seconds

DigiByte v9.26.x nodes set the DigiDollar activation signal on bit 23 of the block
version. Bit 23 sits inside bits 13–28 — the exact region SHA256 ASICs overwrite
as scratch space for version rolling (AsicBoost).

Miner firmware was written assuming that region starts empty. On v8 it always did.
On v9 it doesn't — and the miner's share math breaks on roughly half of all shares.

Symptom	Cause
Difficulty too low rejects	pool rebuilds a header the chip never hashed
Hashrate ~55% of chip spec, clean accepts	firmware silently discards half its own shares
duplicate share storms	pool's duplicate check can't tell rolled shares apart

Nothing is wrong with the miners, the chips, or the node. It's the job format.

2. Why it happens — 60 seconds

node → pool:   getblocktemplate version = 20800202   (bit 23 set)
pool → miner:  job goes out with that version
ASIC:          OVERWRITES bits 13–28 with its own counter (bit 23 flips randomly)
miner ← ASIC:  firmware rebuilds "what did the chip hash?" using OR:
               rolled_version = job_version | counter        ← assumes region was empty

OR can turn bits on but never off. When the job already has bit 23 on and the chip
turns it off, the firmware reconstructs the wrong header → wrong hash → a good
share gets discarded or rejected. Coin flip per share: ~50% loss.

3. The fix — 3 steps, same on every pool

Step 1 — Strip the rolling region from every SHA256 job.
Jobs must go out with version 20000202, not 20800202.

Step 2 — Grant and validate the FULL rolling mask 1fffe000.
In the mining.configure response and in share validation. Never narrow it to
"protect" bit 23 — chips roll that bit no matter what; a narrow mask just turns their
legal work into rejects.

Step 3 — Restart the SHA256 port; miners reconnect (power-cycle to be sure), so
mining.configure renegotiates.

Steps 1 and 2 only work together: the strip makes the firmware's math correct;
the full mask makes the chip's inevitable bit-23 flips legal and merged back
faithfully.

4. Applying it on your software

DigiHash / NOMP-style pools (this repo)

npm update stratum-pool      # v0.3.0 does step 1 automatically + fixes duplicate detection
# coins/digibyte.sha256.json must keep:  "version_mask": "1fffe000"
# restart the SHA256 pool process

Only SHA256 is touched. Scrypt/Skein/Qubit/Odo configs have no version_mask, so
their jobs keep bit 23 and keep signaling DigiDollar on every block.

MiningCore

One line where the job takes the template version (BitcoinJob.cs), for the
DGB-sha256 pool only:

version = BlockTemplate.Version & ~0x00800000u;

Leave the global VersionRollingPoolMask at 0x1fffe000. It is shared by every
SHA256 coin on the instance — narrowing it fixed DGB but broke BTC/BCH in field
testing.

Any other stratum

Apply the same three rules:

1. Strip in one place (where the GBT version enters the job) so the job
   announcement, share validation, and block submission all agree.
2. Include the miner's version_bits in your duplicate-share key — with rolling,
   two valid shares can differ only in those bits.
3. Roll out on a fresh job (clean_jobs = true).

Miner firmware (NerdAxe / NerdQAxe / Bitaxe)

The root fix is one line — replace the OR with a masked merge:

rolled_version = (job->version & ~0x1fffe000) | (version_bits << 13);

NerdQAxe also needs the pool-granted mask actually programmed into the ASIC
(upstream issue shufps/ESP-Miner-NerdQAxePlus #640). Until those ship in a
release: mine on a pool that applied steps 1–3. No device setting works around
this.

5. Verifying the fix works

Check these four things, in order:

1. Job version is clean. mining.notify for SHA256 shows version 20000202.
2. Full mask granted. The mining.configure response contains
   "version-rolling.mask": "1fffe000".
3. Math check. A share with version_bits = 03fe2000 on job 20000202 must
   validate against header version 23fe2202. (Real values from a NerdQAxe++ log.)
4. Results. Difficulty too low rejects go to zero and credited hashrate returns
   to chip spec (a NerdQAxe++ reads ~11.3 TH/s again). Accepted shares show a mix of
   version_bits with bit 23 on (03fe2000) and off (00034000) — both are normal.

If something still fails:

Still seeing	It means	Do this
notify shows 20800202	strip not active	update stratum-pool / apply the one-liner; check version_mask is set for the coin
rejects continue, and rejected shares have bit 23 set in version_bits	a narrowed mask somewhere (grant or validation)	set BOTH to full 1fffe000
duplicate share storm	dup key ignores version bits	include version_bits in the key (stratum-pool v0.3.0 does)
one miner still at ~55%, no rejects	it connected before the restart	power-cycle that miner

6. FAQ

Does stripping bit 23 hurt DigiDollar activation?
No. Bit 23 is a vote, never a validity rule — a block is equally valid with or without
it. The chip's own rolling still sets it on ~half this port's blocks (free signaling),
the other four algos signal on 100% of theirs, and from block 23,788,800 every
upgraded node also signals bit 0, which rolling cannot touch.

Why can't the pool just keep bit 23 fixed and forbid rolling it?
The hardware can't comply. BM13xx chips roll bits 13–28 as one contiguous counter —
there's no way to fence off one bit in the middle, and some firmware never loads the
pool's mask into the chip at all.

What did "Difficulty too low" actually mean?
The pool rebuilt a header that wasn't the one the chip hashed (bit 23 mismatch),
hashed it, and got a random number — which almost never meets the target. The share
was fine; the reconstruction wasn't.

Where's the deep technical writeup?
DigiByte repo: BIT_ISSUE.md (root cause with code citations),
POOL_BIT23_HOTFIX_GUIDE.md, and BIT23_MATH_EXPLAINED.md (the bit math, step by
step). The stratum fix itself: node-stratum-pool commit e564a00, tests in
lib/test_versionroll.js.

[JaredTate]

Find the above text written in an MD document here as well: https://github.com/JaredTate/digihashv2/blob/main/SHA256_VERSION_MASK_FIX.md

[FullyElectric]

Thank you for looking into and sorting this, as you know MiningCore as global share files under ./src/Miningcore/Blockchain/Bitcoin/* for ALL sha256 coins no files are dedicated to a single coin using the same algo, for me to affect only DGB i would have to add DGB sha256 as a new algo to MiningCore with its own processing files, however the shared BitcoinJob.cs located at ./src/Miningcore/Blockchain/Bitcoin/BitcoinJob.cs does have the var version = BlockTemplate.Version; entry and another line that is some what similar .. see below .. grep output

$ grep BlockTemplate.Version ./src/Miningcore/Blockchain/Bitcoin/BitcoinJob.cs
var version = BlockTemplate.Version;
BlockTemplate.Version.ToStringHex8(),

What i will attempt todo is change the first list above ..

From:
var version = BlockTemplate.Version;

To:
var version = BlockTemplate.Version & ~0x00800000u;

in the shared file ./src/Miningcore/Blockchain/Bitcoin/BitcoinJob.cs
note doing so is still global, however if it does not affect the other sha256 coins i am ok with it, i just don't see how to indicate in MiningCore BitcoinJob.cs file to only affect the DGB sha256 pool.

will report back once done ..

[FullyElectric]

So making the suggested change for MiningCore does not work..

From:
var version = BlockTemplate.Version;

To:
var version = BlockTemplate.Version & ~0x00800000u;

i also tried without the "u" just in case that was a typO .. in anycase does not work for the DGB sha256 pool and also does not affect the only sha256 pools.. so as of right now i am NOT able to run the DGB sha256 pool on MiningCore with other sha256 pools, however i am able to run it on a dedicated sha256 pool with the mask directly changed to 1f7fe000

$ grep 0HNMQS1T8I1I0 dgb-sha256-1.log
[2026-07-05 21:58:20.9849] [I] [dgb-sha256-1] [0HNMQS1T8I1I0] Accepting connection from ::ffff:10.33.29.112:63282 ...
[2026-07-05 21:58:20.9849] [I] [dgb-sha256-1] [0HNMQS1T8I1I0] Connection from ::ffff:10.33.29.112:63282 accepted on port 3334
[2026-07-05 21:58:21.0038] [I] [dgb-sha256-1] [0HNMQS1T8I1I0] Using version-rolling mask 1fffe000
[2026-07-05 21:58:21.0306] [I] [dgb-sha256-1] [0HNMQS1T8I1I0] Setting static difficulty of 8192
[2026-07-05 21:59:36.0775] [I] [dgb-sha256-1] [0HNMQS1T8I1I0] Share rejected: low difficulty share (1.4825774679508045E-08) [bitaxe/BM1370/v2.11.0-5-g8dc659c-dirty]
[2026-07-05 21:59:59.1809] [I] [dgb-sha256-1] [0HNMQS1T8I1I0] Share rejected: low difficulty share (2.4572806800164023E-10) [bitaxe/BM1370/v2.11.0-5-g8dc659c-dirty]
[2026-07-05 22:00:07.9223] [I] [dgb-sha256-1] [0HNMQS1T8I1I0] Share rejected: low difficulty share (2.895989791648013E-10) [bitaxe/BM1370/v2.11.0-5-g8dc659c-dirty]
[2026-07-05 22:00:24.0887] [I] [dgb-sha256-1] [0HNMQS1T8I1I0] Share rejected: low difficulty share (7.124093492312895E-09) [bitaxe/BM1370/v2.11.0-5-g8dc659c-dirty]
[2026-07-05 22:00:48.8253] [I] [dgb-sha256-1] [0HNMQS1T8I1I0] Share rejected: low difficulty share (4.346815793229157E-09) [bitaxe/BM1370/v2.11.0-5-g8dc659c-dirty]
[2026-07-05 22:00:53.5620] [I] [dgb-sha256-1] [0HNMQS1T8I1I0] Share rejected: low difficulty share (2.700058212384664E-10) [bitaxe/BM1370/v2.11.0-5-g8dc659c-dirty]
[2026-07-05 22:01:59.8960] [I] [dgb-sha256-1] [0HNMQS1T8I1I0] Share rejected: low difficulty share (8.345245193834624E-10) [bitaxe/BM1370/v2.11.0-5-g8dc659c-dirty]
[2026-07-05 22:02:18.3630] [I] [dgb-sha256-1] [0HNMQS1T8I1I0] Share rejected: low difficulty share (2.3559529608289194E-10) [bitaxe/BM1370/v2.11.0-5-g8dc659c-dirty]
[2026-07-05 22:02:21.4130] [I] [dgb-sha256-1] [0HNMQS1T8I1I0] Share rejected: low difficulty share (5.102425467682391E-10) [bitaxe/BM1370/v2.11.0-5-g8dc659c-dirty]

[FullyElectric]

so their has to be something set at the MiningCore port level or some place else to let miningcore use the new mask "1f7fe000 " for DGB v9 .. any other ideas ?