Compatibility Report Obelisk SC1 Slim

Original I posted this in General by mistake, so I reposted it here i BitCoin. I tried to delete the post in General but do not have access

ASIC compatibility report

Device: Obelisk Obelisk SC1 Slim Gen2
Firmware: 1.60
Stratum user agent: cgminer/4.10.0

Jobs received, nothing submitted. The miner is not hashing this work. Likely a work-format or algorithm mismatch.

Outcome

  • TCP connections: 1

  • stratum sessions: 1

  • jobs received: 58 (1 with clean_jobs)

  • shares: 0 submitted, 0 accepted

  • session: 1374s

  • blocks: none submitted this session

Dialect

subscribe        : 1 param(s), widths [14]
extranonce1      : 4 bytes
extranonce2_size : 8
difficulty       : [64]
methods used     : mining.authorize, mining.notify, mining.set_difficulty, mining.subscribe
non-standard     : none

Environment

  • datum-blake2b image (gateway 39f9c3c82df72736f0ac9417ac388885ce32340e, tooling 140b8ccab213)

Notes

Spins up and Hashrate on Obelisk Dashboard climbs but not on Datum Gateway Dashbord

Worker names are hashed and passwords dropped at capture time.

Share this in the Bitcoin section of the forum:
Bitcoin - PaulsCode (a free account is needed to post)
or, if you already use GitHub:

Today I ran a second test, using the RC5 release on my Start9 setup and I added another hashboard, factyory reset and ran AutoTune, when I was connected to the a officiel Sia Coin pool.
I found a post where Paul was testing on this setup
Pool URL:
stratum+tcp://sc.f2pool.com:7788

Worker:
26117c19ca3975b315d663dcbbc19cf9c07274f441689d4392ed380b2337589ef1aacfbdc93f.ObeliskSC1

Password:
x

And I did the same and the miner was hasning as expected on this pool climbing to about 950 Gh/s

I then updated to mine (solo) on my Start9 setup, but the same result as previous, Datum showed 1 client connected but no hashrate. I tested for about 1 hour with no changes.
On the Datum config I tried with and without Allow hasher time rolling for BLAKE2b jobs

A extract from the Datum log

I finaly got the Obelisk SC1 Slim Gen 2 miner to mine on blake2b POW today. Here’s a writeup my AI Agent created
Obelisk SC1 Gen2 → Bitcoin BLAKE2b-POW: findings and fixes

Shareable write-up for other miners running Obelisk SC1 “Slim” (Gen 2) units on the
Bitcoin Knots BLAKE2b hard-fork. Author: Klaus E. Frederiksen. Date: 2026-09-05.

Summary#

The Obelisk SC1 Gen2 (ob2 firmware, cgminer 4.10.0) can mine the BLAKE2b fork.
The ASIC hardware, the software Blake2b, and the verify target are all standard —
the only thing standing between the miner and accepted shares was a
4-byte-vs-8-byte extranonce2 mismatch between the miner firmware and the DATUM
gateway. Two small changes make shares accepted:

  1. A 3-instruction binary patch to the miner’s cgminer-sia (zero-pad the
    extranonce2 in the merkle-root leaf).

  2. A gateway-side zero-extension in datum_stratum.c (zero the high 4 bytes of
    the submitted extranonce2).

Background#

  • The fork switched SHA-256d → BLAKE2b at block 961,640 (2026-08-30). Miners attach
    through a DATUM Gateway (a “Siacoin dialect” of Stratum v1).

  • The SC1 Gen2 control card is a TI AM335x (ARMv7), Linux 4.9.118, running a
    closed-source ob2 cgminer-sia binary. (The Gen1 “ob1” source is open but has
    a different ASIC layer, so it can’t be rebuilt for Gen2 hardware.)

  • The fork’s merkle leaf (datum_pow.c datum_blake2b_work_root) is:
    Blake2b(0x00 || coinb1(39) || sid_inv(4) || extranonce2(8)) — a 52-byte input.

  • The firmware builds its leaf as 0x00 || coinb1 || en1(4) || en2 || coinb2, which
    is byte-identical to the fork’s when coinb2 is empty and en2 is 8 bytes.

The problem#

Shares were submitted but every one was rejected by the gateway with error 23
H-not-zero. The miner’s own log reported the shares as found, but the gateway
reconstructed a different header hash.

