A public-code review of the Bitfortun BS-1 has exposed an unusually concrete lesson in Bitcoin-mining telemetry: firmware published for the single-chip BM1373 home miner contained a fixed +400 GH/s adjustment in the path used to show hashrate on the device display. A September investigation by an independent hardware publication traced the addition in the published source and compared it with the upstream NerdQAxe+ code, where the offset was absent.

The 400 GH/s Difference Was Visible in Code

The audit identified + 400.0f in the display calculation. Solo Satoshi reported that the primary hashRate value returned through the miner’s system-information API was not padded by the same 400 GH/s, creating a way to compare the displayed figure with another local measurement. The publication calculated that a screen reading of 5.5 TH/s against an underlying 5.1 TH/s average would represent roughly a 7.8% difference.

Independent testing made the discrepancy easier to understand. Rabid Mining, a verified YouTube channel with more than 100,000 subscribers, reported its BS-1 showing roughly 5.3–5.4 TH/s locally while its pool averaged around 4.9–5.0 TH/s. In a particularly useful diagnostic test, the channel deliberately entered an invalid pool address and reported that the device still displayed 400 GH/s even though Stratum was not connected. The test did not indicate fabricated shares or inflated pool payouts; it isolated the issue to local hashrate reporting.

Bitfortun Responded and the Offset Was Removed

The story did not end with the code discovery. HarloLabs subsequently published Bitfortun’s response, reporting that the manufacturer described the adjustment as an attempt to bring the displayed number closer to observed pool-side performance. According to the response, the 400 GH/s addition was removed from newer firmware and upcoming units were being updated.

Pool-Side Hashrate Remains the Reality Check

The episode illustrates why miners should distinguish between a device’s calculated or displayed hashrate and the work independently observed by a pool. Short pool windows are noisy because share discovery is probabilistic, but a sufficiently long comparison can expose persistent reporting differences. Operators troubleshooting larger machines face the same principle: start with the measurement source before replacing hardware.

BitcoinVersus.tech has previously examined why ASIC hashboards cannot always be swapped between miners, while its recent NerdOS coverage followed the expansion of open-source mining software. The same verification mindset also matters when Bitaxe software adds Stratum V2 connectivity and when technicians flash open-source miner firmware.

Open Source Turned the Bug Into an Auditable Event

The most important part of the BS-1 episode may be that outsiders could inspect the implementation at all. The source was available for comparison against the upstream project, independent reviewers could reproduce the relevant code path, hardware testers could compare it with pool observations, and the disputed behavior could then be removed. Another open firmware project now lists the BS-1 among its supported devices, giving owners an additional software path.

For miners, the practical procedure is straightforward: record the miner’s local hashrate, compare the unadjusted API value where available, compare pool-side accepted work over a meaningful window, and check the exact firmware revision before drawing conclusions. A dashboard is an interface. Accepted shares are evidence of work.

---

Disclaimer: BitcoinVersus.tech provides technology news and analysis for informational and educational purposes only. Mining performance varies with firmware, tuning, silicon quality, temperature, power delivery, pool conditions and measurement interval. Verify software compatibility and preserve a recovery path before changing miner firmware.