Open-source audit finds a fixed hashrate offset in Bitfortun BS-1 firmware
Source report: 2026-09-10 · Editorial analysis published: 2026-09-27
A public-code review found Bitfortun BS-1 display paths adding 400 GH/s to measured hashrate and a separate 0.4 TH/s offset in one-minute history. The main API value was reportedly unchanged, so owners can compare pool-side and API measurements with the screen.
Analysis and practical implications
This section is our analysis and illustrative calculations, separate from the source report.
What the source review found
Solo Satoshi reported that a review of the public Bitfortun BS-1 firmware repository found fixed additions in several hashrate display paths. In DisplayDriver::updateHashrate(), the screen calculation reads the current hashrate plus 400.0f for both displayed efficiency and displayed hashrate. In history.cpp, the one-minute average is returned with an added 0.4, and another line offsets a freshly allocated history buffer by 400 elements. The report checked commit bbd42bc from a repository initialised on August 12, 2026 and compared it with the NerdQAxe+ upstream named by the project.
The offsets affect presentation paths, not proven work
The report says the primary hashRate field in the device’s /api/system/info response is not padded. That distinction matters. A dashboard number is calculated by firmware, while mining revenue depends on valid shares accepted by a pool. Adding a constant to a display can make a machine appear faster locally without producing one extra nonce or accepted share. ASIC.tools has not tested a physical BS-1, so the conclusion is confined to the published source paths and the reviewer’s comparison. It is not evidence that pool records, Bitcoin blocks or every API endpoint were altered.
How large 400 GH/s is in context
Bitfortun marketed the BS-1 around 5.5 TH/s, so a fixed 0.4 TH/s addition is roughly seven percent of that nominal figure. The relative effect changes with real output: it is larger when the hardware hashes below target and smaller when it hashes above target. Because the addition is constant rather than proportional, a temperature or voltage problem could be partly hidden on the screen. This arithmetic does not establish intent. A hard-coded value can be deliberate presentation, a test artefact or an error, but any of those explanations requires removal or clear disclosure before the display can be treated as measured hashrate.
Why the pool is the independent reference
A pool estimates hashrate from submitted shares and their difficulty over time. That method is noisy over short windows but independent of the miner’s local display. Owners can compare a 24-hour or longer pool estimate with the unmodified API field and the front-panel number, while checking rejected and stale shares. If the screen remains approximately 0.4 TH/s above the API across changing operating conditions, it matches the published code pattern. One short reading is insufficient because share variance, pool outages, Wi-Fi loss and warm-up can produce real gaps between local and pool values.
The comparison method is reproducible
The reviewer cloned the BS-1 repository at a stated commit, traced every call feeding hashrate into the screen and HTTP API, cloned the upstream firmware and searched its full history for the same strings. The upstream DisplayDriver paths reportedly call getCurrentHashrate() without the +400.0f term, and the searched offsets did not appear in upstream history. A stronger vendor response would publish a commit removing or explaining the constants, tag a release, provide reproducible binaries and document which values are raw, averaged or estimated. Users should preserve commit hashes because a mutable branch can change after an audit.
Open source makes verification possible, not automatic
Publishing code did not prevent the questionable calculation, but it made the calculation visible and attributable. Open source still requires reviewers, deterministic build instructions and a way to confirm that the binary on the device matches the repository. A vendor could publish one source tree and ship another image, or include opaque binary components. Operators should look for signed releases, checksums, build provenance and a documented update path. Auditable source is a necessary control for trust-minimised firmware, yet it does not replace hardware testing, pool measurement or release governance.
What a BS-1 owner can check safely
First record the installed firmware version and configuration without changing voltage or frequency. Export the API hashrate, screenshot the display and obtain pool-side accepted hashrate over at least 24 hours. Note temperature, uptime, rejects and any restarts. Compare values in the same units: 400 GH/s equals 0.4 TH/s. If upgrading, use only a release that identifies the exact hardware revision, verify its checksum and keep a recovery image. Do not flash an unverified community binary merely because it claims to fix the offset; control-board compatibility and rollback access matter more than a cosmetic correction.
What evidence would close the issue
A complete resolution would include a vendor explanation, a public patch, tagged source, matching binary hashes and before-and-after measurements from independent hardware. The firmware should label chip-rate estimates, share-derived hashrate and pool-side results separately instead of presenting one number as universal truth. Until then, buyers should treat the BS-1 screen figure as a display estimate and use accepted pool shares for economic decisions. The incident is also a broader lesson: every local efficiency value is software output, so farms need external measurement and source-level audit where possible.
Source: Solo Satoshi / public source code ↗
Mining calculator ↗
