What Is Proof of Work? How Bitcoin Mining Secures the Blockchain

Why a shared ledger needs more than signatures

A digital signature can demonstrate that a transaction satisfies an owner’s spending conditions. It cannot, by itself, settle which of two conflicting payments should become part of a shared history.

Imagine someone signs two transactions spending the same coins: one pays a shop, while the other sends those coins back to another address they control. Different participants might see different transactions first. The network needs a way to converge on one ordering without appointing a referee.

This is the double-spending problem addressed in the Bitcoin white paper. If the underlying ledger is unfamiliar, start with how a blockchain works.

Simply counting computers would not solve the problem. One participant could create many identities. Proof of work makes influence over block production depend on computational effort rather than the number of accounts someone creates.

A useful model: a lottery with checkable entries

Think of mining as repeatedly generating lottery entries. Most attempts fail. Occasionally, one meets a publicly known condition, and everyone else can check it.

The analogy helps explain why more attempts improve a miner’s chances without guaranteeing the next win. It also explains why yesterday’s unsuccessful attempts do not make today’s next attempt “due” to succeed.

But there is no lottery company, no ticket seller, and no official drawing. A miner generates attempts locally. The acceptance condition comes from the protocol, and participants verify it independently.

What miners actually calculate

A miner prepares a candidate block containing transactions and a compact summary called a block header. Bitcoin’s header includes a reference to the previous block, a commitment to the candidate’s transactions, and a changeable number called a nonce.

The miner hashes this header using SHA-256 twice. A hash is a fixed-length output calculated from an input. Identical inputs produce identical outputs, but changing the input produces an output that miners cannot usefully predict in advance.

Bitcoin interprets the resulting hash as a number. To satisfy proof of work, that number must be less than or equal to the required target. A smaller target leaves fewer acceptable results and makes success harder. These fields and rules are documented in the Bitcoin block reference.

Mining therefore consists of changing candidate data and trying again. It is not decrypting transactions or solving a scientific problem hidden inside a payment.

A deliberately simplified example

Suppose an imaginary hash function produces evenly distributed whole numbers from 0 to 999. Our invented rule accepts only results below 10.

That gives each fresh attempt a 1% chance of success. A sequence might produce 742, 315, 908, and then 6. The fourth attempt succeeds. Another sequence might fail hundreds of times.

On average, finding a successful result would take 100 attempts. That average is not a promise about any individual search.

These numbers are teaching aids, not Bitcoin parameters. The point is the imbalance: searching may require many attempts, while checking a submitted result requires recalculating that result and comparing it with the threshold.

Finding a hash is only part of producing a block

Mining software assembles candidate data and supplies work to hashing hardware. When available nonce values are exhausted, it can change other permitted data to create fresh candidates.

A successful header accompanies the proposed block when it is broadcast. The Bitcoin mining guide describes this division between constructing blocks and repeatedly hashing their headers.

Receiving a block does not mean accepting it. A full node independently checks the applicable consensus rules, including transaction validity and the permitted creation of new coins. Proof of work is one check among several.

A valid block can contain a special transaction claiming the allowed block subsidy and transaction fees. A miner cannot increase that allowance merely by producing an exceptionally difficult hash. Nodes enforcing Bitcoin’s rules reject invalid blocks, as explained in the blockchain developer guide.

How independent participants converge on a history

Bitcoin does not have one central inbox. Transactions and blocks travel between peers, so participants can receive information at different times. The peer-to-peer networking guide explains this exchange of data.

Two miners can find valid blocks extending the same parent before hearing about each other. Temporarily, different participants may follow different branches.

Among valid competing chains, nodes select the one with the most accumulated proof of work. “The longest chain” is common shorthand, but block count alone is not the precise rule when difficulty differs.

Switching to a competing branch is called a chain reorganization. Transactions in displaced blocks may return to the unconfirmed state or be included again, unless they conflict with the replacement history. The developer guide’s discussion of forks explains this process.

Why difficulty changes

If computing power increases while the target stays unchanged, successful results tend to arrive faster. If computing power disappears, they tend to arrive more slowly.

Bitcoin’s main network adjusts its difficulty every 2,016 blocks, aiming for an average interval of roughly ten minutes. Individual blocks can arrive much sooner or much later.

The adjustment follows protocol rules; miners cannot simply select an easier target and expect other nodes to accept it. Bitcoin Core implements the calculation and target checks in its proof-of-work code.

This is a feedback mechanism, not a clock. It responds at adjustment boundaries rather than instantly correcting every change in mining power. A long wait for one block therefore does not, by itself, mean the network has stopped working.

Why rewriting a payment requires more work

Consider a hypothetical payment from Maya to a bookshop. It enters a block, and later blocks build on top of it.

To replace that payment with a conflicting spend, an attacker needs a different history. Changing the earlier block changes its hash, breaking the links used by its descendants. The attacker must produce replacement work while competing with miners extending the existing chain.

Under the white paper’s model, an attacker with less hashing power than the honest miners becomes less likely to catch up as the lead grows. This is a conditional security argument, not a declaration that reversal is mathematically impossible. The assumptions and probability model appear in the original paper.

A transaction has one confirmation when included in the active chain, two when another block builds on it, and so on. Confirmations describe its position within that history; they are not separate approvals from individual people.

The payment-processing guide connects confirmation depth with double-spending risk. For the distinction between broadcasting and confirmation, see what “sent” means in a crypto transfer.

What proof of work cannot guarantee

A powerful attacker can contest transaction history

An attacker controlling sustained majority hashing power can attempt to outpace other miners, reorganize recent history, or obstruct transaction inclusion. The familiar “51% attack” label describes majority control, not a threshold below which every attack becomes impossible.

However, hashing power does not reveal private keys or make invalid spending valid. Nodes still enforce transaction and issuance rules. The Bitcoin FAQ distinguishes mining influence from permission to break those rules.

Mining consumes resources and can concentrate

Repeated hashing requires hardware and energy. That cost is part of the security mechanism, but it is also a real operating requirement. Proof of work does not make those resources free merely because the resulting ledger is useful.

Ethereum’s proof-of-work documentation discusses this resource tradeoff. Ethereum itself now uses proof of stake; mining is not a requirement shared by every blockchain.

Bitcoin miners can also join pools to receive more regular payouts. Pools typically measure contributions through easier proofs called shares. Most shares are not sufficient to become Bitcoin blocks. This arrangement reduces payout variability but can concentrate block-building coordination, depending on how the pool operates. See the pool-mining explanation.

Ledger security does not solve wallet security

A correctly authorized payment can still be a mistake. If someone tricks you into sending coins to their address, mining does not evaluate the story they told you.

Similarly, stronger protection against rewriting history cannot recover a lost private key. These are different layers of security. Our guide to wallets, keys, and transactions explains the authorization layer.

How to use this model when reading about crypto

• Identify the network. Bitcoin’s mining rules should not be assumed to apply to every blockchain.
• Separate validity from ordering. Ask whether a claim concerns which transactions are allowed or which valid history becomes accepted.
• Read confirmations as increasing assurance. A confirmation count is not an unconditional guarantee of irreversibility.
• Question claims of unlimited miner power. Block production and independent rule enforcement have different roles.
• Keep wallet risks separate. Mining does not protect a disclosed recovery phrase or correct a mistaken recipient.

To compare a different approach, read how proof of stake reaches consensus without mining. The useful comparison is how each system makes attacks costly and resolves disagreement.