Mujina's first pool-accepted share on BZM2 silicon

2026-09-23T02:37:09Z. Mujina, the open-source (GPL-3.0-or-later) Bitcoin mining software, submitted a share that a public pool accepted. It came from an RDS hashboard carrying 100 BZM2 ASICs, running on Mujina's own driver from job to result to submission.

At that second the chain tip was block 968,216 (000000000000000000014df86e986ca182365da99657cdfd1c22c3326d6a8cdc), so the share was mined toward block 968,217. Two independent block explorers, mempool.space and blockstream.info, agree on the tip's height, hash and header time. Header times are set by miners, and this tip was only 32 s old, so "tip at that second" is stated with that caveat. The pool accepting the share is the evidence that its job was on the current tip.

What ran

What it measured

Over a 610 s hold, from the first job to the pause:

shares accepted / rejected 13 / 0, at difficulty 262,144
trips, arms, scrams none

When the harness paused mining at the end, the load came off within a second, with Mujina still running. The engines stop when work stops.

Figures published by explicit decision (Ronald Bynoe, 2026-09-23): the share counts and window. The hash rate was published with them, and withdrawn on 2026-09-28: no performance figure is published before the first multi-day run of at least 48 hours. Performance, power, efficiency and temperatures from this run are in the project's case record, for the eventual retrospective.

What it took

A first dispatch, one run earlier, returned nothing. Every result was missing, and power stayed at idle. A verified investigation found three separate defects, and any one of them would have prevented an accepted share. Each fix carries a test that fails without it, and the first was confirmed on the silicon before any code was written:

  1. The engines were clock-gated. Mujina's take-over reset gates every engine's cores, and nothing ungated them. We read the engine's config register on the chip after the reset (gated), wrote the run value, and read it back (running). Mujina now ungates after every reset and refuses to dispatch unless the readback agrees.
  2. The job and the returned nonce were in the wrong byte order, and the nonce offset was wrong. Checked against a public captured hardware result: under the old rule it decodes to a header with 1 leading zero bit; under the new rule, 34.
  3. Every engine hashed identical work. The silicon does not split work between engines or ASICs, so without distinct work the same nonces were hashed 23,600 times over. Each ASIC now has its own nonce range, and each engine its own extranonce2.

The safety behaviour that surrounded those runs was exercised for real. A thermal interlock refuses work until every die has reported. A stall watch stops a chain that is given work but returns nothing. A ladder de-energises the board if that does not clear. All three fired correctly on the failed runs, including one caused by a sequencing mistake of ours, in which the sensor stream never came up. Each time, the board ended dark and safe.

What this does not claim

Reproducing it

The tree that produced this share is tagged milestone/first-accepted-share. The run's case record gives its configuration, pass and fail criteria, all written before the run, and every figure above with its evidence path.