Proof-of-work mining

What Bitcoin miners actually do

Bitcoin mining combines transaction selection with a competition to produce an acceptable block header. A miner assembles a candidate block, commits to its transactions through a Merkle root and repeatedly hashes the header while changing permitted fields. A successful hash must meet the network’s current target. Hashing faster increases the number of attempts a miner can make; it does not let the miner choose a successful result in advance.

The candidate normally includes transactions that pay fees and a special coinbase transaction claiming the permitted subsidy and fees. A mining pool can distribute work to participants and record easier proofs, usually called shares, to account for their contributions. A pool share is evidence of submitted work under that pool’s rules. Most shares are not valid Bitcoin blocks, so a dashboard full of accepted shares is not a list of blocks the participant has independently produced. Bitcoin developer guide: mining.

A valid proof of work is only part of block validation

Full nodes check the block and its transactions against their consensus rules. Among other checks, spending conditions must be satisfied and an ordinary transaction cannot create outputs worth more than its inputs. The miner’s coinbase must also stay within the allowed reward. An expensive proof of work attached to a block that violates these rules does not make the block acceptable to a node enforcing them.

This distinction matters when someone claims that miners can take any coins they want. Computing power does not reveal another user’s private key. Reordering valid transactions, replacing a payment made by the attacker and inventing a signature for somebody else’s coins are different capabilities. A discussion that bundles them together produces a misleading picture of both the attack and the defence. Bitcoin developer guide: transactions.

How competing histories are resolved

Miners can find competing blocks before either block has reached every participant. Nodes then have alternative valid histories to consider. Bitcoin’s chain selection depends on accumulated proof of work, rather than a vote in which every advertised node receives an equal ballot. A replacement history must satisfy the validation rules as well as compete on work. Simply creating many network identities does not provide the equivalent of mining power.

Bitcoin adjusts its mining target every 2,016 blocks using the elapsed time recorded in the preceding adjustment period. Its intended average block interval is about 10 minutes. That is a statistical target, not an appointment: individual blocks can arrive quickly or after a longer wait. A block explorer temporarily showing no new block is therefore not, by itself, evidence that the network has stopped working. Bitcoin developer guide: the blockchain.

Confirmations reduce a particular risk

A payment receives its first confirmation when it is included in a block on the accepted chain. Additional blocks extend that history. Replacing an older payment then requires competing with more accumulated work. The Bitcoin whitepaper models an attacker trying to catch up with an honest chain and explains why the attacker’s computing share and the depth of the payment matter.

A confirmation does not check whether a seller will deliver an order, whether an exchange has enough assets to repay depositors or whether a token promoted as a Bitcoin investment is honest. Those risks remain outside Bitcoin’s block validation. For example, an exchange can credit a genuine confirmed deposit and subsequently lend the customer’s assets to a related company. The blockchain record may be correct while the customer’s custodial claim becomes impaired. Bitcoin whitepaper, sections 5 and 11.

How to examine a mining investment claim

Start by identifying what is actually being sold. Ownership of a machine, a contract for a share of its output, a hosted account balance and a token supposedly backed by mining are different arrangements. A transaction from a mining pool to a company shows that the company received a payment. It does not establish that a particular customer owns a machine or has an enforceable claim to that payment.

As an investigative example, consider an operator showing a pool dashboard alongside a fixed daily return. The dashboard should be reconciled with the claimed hardware, operating period and payout records. The fixed-return promise separately requires an explanation of who covers shortfalls when operating costs or output change. A photograph of equipment cannot answer that contractual question. An unexplained gap should remain an unresolved claim, rather than being filled with either an endorsement or an unsupported accusation.

Keep the original offer, payment address, contractual terms and dated screenshots together. Compare the operator’s advertised output with the records they actually provide, and distinguish gross receipts from the amount available after expenses and obligations. This is an assessment of a business and its claims, not another proof-of-work calculation.

Sources

• Bitcoin developer documentation
• Mining: block construction, pools and submitted shares
• Transaction validation and spending conditions
• Proof of work, difficulty and competing chains
• Satoshi Nakamoto: Bitcoin whitepaper