Quick answer: Bitcoin mining is the search for a block-header hash at or below the network target. Mining software builds or receives candidate-block work, an ASIC performs repeated SHA-256 hashing, and a successful block is broadcast. Independently operated full nodes—not the miner’s claim—decide whether that block and every transaction in it satisfy their consensus rules. Pools coordinate work and payouts; a pool share is evidence of work for the pool, not necessarily a Bitcoin block.
Scope and commercial-interest disclosure: D-Central sells, services, and supports Bitcoin mining equipment. That is a financial interest. This page explains protocol roles and an evidence-first operating workflow; it does not promise profit, a block, a payout, equipment compatibility, or a safe installation. Use current software documentation, the exact equipment manual and nameplate, your pool or solo-service terms, and the authorities and qualified professionals responsible for the site.
Start with the roles: wallet, full node, work coordinator, miner
The word miner is often used for several different systems. Keeping them separate prevents one of the most common Bitcoin explanations from going wrong.
| Role | Primary job | What it does not establish by itself |
|---|---|---|
| Wallet | Constructs and signs a transaction using the keys or signing policy it controls. | Signing does not ensure relay, inclusion, confirmation, or later settlement confidence. |
| Full node | Checks transactions and blocks against its consensus rules, maintains its view of the valid chain, and may relay policy-acceptable data. | A node does not need to perform mining work, and one node’s mempool is not a global queue. |
| Template or job coordinator | Selects candidate transactions and constructs or distributes work. This may be the operator’s own node/software or a pool/service. | Choosing a transaction does not make an invalid transaction valid; full nodes still check the completed block. |
| ASIC miner | Evaluates enormous numbers of block-header candidates and reports results meeting the assigned target. | An ASIC does not independently validate the entire chain merely because it hashes. |
| Pool | Coordinates jobs, measures submitted shares, may submit network-valid blocks, and applies its payout rules. | A pool share is not automatically a block, on-chain payment, or proof of the pool’s solvency. |
Mining contributes proof of work and block ordering. Economic actors using fully validating nodes decide what they accept as Bitcoin by enforcing their own rules. A miner can propose a block; it cannot require independently validating nodes to accept an invalid one.
From a signed transaction to a confirmed block
- Create and sign: a wallet selects inputs, defines outputs and a fee, then produces the required signatures or witnesses.
- Relay: the wallet or a node sends the transaction to peers. Each node applies consensus checks and its own relay/mempool policy. Nodes can have different mempools.
- Build candidate work: a node, solo-mining stack, pool, or other coordinator selects transactions and constructs a candidate block, including a coinbase transaction.
- Search: mining hardware hashes header candidates. Changes to the nonce, extra-nonce-dependent Merkle root, time, version bits, or other permitted fields create more candidates.
- Broadcast: when a result satisfies the network target, the completed block is sent to peers.
- Validate independently: full nodes check proof of work, block structure, transaction validity, permitted value creation, and the rest of their consensus rules before extending their accepted chain.
- Accumulate confirmations: later accepted blocks add proof of work above the transaction’s block. Reorganization risk generally falls as work accumulates, but an appropriate acceptance threshold depends on value, context, counterparty risk, and the receiver’s validation model.
A transaction shown as “pending,” present in one mempool, or broadcast to a peer is not the same thing as a confirmed transaction. A confirmation is also not a universal legal or commercial finality rule. Receivers define their own risk policy.
What proof of work actually searches
A Bitcoin block header is 80 bytes. It commits to the previous block hash, a Merkle root derived from the block’s transactions, time, the compact target representation, a nonce, and version information. Mining repeatedly applies Bitcoin’s header-hashing function and interprets the result as a number. The candidate satisfies proof of work when that number is at or below the target.
The ASIC is not solving a transaction-specific equation and it is not decrypting anything. Each hash is an independent candidate test. A result can meet a pool’s easier share target without meeting the Bitcoin network target. That is useful accounting evidence for the pool, but it is not a new Bitcoin block.
Candidate block
The coordinator chooses the transaction set and coinbase destination or policy, then derives the Merkle commitment and header work. BIP 22’s getblocktemplate interface is one documented way for software to request data needed to construct a block.
Hashing device
The device searches assigned header space and reports qualifying results. Its dashboard hashrate is an estimate derived from work over time; wall power requires a suitable external measurement, not a dashboard assumption.
Target, difficulty, hashrate, and time
The target is the threshold a valid block-header hash must not exceed. “Difficulty” is a human-readable ratio derived from that target. Bitcoin retargets its proof-of-work threshold every 2,016 blocks using the protocol’s bounded timing calculation. The aim is an average block interval over time; it is not a ten-minute appointment for each block.
Network hashrate is not directly counted. It is estimated from observed blocks and difficulty over a chosen window, so different windows and endpoints can report different values. Treat every current network number as a timestamped estimate. For current, attributable data, use the open mining data hub or your own node’s documented RPC results instead of copying a number into evergreen prose.
More hashrate raises the probability of finding a qualifying hash per unit time. It does not create a schedule for one device. The solo mining probability calculator expresses that uncertainty; expected time is a statistical mean, not a countdown.
Subsidy, transaction fees, and the coinbase transaction
The first transaction in a block is the coinbase transaction. Subject to consensus limits, it can claim the block-height-dependent subsidy plus fees from the included transactions. “Block reward” is convenient shorthand, but it hides two different components:
- Subsidy: newly issued bitcoin determined by block height and the consensus schedule.
- Transaction fees: the difference between inputs and outputs of transactions included in that block; the total varies by the chosen transaction set.
Do not hard-code today’s subsidy, fee total, bitcoin price, or fiat value into an operating decision. Read height and block data from a current validating source, label its timestamp, and keep fiat conversion separate. In a pool arrangement, the block’s coinbase output and the miner’s later pool payout are also separate events governed by the pool’s disclosed method and terms.
Solo mining and pooled mining are arrangements, not device types
| Question | Solo or self-coordinated path | Pool-coordinated path |
|---|---|---|
| Who constructs the template? | Your node and mining stack, or a service whose exact role you verify. | The pool commonly distributes the job; supported miner choices depend on the protocol and implementation. |
| Who controls the coinbase destination? | Verify it in your configuration and resulting template; do not infer it from a marketing label. | Usually the pool, which later accounts to miners under its payout terms. |
| What does a submitted share mean? | Not applicable unless the chosen service uses an accounting share layer. | Evidence that assigned work met the pool target; only a rarer result also meets the network target. |
| How are payments determined? | A found block’s coinbase policy and the selected stack govern the on-chain destination. | Method, fees, thresholds, reserves, custody and timing are contractual and operational dependencies. |
| Primary risk shape | High variance, configuration and node-availability responsibility. | Coordinator, accounting, custody, policy and counterparty dependencies in exchange for smoother modeled payouts. |
Use the solo-versus-pool decision guide to document these dependencies. “Solo” in a product or service name does not by itself prove who builds templates, controls payout keys, holds funds, or sets a minimum payout.
Mining economics begin with measurements and contracts
A useful evaluation keeps protocol probability separate from site economics. At minimum, record:
- the exact device, hardware revision, firmware version, configured mode, and current manufacturer documentation;
- measured wall input in a stable state, accepted hashrate over a defined window, rejected/stale shares, and downtime;
- the complete tariff: energy, demand, fixed charges, taxes, seasonal/time-of-use rules, and the correct customer class;
- ventilation, noise, maintenance, network, insurance, building, electrical, and labour constraints;
- pool or service fee, payout method, threshold, custody path, template policy, and failure history;
- timestamped difficulty, network-hashrate estimate, fee assumption, exchange rate, and sensitivity range.
The mining profitability calculator can organize scenario inputs, but its output is not a quote or forecast. Test adverse cases and define a stop rule before buying hardware.
A defensible start-to-hash workflow
- Define the goal: learning, probabilistic solo participation, a pool payout profile, heat reuse, or a measured commercial operation have different acceptance criteria.
- Choose exact equipment: verify model, revision, power supply, connectors, firmware support, manual, condition, and provenance. The ASIC miner database is a discovery aid; reconcile it to the exact manufacturer record and nameplate.
- Approve the site: obtain the electrical, ventilation, noise, fire, building, insurance, landlord, utility, and network decisions that apply locally.
- Secure the payout path: use a wallet and backup process you understand; verify addresses on a trusted display or channel; record who can change pool and payout settings.
- Baseline before tuning: update only through an authenticated, compatible path; start in a documented stock mode; record wall power, accepted work, errors, temperatures and alarms over a defined window.
- Change one variable: use bounded, reversible changes with abort criteria. Never treat a displayed hashrate increase alone as an efficiency improvement.
- Retain evidence: keep configuration exports, logs, firmware provenance, measurements, timestamps and the last accepted state.
New operators can continue with the home-mining start guide and use the Bitcoin Mining Facts Canon to check frequently repeated technical claims.
Primary sources and review boundary
- Bitcoin: A Peer-to-Peer Electronic Cash System — original proof-of-work, network and incentive design.
- Bitcoin Core: Validation — why full validation is independent of miners.
- Bitcoin Developer Guide: Mining — block templates, headers, ASIC work, pool targets and shares.
- BIP 22: getblocktemplate fundamentals — block-template and proposal interface.
- Bitcoin Core 31.0 getblocktemplate RPC — current RPC fields and rules as reviewed.
- Bitcoin Core validation source — implemented block and chain validation context; the branch can change, so pin a commit for an audit.
Sources reviewed 2026-08-30. Software, documentation, pool terms, equipment records, network estimates, regulations, tariffs and URLs can change. Re-check the version and timestamp that govern your decision.
Frequently asked questions
Do miners validate Bitcoin transactions?
A template-building node or coordinator may select and validate transactions; a hashing client or ASIC may receive prepared work and need not perform full transaction validation. Independently operated full nodes decide whether a received block and its transactions satisfy their consensus rules.
What is a Bitcoin miner trying to find?
It searches for a block-header hash whose numeric value is at or below the assigned target. Meeting a pool’s easier share target proves work to that pool; only a result at or below the Bitcoin network target can support a candidate network block.
Does Bitcoin produce one block exactly every ten minutes?
No. Proof of work is probabilistic. The protocol adjusts the target to aim for an average interval over time, while individual blocks can arrive much sooner or later.
Is network hashrate an exact live count?
No. It is estimated from observed block production and difficulty over a selected window. Always record the source, method, window and timestamp when using it.
Is a pool share the same as finding a Bitcoin block?
Usually not. A share meets the pool’s accounting target. By chance, a share can also meet the harder network target; only then can the corresponding complete, valid block be submitted to Bitcoin nodes.
Where does mining revenue come from?
A valid block’s coinbase transaction may claim the height-dependent subsidy and fees from included transactions. A pool miner is paid according to the pool’s separate method, fees, thresholds and custody terms.
Can a profitability calculator predict my result?
No. It evaluates assumptions. Difficulty, network participation, fees, exchange rates, uptime, measured efficiency, tariffs and failures can change, so use ranges and pre-defined stop rules.
What should I verify before powering an ASIC?
Verify the exact model, revision, power supply, connectors, manual, condition and firmware; obtain the required electrical and site approvals; confirm ventilation and emergency isolation; and secure the network and payout configuration. Keep damaged, wet or incomplete equipment de-energized.