Root cause — two bugs#

  1. The leaf uses a 4-byte extranonce2. The ob2 merkle-root builder hashes a
    48-byte leaf with a 32-bit nonce2, while the gateway (and fork consensus) hash a
    52-byte leaf with a 64-bit extranonce2. Different root → different header hash →
    h[0] != 0H-not-zero.

  2. The submission path reads 8 bytes out of a 4-byte nonce2. The stratum submit
    (__bin2hex(nonce2hex, &extranonce2, nonce2_len=8)) reads 8 bytes from a 4-byte
    uint32_t, so the high 4 bytes are stack garbage. Even after fixing the leaf, the
    submitted extranonce2 still carried garbage in the high 4 bytes.

The fixes#

Fix 1 — miner firmware (ob2 binary), 3 patches#

All in the 32-bit ARM (armv7, ARM-state) binary /usr/local/ob2/bin/cgminer-sia:

Patch File offset Change
nonce2_len gate 0xc6bc cmp r3,#4cmp r3,#8 (allow nonce2_len 8)
ExtraNonce2Size 0x32610 (VMA 0x42610) mov r0,#4mov r0,#8
leaf zero-pad 0x32694 bl memcpystr r8,[r0] (zero the en2 high 4 bytes)
leaf zero-pad 0x32698 add r2,r8,r7add r2,r7,#4 (hash 52 bytes, not 48)

The leaf patch makes the miner hash a 52-byte leaf with the high 4 bytes of the
extranonce2 explicitly zeroed, matching the gateway.

Fix 2 — gateway zero-extension (datum_stratum.c, client_mining_submit)#

The pristine gateway reads all 8 bytes of the submitted extranonce2. The SC1 only has
4 real bytes (the high 4 are garbage), so zero them:

Plain Text

Show linesCopy

// Obelisk SC1 miners have a 32-bit nonce2 and submit it in the low 4 bytes of the
// 8-byte extranonce2, leaving stack garbage in the high 4 bytes. Zero-extend to
// 64-bit so the gateway's work-root leaf matches the miner's (which zero-pads the
// same 32-bit nonce2 in its leaf builder). SC1-specific: a true 64-bit-nonce2 miner
// would need the full 8 bytes preserved.
for(i=0;i<4;i++) {
    extranonce_bin[i+4] = hex2bin_uchar(&extranonce2_s[i<<1]);
}
memset(&extranonce_bin[8], 0, 4);

(the pristine version read for(i=0;i<8;i++) with no memset.)

What we proved standard along the way#

  • Software Blake2b (ob2 0x41e80) matches hashlib.blake2b(digest_size=32) on
    empty / "abc" / 80-byte vectors (4/4).

  • Hardware ASIC is standard: 4/4 chip-valid nonces hash to h[0]==0.

  • Verify target is the correct pool target (not a looser chip target).

  • Header layout (prevhash32 || nonce8 || ntime8 || root32) is byte-identical on
    both sides.

So the rejection was never a hashing or hardware problem — it was purely the
extranonce2 width.

Result#

Miner log:

CRITICAL:Accepted 00000028 Diff 18.4E/16384 BLOCK! Obelisk OB2 0

(previously CRITICAL:Rejected ... BLOCK! Obelisk OB2 0 (H-not-zero)).

Deployment on another SC1 Gen2#

  1. Fingerprint the live binary: md5 4c0b44bc41226205347abd3e4a65311a (pristine ob2).
    If it differs, re-apply the three patches to that unit’s own binary offline.

  2. Deploy the pre-patched binary (md5 a59d7e04cb01e03cc52617320fd11614):
    kill cgminer-siamount -o remount,rw / → replace
    /usr/local/ob2/bin/cgminer-siamount -o remount,ro / → restart.

  3. Write the pool config (/var/etc/ob2/cgminer.conf) — a factory-fresh unit has
    pools: []; set {"url":"stratum+tcp://<gateway>:23334","user":"sc1-N","pass":"x"}.

  4. Confirm Accepted ... BLOCK! Obelisk OB2 0 in /var/log/ob2/cgminer-sia.

Rollback#

On-device backup at /var/backup/cgminer-sia.preleaf; restore by copying it back,
remounting ro, and restarting.