Bitcoin Difficulty Explained

Difficulty is the knob that keeps block times near ten minutes while global hashrate moves constantly. It recomputes every 2016 blocks, which makes it a variable in your return calculations, never a constant.

Target, nBits, difficulty

A block is valid if the double SHA-256 of its header is below a target. That target rides in the header in compact form, in the nBits field.

Difficulty is the human way to talk about that target. Higher difficulty means a smaller target, so a random hash is less likely to pass. It is defined against a historical reference target, the protocol maximum. An operator does not hand-compute this: nodes and pools do it.

Difficulty and target therefore say the same thing, inverted. Firmware sometimes shows both. The pool mostly gives you a share difficulty, much lower, which meters your work between blocks.

Retarget every 2016 blocks

Every 2016 blocks, the network compares the time actually elapsed over that window against the intended span, 2016 times ten minutes.

• If blocks came in too fast, hashrate probably rose, and difficulty goes up.
• If they came in too slow, it goes down.

The move is capped: the protocol does not multiply or divide without limit in a single step. Between retargets, network difficulty stays constant. At nominal pace, 2016 blocks is about two weeks; a hashrate ramp shortens that window, a slowdown stretches it.

The practical consequence: on the day you read a difficulty value, the next retarget may already have landed. Any projection must carry the date of the difficulty it used.

Hashrate, block time, and what that means

Mean time between blocks depends on total hashrate and the target, hence on difficulty. The protocol aims at ten minutes. If machines come online and difficulty has not moved yet, blocks rush until the next retarget, after which the pace returns toward ten minutes at a higher difficulty.

For a solo miner, expected block finds are:

your hashrate divided by network hashrate, times one block roughly every ten minutes.

You do not control the denominator. You control the numerator, meaning rigs that stay powered and stable, along with your losses: rejected shares, downtime, heat.

Shares, pools, and revenue

In a pool you are not waiting to win a block yourself. You submit shares under a pool difficulty, and when the pool finds a block it splits by its own rules, PPS, FPPS, PPLNS, or another.

Four effects worth separating:

• Network difficulty rises. Your share rate at a fixed pool difficulty does not change, since the machine hashes the same. What changes is the value of that work against the global puzzle, so the expected BTC per TH per day once pool rules and fees apply.
• Your hashrate rises. You produce more valid shares, so your cut grows.
• Everyone else's hashrate rises. After a retarget, difficulty follows. Same machine, same power draw, less expected BTC.
• The block reward changes. Subsidy and fees form a separate lever, which difficulty does not set.

What an operator actually does

1. Watch the observed block time and the date of the last retarget, rather than a single number copied from site to site.
2. Compare pool hashrate against local hashrate. A lasting gap comes from share loss or a bad job, never from difficulty.
3. Size power and cooling on real watts, without counting on a difficulty drop.
4. Identify the marginal machines, the ones with poor J/TH or an expensive rate. Those go underwater first when difficulty rises, and it is better to know which ones before it happens.

Three calculation traps

• Mixing up network difficulty and share difficulty. The latter is a meter internal to the pool and has no influence on your revenue.
• Believing that switching off a few machines lowers difficulty. At small-fleet scale, your weight in the retarget is negligible.
• Leaving a six-month-old difficulty in a spreadsheet that is still open. That is the error that distorts the most financing plans, because nothing flags it.