At 09:40:46 UTC on 7 November 2026, a blockchain and earns a reward, which makes rewriting history very expensive.">mining smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool called SECPOOL announced Bitcoin block 974,916. Written in hexadecimal, the block’s identifier begins with 21 zeros: 000000000000000000000123c5c7 and so on. Any laptop can confirm in well under a millisecond that this number sits below the bar the network demanded at that moment. Finding it took, on average, about 637 sextillion attempts by the mining machines of the whole planet.
That gap, ruinously expensive to produce and almost free to verify, is the core of the answer to the question what is proof of work. It is a lottery in which every ticket costs electricity and every winning ticket can be checked by anyone with a single hash computation. Behind that simple picture sit a handful of precise rules: which 80 bytes get hashed, how the bar is encoded, how Bitcoin pulls blocks back towards ten minutes apart, and why a chain carrying more work beats one carrying more blocks. Each of them has a number attached as of 7 November 2026, and a couple of them still hide bugs from 2009.
What is proof of work: costly to make, cheap to check
The previous lesson, on the Byzantine generals problem, ended on a hard question: how can thousands of strangers who do not trust each other agree on one history when some of them may lie? Proof of work is Bitcoin’s answer, and it is a probabilistic one. Nobody votes with an identity, which is cheap to fake. Participants vote with computation, which cannot be faked, and the history backed by the most computation wins. Our overview of how blockchains reach consensus places it next to the other families of mechanisms; this lesson stays inside it.
Satoshi Nakamoto summed it up in section 4 of the Bitcoin white paper: “Proof-of-work is essentially one-CPU-one-vote.” The sentence just before explains the choice. A majority counted by IP addresses could be captured by anyone able to obtain many addresses; processing power is far harder to multiply for free. Our section-by-section reading of the white paper covers the rest of the document, while this lesson goes into the mechanics the paper only sketches.
The idea is older than Bitcoin. Adam Back’s Hashcash, invented in 1997, asked a computer to find a hash with a set number of leading zero bits before its email or request would be accepted: a small stamp paid in computation, painless for one message and costly for a million. Section 4 of the white paper describes Bitcoin’s system as one “similar to Adam Back’s Hashcash”. That history, along with b-money and bit gold, is told in our lesson on digital money before Bitcoin. Bitcoin added two things Hashcash never needed: a bar that moves with the total computing power, and a chain in which each block’s work is stacked on all the work before it.
Picture the search as a lottery with no shortcut. A miner assembles a candidate block, hashes its header and looks at the result. If the number is low enough, the block is valid and the miner collects the reward. If not, the miner changes one small field and tries again. The output of a good hash function cannot be predicted from its input, so there is no cleverer strategy than trying. That is why the number of attempts per second, the hashrate, is the only thing that counts in this race.
What a Bitcoin miner hashes, billions of times a second
Twice SHA-256 over an 80-byte header
The object being hashed is tiny. It is the 80-byte block header you met in our lesson on what a block contains: version, hash of the previous block, Merkle root, timestamp, encoded target and nonce. The transactions are not rehashed on each attempt. They are summed up in the 32-byte Merkle root, so a block holding 2,029 transactions, like block 974,916, costs no more to try than an empty one.
Bitcoin runs SHA-256 over those 80 bytes, then runs SHA-256 a second time over the 32-byte result. Developers call this SHA-256d. The final 256 bits are read as one very large number, in little-endian byte order, which is why explorers display block hashes with their zeros at the front. Why a hash cannot be run backwards is a topic for a later lesson on hash functions. Here one property matters: flip a single bit of the header and the result changes completely, with no relation to the previous one.
The 32-bit nonce runs out in microseconds
The nonce field is 32 bits wide, so it holds about 4.29 billion values. That sounds like plenty until you put it next to a modern machine. Take a miner running at 200 terahashes per second, an example figure in the range of current high-end hardware: it would exhaust every possible nonce in about 21 microseconds. When BIP 320 was written in 2018, its authors already noted that hardware could burn through the whole nonce range in under 200 milliseconds. Machines have become far faster since.
So miners vary other parts of the block as well. The most common lever is the extranonce, a field the miner fills freely inside the input of the coinbase transaction, the one that pays the miner. Changing it changes that transaction’s hash, therefore the Merkle root, therefore the header, and a fresh range of 4.29 billion nonces opens up. The timestamp can move too, within limits set in Bitcoin Core’s code: a block’s time must be later than the median of the previous 11 blocks and no more than two hours ahead of the node’s clock.
The third lever is version rolling. BIP 320, still a draft, sets aside 16 bits of the header’s version field (bits 13 to 28) for general use, and mining chips roll them as extra search space, negotiated with pools through an extension of the Stratum protocol. The trace is visible on the live chain. Block 974,916 carries the version 0x2a000000 rather than the plain 0x20000000 a node writes by default. Its winning nonce, for the record, was 3,425,572,080.
Target, nBits and difficulty: three ways to write the same bar
Winning means exactly one thing: the header’s double hash, read as a number, must be lower than or equal to the current target. The target is itself a 256-bit number. The famous leading zeros are only a side effect. A smaller target forces more zeros at the front of any number that falls below it, but nodes run a comparison, not a count of zeros, and a hash with the right number of zeros can still fail if the digits after them are too high.
The header has no room for a 32-byte target, so it stores a compact 4-byte version called nBits. Its first byte is an exponent, the next three a mantissa, and the target equals the mantissa multiplied by 256 to the power of (exponent minus 3). Block 974,916 has nBits 0x1701e5ac. The exponent is 0x17, or 23, and the mantissa 0x01e5ac, so the target is 0x01e5ac followed by 20 zero bytes. Written as 64 hex digits, it begins with 19 zeros, about 79 zero bits. The winning hash, with 21 zeros in front, cleared it with room to spare.
Difficulty is the human-friendly form of the same number. It divides the easiest target the protocol allows (nBits 0x1d00ffff, the bar of the genesis block on 3 January 2009, difficulty 1) by the current target. As of 7 November 2026, Bitcoin’s difficulty stood at 148,364,561,003,867, about 148.36 trillion (written 148.36 T), according to mempool.space. Put simply, a block today is some 148 trillion times harder to find than one of the first blocks.
A handy rule of thumb follows. At difficulty 1, a miner needs on average 2 to the power 32 hashes, about 4.29 billion, to find a block. Multiply by today’s difficulty and you get the expected price of one block: about 6.37 x 1023 hashes, roughly 637 sextillion. Seen from the other side, each individual hash wins with odds of about one in 637 sextillion. A single machine can still get lucky on its first try; it is just vanishingly unlikely.
Bitcoin difficulty adjustment: ten minutes on average
A fixed target would not last. When more machines join, blocks would come faster; when miners switch off, slower. The white paper describes the fix in one line, a moving average aimed at a set number of blocks per hour. The code is more precise than the paper, and a little stranger.
Every 2,016 blocks, by at most a factor of four
In Bitcoin Core’s src/pow.cpp and its chain parameters, the target timespan is two weeks (1,209,600 seconds) and the target spacing ten minutes (600 seconds). Divide one by the other and you get the adjustment interval: 2,016 blocks. At the end of each interval, every node computes the new target on its own: old target, multiplied by the time the period actually took, divided by two weeks. Blocks too fast, the target shrinks and difficulty rises. Too slow, the reverse. Nobody announces the new difficulty. Every node reaches the same number from the same timestamps.
Two guard rails cap the move. If the measured period is shorter than a quarter of two weeks, the code uses a quarter; if it is longer than four times two weeks, it uses four times. Difficulty can therefore change by at most a factor of four in either direction per period. Real moves are much smaller. The largest drop on record came on 3 July 2021, at block 689,472: minus 27.94 percent, after China’s ban on mining pushed a large share of machines offline, per mempool.space data. The highest difficulty so far, 155.97 T, was set on 29 October 2025 at block 921,312.
The last eight adjustments, read from mempool.space on 7 November 2026, show the mechanism tracking the hashrate in small steps:
| Date (UTC) | Block | New difficulty | Change |
|---|---|---|---|
| 25 July 2026 | 959,616 | 126.23 T | -0.74% |
| 8 August 2026 | 961,632 | 127.48 T | +0.99% |
| 23 August 2026 | 963,648 | 125.81 T | -1.31% |
| 5 September 2026 | 965,664 | 127.45 T | +1.31% |
| 19 September 2026 | 967,680 | 132.76 T | +4.16% |
| 3 October 2026 | 969,696 | 132.72 T | -0.03% |
| 16 October 2026 | 971,712 | 140.58 T | +5.92% |
| 29 October 2026 | 973,728 | 148.36 T | +5.54% |
So how often does Bitcoin’s difficulty change? Every 2,016 blocks, which is about every two weeks, but the calendar gap varies: a little over 13 days between the two October adjustments, a little over 14 between those of 8 and 23 August. The next one falls at block 975,744. On 7 November 2026, mempool.space estimated it for around 13 November and projected a fall of about 4 percent, because blocks in the current period were averaging about 10 minutes 26 seconds. That projection moves with every block.
The off-by-one and the timewarp bug
The code carries a quirk from 2009. To measure a period, pow.cpp walks back from the period’s last block to its first. The comment above the line reads “Go back by what we want to be 14 days worth of blocks”, yet the line subtracts 2,015, not 2,016. The measured time therefore covers 2,015 block intervals but is compared with 2,016 times ten minutes. The direct effect is small: Bitcoin aims for an average about 0.05 percent slower than ten minutes.
The bigger consequence is that periods never overlap. The gap between the last block of one period and the first block of the next is never measured. That opens the timewarp attack. A majority of miners could stamp the last block of each period with the real time, which the rules allow, while keeping every other timestamp as low as the median rule permits. Each period then looks longer than it was, difficulty falls, and the trick can be repeated. The BIP 54 text puts the worst case bluntly: “an attacker can bring down the difficulty to its minimum within 38 days of starting the attack.” It would take majority hashrate and would be visible to everyone, but a consensus rule that tolerates it is still a hole.
BIP 54: the fix is written, not switched on
BIP 54, titled Consensus Cleanup and written by Antoine Poinsot and Matt Corallo, is a soft-fork proposal that closes four old weaknesses: the timewarp, the worst-case time needed to validate a block, a Merkle-tree ambiguity involving 64-byte transactions and duplicate coinbase transactions. For the timewarp, the new rule is short. The first block of a period may not carry a timestamp more than two hours (7,200 seconds) earlier than the block before it, and the last block of a period may not be earlier than the first block of that same period. Bitcoin’s newer test network, testnet4 (BIP 94), already applies a similar rule with a ten-minute grace.
Its status needs a careful reading. The BIP repository lists BIP 54 as Complete, which describes the specification, not the network. As of 7 November 2026 it is not active on Bitcoin’s main network and no activation date has been set. Until it is, the off-by-one and the timewarp remain part of the rules that every node enforces.
How much work is one Bitcoin block today?
The table gathers the live figures read from mempool.space’s public API on 7 November 2026, between 09:47 and 10:30 UTC (the estimates move with every block), with two values computed from them.
| Figure (7 November 2026) | Value |
|---|---|
| Latest block | 974,916, mined at 09:40:46 UTC by SECPOOL, 2,029 transactions |
| nBits of that block | 0x1701e5ac |
| Difficulty | 148.36 T, set at block 973,728 on 29 October 2026 (+5.54%) |
| Expected hashes per block (computed) | about 6.37 x 1023 |
| Hashrate needed for exactly 600 seconds per block (computed) | about 1,062 EH/s |
| Estimated network hashrate, 3-day average | about 1,012 EH/s |
| Average block time in the current period | about 10 minutes 26 seconds |
| Next adjustment | block 975,744, around 13 November 2026, projected about -4% (estimate) |
| Highest daily hashrate of the past 12 months | about 1,245 EH/s (27 November 2025) |
| Record difficulty | 155.97 T (29 October 2025) |
An exahash is a billion billion hashes. At roughly 1,000 EH/s, the network performs about 1021 double SHA-256 computations every second. The two hashrate lines explain the slow blocks of this period: difficulty was set for about 1,062 EH/s, the network has been delivering a little over 1,010, so blocks take slightly longer than ten minutes and the next adjustment should ease the bar. Hashrate figures are estimates, inferred from how fast blocks arrive at a known difficulty; nobody counts the machines.
Block times are random. Each hash is an independent draw, so the wait for the next block follows, roughly, an exponential distribution with a ten-minute mean. Simple arithmetic gives the odds, as an illustration rather than a forecast: about 9.5 percent of blocks arrive within one minute of the previous one, about 5 percent take longer than 30 minutes and roughly 0.25 percent take more than an hour. A long silence on the network is usually just bad luck.
Who supplies this hashrate, with which machines and at what electricity price, is the subject of the next lesson in this path, a full guide to Bitcoin mining.
Why proof of work protects Bitcoin’s history
A short reminder from our lesson on why a blockchain is so hard to change: to alter an old block, an attacker must redo its work and the work of every block stacked after it, and do it faster than the honest network keeps adding blocks. The white paper’s point is that spent work cannot be reused. Change one byte in an old block and its hash, and every hash after it, must be found again.
Strictly speaking, nodes do not follow the longest chain. The white paper speaks of “the longest chain, which has the greatest proof-of-work effort invested in it”, and Bitcoin Core implements the second half of that phrase. Each block counts for 2 to the power 256 divided by its target plus one, which is its expected number of hashes, and nodes follow the valid chain with the most accumulated work, a value the code calls nChainWork. A chain with more blocks at an easier difficulty loses to a shorter one carrying more total work. That rule closes a cheap trick: mining a long chain of easy blocks in private.
Two honest blocks found almost at the same moment create a short split that this rule settles within a block or two; the losing block becomes stale. Our lessons on finality and chain reorganisations and on how forks happen cover those cases in depth. The point here is that confirmation under proof of work is probabilistic. Each new block makes a rewrite exponentially less likely, never strictly impossible.
What an attack would cost, and why rental prices mislead
The site crypto51.app estimates what it would cost to rent, for one hour, as much hashrate as each network has. The figures below are those it displayed on 7 November 2026, from an update the page timestamps at 04:08 EST (09:08 UTC) that day.
| Network | Algorithm | Hashrate shown | Cost of a 1-hour attack | Share rentable on NiceHash |
|---|---|---|---|---|
| Bitcoin | SHA-256 | 946,836 PH/s | $1,800,721 | 0% |
| Bitcoin Cash | SHA-256 | 3,855 PH/s | $7,332 | 0% |
| Litecoin | Scrypt | 3 PH/s | $52,519 | 6% |
| Zcash | Equihash | 32 GH/s | $70,237 | 1% |
| Ethereum Classic | Etchash | 202 TH/s | $2,892 | 0% |
| Kaspa | kHeavyHash | 352 PH/s | $2,780 | 10% |
Read the last column first. For Bitcoin, 0 percent of the needed hashrate can be rented on NiceHash, the marketplace the site uses for prices. The $1.8 million is what an hour would cost if that much hashrate were for hire, and it is not. A real attacker would have to buy and power hundreds of exahashes of machines for months, and a visible attack could sink the value of the very coins those machines earn. The site also measures Bitcoin’s hashrate its own way, which is why its figure differs from mempool.space’s.
Bitcoin Cash shows the real danger. It runs the same SHA-256 as Bitcoin with about 0.4 percent of its hashrate, so a sliver of Bitcoin’s fleet could outrun it. Small chains that share an algorithm with a far larger one are exposed in this way, the pattern behind the 51 percent attacks on Ethereum Classic and Bitcoin Gold recounted in our lesson on whether a blockchain can be hacked.
For Bitcoin itself, the realistic concern is concentration rather than rental. Over the seven days to the morning of 7 November 2026, Foundry USA found 23.1 percent of blocks, AntPool 19.7 percent and F2Pool 17.2 percent, according to mempool.space: about 60 percent for the top three. A pool is not one owner. Its hashrate belongs to many miners who can leave, but the operator picks which transactions go into its blocks.
Selfish mining: when a minority earns more than its share
In November 2013, Ittay Eyal and Emin Gün Sirer of Cornell University published Majority is not Enough: Bitcoin Mining is Vulnerable. Their selfish-mining strategy works like this. A pool that finds a block keeps it secret and mines on top of it. When the honest network finds a competing block, the pool releases its hidden one to win the race, so honest miners waste work on blocks that end up stale. The paper shows that colluding miners following this strategy can earn more than their fair share of rewards.
The authors proposed a change to how nodes break ties, which would protect the network against selfish pools holding less than a quarter of the hashrate. They noted that this threshold is “lower than the wrongly assumed 1/2 bound” but better than the situation they described, in which a group of any size could profit. No large-scale case of selfish mining on Bitcoin has been proven. The paper’s lasting lesson is about incentives: proof of work makes cheating expensive, yet honest mining is the best strategy only under assumptions about how fast blocks travel across the network. Selfish mining and other network-level attacks will get their own lesson later in this path.
Proof of work beyond Bitcoin: Scrypt, RandomX and Ethash
SHA-256d is one design among several. Each proof-of-work network picks a hash function and a block time, and some pick a deliberate hardware bias. The table lists the cases this lesson checked against source code or official documentation. Ethereum Classic, Zcash and Kaspa, which also still mine, appear in the attack-cost table above.
| Network | Algorithm | Block target | Detail |
|---|---|---|---|
| Bitcoin | SHA-256d | 10 minutes | retarget every 2,016 blocks |
| Litecoin | Scrypt (N=1,024, r=1, p=1) | 2.5 minutes | retarget every 3.5 days, also 2,016 blocks |
| Dogecoin | Scrypt, merge-mined with Litecoin | 1 minute | AuxPoW from block 371,337 (11 September 2014, per CoinDesk and the block’s timestamp) |
| Monero | RandomX | 2 minutes | since block 1,978,433 (30 November 2019) |
| Ethereum | Ethash | none | proof of work ended with the Merge, 15 September 2022 |
Scrypt and merge mining: one hash, two chains
Litecoin replaced SHA-256 with Scrypt and cut the block target to two and a half minutes. Its source code names the hash function scrypt_1024_1_1_256, for the parameters N = 1,024, r = 1 and p = 1, which call for a 128 KiB scratchpad per hash. Scrypt was meant to be memory-hard, so that ordinary computers would keep pace with specialised chips. A 128 KiB scratchpad proved small enough to put on a chip, and dedicated Scrypt machines were built. Litecoin’s retarget runs every 3.5 days, which at 2.5 minutes a block is again 2,016 blocks.
Merge mining, also called merged mining or AuxPoW (auxiliary proof of work), lets one hash serve two chains that use the same algorithm. The miner builds a Litecoin block whose coinbase transaction also carries the hash of a Dogecoin block. If the result meets Dogecoin’s easier target, the miner hands Dogecoin a proof: the Litecoin header, the coinbase transaction and the branch linking it to that header’s Merkle root. Dogecoin checks the proof and accepts the work. If the same hash also meets Litecoin’s target, it wins a Litecoin block too. Miners pay nothing extra for the second chain.
Dogecoin, which targets one block per minute, switched merge mining on at block 371,337, a height written into its source code. CoinDesk reported the switch on 11 September 2014, and Blockchair dates block 371,337 to 19:42 UTC that day. A small chain borrowed the protection of a larger chain’s hashrate without asking miners to choose between them.
Monero’s RandomX: a bet against specialised chips
Monero went the other way. Since block 1,978,433, mined on 30 November 2019 according to the project’s technical specifications, it has used RandomX, which followed several versions of CryptoNight. RandomX makes each hash run randomly generated programs in a virtual machine, mixing integer maths, floating-point maths and branches, so the best hardware for it is a general-purpose CPU. A miner needs about 2,080 MiB of memory in fast mode; a node checking a proof can use a light mode with 256 MiB, slower but giving the same result. Four independent security teams audited the algorithm between May and August 2019 before launch.
The bet is that if any laptop can mine, mining stays spread across many hands. The flip side is that any computer can mine it, including computers whose owners never agreed to it.
Ethash: the proof of work Ethereum retired
Ethereum ran proof of work with an algorithm called Ethash until the Merge, which ethereum.org dates to 15 September 2022 and credits with cutting the network’s energy use by about 99.95 percent. Validators now lock up ether as collateral instead of burning electricity, under proof of stake. Ethereum Classic kept mining with Etchash, a variant, and crypto51.app still lists the EthereumPoW fork under Ethash.
Set side by side, proof of work ties security to an external cost (machines and power) that anyone can check from the chain alone, and lets anyone join by plugging in hardware; proof of stake ties it to capital locked inside the system, uses a sliver of the energy and gives faster finality, at the price of more complex rules and a dependence on who already holds coins. A later lesson on proof of stake in depth and another on the Merge compare them properly.
The energy cost of proof of work, as of November 2026
Work means electricity; the white paper says as much when it compares new coins to gold miners spending resources. The Cambridge Bitcoin Electricity Consumption Index (CBECI), run by the University of Cambridge, displayed on 7 November 2026 a best estimate of about 165 TWh a year for Bitcoin, between a much lower theoretical floor and a much higher ceiling. Two cautions apply. The bounds are far apart because nobody knows exactly which machines are running. And the index’s data, as shown that day, ended in early May 2026, so the figure describes the network as it was then, when hashrate was lower than in November. The debate over whether that energy is waste or a fair price for security belongs to a later lesson on Bitcoin’s energy use.
What regulators say about proof-of-work mining
In the United States, the SEC’s Division of Corporation Finance published a statement on certain proof-of-work mining activities on 20 March 2025. Its view: mining on a proof-of-work network, alone or through a mining pool, does not involve an offer or sale of securities, so participants do not need to register those transactions with the SEC under the Securities Act. The statement says it is a staff view with no legal force or effect, not a rule of the Commission. How mining income is taxed by the IRS, or by HMRC in the UK, is covered in the coming mining guide.
In the European Union, MiCA (Regulation (EU) 2023/1114) requires crypto-asset service providers to publish, in a prominent place on their website, information on the principal adverse impacts on the climate and environment of the consensus mechanism of each crypto-asset they offer (Article 66(5)). Delegated Regulation (EU) 2025/422 makes annual energy consumption, in kilowatt-hours, the mandatory key indicator. A reader holding bitcoin through an EU-licensed platform can find a proof-of-work energy figure in that platform’s sustainability disclosures.
Proof of work in six facts
- A Bitcoin miner hashes the 80-byte block header twice with SHA-256 and wins when the result, read as a number, is at or below the target.
- The 32-bit nonce runs out in microseconds on modern machines, so miners also roll the extranonce, the timestamp and 16 bits of the version field.
- Difficulty stood at about 148.36 T on 7 November 2026, or about 6.37 x 1023 expected hashes per block.
- The target is recomputed every 2,016 blocks, by at most a factor of four; an off-by-one in the code enables the timewarp attack that BIP 54 would close once activated.
- Nodes follow the valid chain with the most accumulated work, not simply the most blocks, which is what makes rewriting history so costly.
- Litecoin and Dogecoin use Scrypt with merge mining, Monero uses CPU-oriented RandomX, and Ethereum left proof of work on 15 September 2022.
Next in this path: the machines, pools and electricity bills behind those 1,000-plus exahashes, in the Bitcoin mining guide. The next difficulty adjustment, at block 975,744, is due around 13 November 2026.
