What Is a Bitaxe? Open-Source SHA-256 Learning Miner
Commercial-interest and safety disclosure: D-Central sells mining equipment and services. This is an educational device-category guide, not a product recommendation, financial claim, or electrical instruction. Independently verify the exact board, firmware, release provenance, documentation, and local safety requirements before acting.
A Bitaxe is not one immutable product specification. It is a family of open-source Bitcoin mining hardware projects used for learning, experimentation, and probabilistic SHA-256 mining. The useful question is not simply “is it a Bitaxe?” but “which documented board revision, firmware revision, configuration, and measurement boundary is this?”
The hardware and firmware boundary
Published schematic, layout, bill-of-material, and firmware source can make a particular revision auditable. That does not make every ASIC chip, assembled board, power accessory, enclosure, modification, or firmware image automatically open source. Treat “open source” as a claim about identified source files and licences, not a substitute for revision evidence.
Bitcoin consensus specifies SHA-256 proof of work; it does not specify ASIC hardware. Specialized SHA-256 hardware is an implementation and market outcome. A device hashes a supplied job; it does not by itself establish which transactions are valid or which chain rules apply.
Revision evidence: pin the source before comparing
The following entries are evidence locations, not current specifications or compatibility promises. Pinning a commit makes the reviewed source reproducible; match it to the markings and documentation for the actual board in front of you.
| Evidence scope | Pinned source | Use it to verify |
|---|---|---|
| Gamma board design | bitaxeGamma commit f04c421 | Board-level files, revision notes, and documented dependencies. |
| Supra board design | bitaxeSupra commit 5b53f2a | Whether a claimed board family and source revision actually align. |
| Ultra board design | bitaxeUltra commit 842b426 | Revision-specific files rather than a generic family label. |
| ESP-Miner firmware | ESP-Miner commit 3a09ea0 | Firmware source, supported configuration evidence, and release provenance. |
Nameplate is a claim; measured operation is an observation
| Record | Why it changes interpretation | Evidence to retain |
|---|---|---|
| Board and firmware revision | A family label does not identify hardware, settings, or code. | Photographs, commit or release identifier, and configuration export. |
| Nameplate claim | A stated value may describe a particular test condition or setting. | The exact cited document and its scope. |
| Wall-power boundary | Device-only and wall-side measurements are not interchangeable. | Meter method, time window, and included equipment. |
| Accepted hashrate | Pool-side accepted work, local reporting, and elapsed window can differ. | Source, observation window, rejects or errors, and timestamps. |
| Operating context | Cooling, airflow, network interruptions, and configuration affect results. | Relevant logs and a condition record. |
Do not convert a nameplate value into a promised outcome. For measurement terms and window selection, see the educational hashrate measurement guide.
Pool, solo, and node roles
| Role | What it does | What it does not establish |
|---|---|---|
| Hashing device | Hashes the job it receives against a target. | Independent transaction validity, template policy, or an assured outcome. |
| Template builder or job distributor | Can assemble a candidate template and distribute jobs. | That the endpoint is an independently operated validating node. |
| Full node | Independently validates blocks and enforces the consensus rules it runs. | That it will find a block or operate a hashing device. |
| Pool | Can distribute work and account for shares under its stated terms. | A direct solo-mining attempt or a fixed payout result. |
Pool shares use a pool-selected share target for work accounting; a valid Bitcoin block must meet the network target. A direct solo attempt is probabilistic. Read how Bitcoin mining works and the planned payout-method guide before treating a pool display as a protocol result.
A compact probability and evidence worksheet
For a chosen observation period, enter your own compatible estimates: device hashrate Hm, network-hashrate estimate Hn, and the number of blocks in that same period B. A simple expectation is E[discoveries] ≈ (Hm / Hn) × B. It is an expected count under stated assumptions, not a prediction, payment calculation, or device comparison.
- Record the source and time window for
Hn; a network estimate is not a direct count of machines. - Use accepted hashrate over a stated window for
Hmwhen possible; identify any rejected or stale work separately. - Keep the units and time period consistent, then record uncertainty rather than claiming precision.
- Do not add price, block-value, fee, or income assumptions to this protocol-level worksheet.
Setup safety and threat model
Follow the exact documentation for the identified revision. This guide does not size power equipment, instruct live probing, or replace a manual. Stop and seek qualified help for damaged equipment, abnormal heat, odour, noise, repeated resets, or uncertain power compatibility.
- Provenance: compare the board revision with a pinned source; independently verify firmware file origin, digest, and compatible configuration.
- Change control: record the prior known-good firmware and configuration; make one documented change at a time and retain logs.
- Network: use unique credentials, restrict administrative access, and review the destination and configuration before enabling operation.
- Boundary: protect wallet credentials and recovery material; a device dashboard is not a substitute for an independent validating node or secure key handling.
- Site: use the applicable manufacturer/project documentation and qualified support for electrical, thermal, building, and fire questions. For feasibility evidence, see the commissioning guide.
Learning and lottery-mining use cases
A small open-source SHA-256 device can support hands-on learning about jobs, targets, firmware provenance, cooling observations, pool accounting, and the difference between local reporting and accepted work. “Lottery mining” describes a low-probability attempt, not a promise of discovery. Keep protocol learning separate from an operational or financial decision; the mining risk guide maps the broader evidence needed.
Frequently asked questions
What is a Bitaxe?
Bitaxe is a family of open-source Bitcoin mining hardware projects. A particular device should be identified by its board revision, component evidence, firmware revision, and configuration rather than by the family name alone.
Is every part of a Bitaxe open source?
No. Hardware design files and firmware can be published while an ASIC chip, assembled unit, replacement part, service, or later modification may have different provenance. Check the exact revision evidence.
Does Bitcoin require ASIC hardware?
No. Bitcoin consensus specifies SHA-256 proof of work, not a hardware type. ASIC use is an implementation and market outcome, not a consensus rule.
What is the difference between nameplate and measured performance?
Nameplate values describe a stated configuration. Measured wall power and accepted hashrate depend on the identified board, firmware, settings, measurement boundary, operating conditions, and observation window.
Is pool mining the same as solo mining?
No. A pool can distribute work and account for contributed shares under its own rules. Direct solo mining attempts to publish a valid block independently. Both remain probabilistic.
Can a Bitaxe guarantee a block or a payment?
No. Hash attempts are probabilistic and an individual device has no assured discovery or payout outcome.
Does the device validate Bitcoin transactions or choose a block template?
A hashing device works on a supplied job. Independently operated full nodes validate blocks and enforce consensus rules. Template construction and job distribution can be performed elsewhere.
What should I verify before using firmware?
Match the board revision to the documented source, identify a pinned release or commit, verify the file and provenance independently, retain the prior known-good state, and follow the exact project documentation.
