Mining software list

Mining software monitoring ASIC hardware

Bitcoin mining software coordinates work among ASIC mining hardware, a mining pool and, in some configurations, a local Bitcoin node. The category includes device firmware, host-side controllers, pool clients and proxies, block-template services, monitoring systems and fleet-management tools. Many programs found in early software lists are historical CPU, GPU or FPGA miners and are not suitable for the modern Bitcoin network.

This page is an encyclopedic overview rather than a download directory. Mining software can control high-power hardware, redirect hashrate and handle pool credentials. Operators should obtain it from a hardware vendor or an authenticated project repository, verify signatures or hashes when available, and avoid repackaged binaries promoted through advertisements or search results.

How the mining software stack works

Modern Bitcoin mining normally separates several functions:

• A Bitcoin node validates transactions and blocks. Its getblocktemplate interface can provide the data needed to construct a candidate block.
• A template service selects transactions, builds candidate block templates and updates them when a new block or relevant transaction arrives.
• A pool server divides work among participants, sets share targets and accounts for valid shares. A share proves that a miner performed work at a lower difficulty than the network requires; it is normally evidence for pool accounting, not a Bitcoin block.
• Mining protocol software distributes jobs and returns shares. Stratum V1 became common in pooled mining. Stratum V2 defines separate mining, job-negotiation and template-distribution protocols and supports channels, proxies and custom jobs.
• Firmware and controller software configure ASIC frequency, voltage, fans and pool endpoints, then report temperature, errors, accepted and rejected shares and hashrate.
• Fleet-management systems aggregate those measurements across many devices and may automate restarts, tuning, power limits or curtailment responses.

These components need not be supplied by one vendor. A farm can use vendor firmware, a local proxy, a third-party pool and its own monitoring stack. A solo miner can connect template and block-submission software to a node without pool accounting. The software that runs a miner is distinct from the Bitcoin Core wallet and graphical program historically called Bitcoin-Qt: Bitcoin Core can validate the chain and supply templates, but it is not a general-purpose ASIC fleet controller.

Protocols and job selection

A mining job includes data from which devices construct block-header candidates. ASICs vary the nonce and other mutable fields, hash each candidate and report results below the pool's share target. The pool checks submissions and broadcasts new work when the previous template is obsolete. Delayed jobs can produce stale shares, while invalid settings or unstable hardware can produce rejected shares and hardware errors.

Protocol design affects more than bandwidth. A traditional pool can choose the complete transaction set for its miners. Stratum V2's job-declaration design aims to let miners or independent template providers propose transaction sets while preserving pool accounting. Its design goals also include efficient binary messages and authenticated, encrypted connections. These capabilities depend on implementation and pool support; the existence of a specification does not mean every deployed miner can use every feature.

Current and historical programs

Project	Historical or present role	Status and cautions
CGMiner	C-based controller for many FPGA and ASIC devices; earlier versions also supported GPU mining	The upstream owner archived the repository on 27 May 2020. Its code and device history remain important documentation, but it should not be described as maintained current software.
BFGMiner	Modular C miner with drivers for ASIC and FPGA devices, a command interface and remote monitoring	The source repository remains available, but compatibility is specific to hardware, operating system and build. Old binaries and instructions must not be assumed safe or current.
Stratum V2 reference implementations	Open protocol libraries and applications for pool, proxy, template-provider and mining roles	Active development does not imply support by every pool, controller or ASIC. Deployment requires matching protocol versions and testing failover and payout configuration.
BTCMiner	Java-based controller associated with early FPGA mining hardware	Historically significant for the FPGA period; not a controller for current commercial SHA-256 ASIC fleets.
DiabloMiner, Phoenix miner, Poclbm, Pyminer and RPC Miner	Early GPU or CPU mining clients	Historical software from the period when general-purpose hardware could participate meaningfully. Dependencies, pool protocols and download links may no longer work.
MinePeon and Modular Python Bitcoin Miner	Controller or appliance projects for early USB, FPGA or mixed-device installations	Useful examples of early miner management; old system images should not be placed on an untrusted network without review.

Some older lists mixed Bitcoin miners with programs for unrelated proof-of-work algorithms, browser mining, closed cloud services and unnamed Windows applications. A familiar brand name or a claim of multi-currency support is not evidence that a program mines SHA-256 Bitcoin, supports a particular ASIC, or remains maintained. Such entries are better preserved in dated history than presented as current recommendations.

Firmware and fleet management

Commercial ASICs usually run embedded firmware and expose a web interface, command API or management protocol. Firmware initializes hash boards, regulates temperature, controls fans and voltage and maintains pool connections. Alternative firmware may offer per-chip tuning, power targets, monitoring or fee arrangements. It can also change warranty coverage, device life, thermal behaviour and who receives part of the hashrate.

Fleet software discovers miners, stores configuration and presents facility-wide measurements. Useful metrics include accepted and rejected hashrate, stale-share rate, chip and board temperatures, fan speed, power draw, pool latency and restart frequency. Reported nominal hashrate is not enough: unstable overclocking can increase displayed speed while worsening efficiency or rejected work.

Security and operational checks

The first compatibility question is the exact ASIC, control board and firmware version. Installing generic desktop software does not make a commercial ASIC faster. Before deployment, an operator should:

• verify the source, release identity and supported hardware;
• record configuration and provide a tested recovery image;
• change default credentials and isolate management interfaces from the public internet;
• restrict APIs that can change pools, frequency or voltage;
• test thermal shutdown, fan failure and network failover;
• monitor unexpected pool destinations or developer fees; and
• roll out changes to a small group before updating a full farm.

Compromised mining software can redirect work without stealing a wallet key, so payout and pool configuration still deserve integrity monitoring. Conversely, a miner does not normally need access to a spending wallet; separating those credentials limits the effect of a device compromise.

Mining profitability is not a property of a software name. It depends on hardware efficiency, electricity and cooling costs, pool fees, uptime, network difficulty, block subsidy, transaction fees and the bitcoin exchange rate. Claims that a generic desktop application can profitably mine Bitcoin on an ordinary CPU or GPU are obsolete or misleading.

Historical development

The original Bitcoin software could generate blocks with a CPU. Independent clients later exploited GPUs' parallel arithmetic, followed by FPGA designs and then SHA-256 ASICs. Each transition changed the useful software: desktop miners gave way to hardware drivers, embedded firmware, proxies and data-centre fleet tools. Pool mining also shifted attention from finding occasional full blocks to reliable share submission and accounting.

Early software lists remain evidence of this development. Their operating-system labels, performance tables and download links, however, describe a past hardware and security environment. Recording the projects, language and role is more durable than treating every old executable as a current option.

See also

• Bitcoin mining
• Mining farm
• Pooled mining
• Stratum mining protocol
• CGMiner