A candidate block comes first
Mining software selects valid transactions, constructs a coinbase transaction and calculates a Merkle root from transaction identifiers. Together with the previous block hash, time, target and nonce, these data form a header. ASIC devices then test its variants at high speed by calculating double-SHA-256 hashes.
A miner can change transaction selection and order, coinbase data and the nonce, opening more possible headers. When a hash below the network target is found, the full block is sent to nodes. They do not count the failed attempts; they verify the successful header, the transactions and the other block rules.
Ten minutes is a statistical average
Every hashing attempt has a tiny probability of success. Even a powerful miner cannot know which particular attempt will work. Two blocks may therefore arrive close together, while at another time the network may wait much longer. No protocol clock commands miners to publish a block at minute ten.
A larger share of total hash rate gives a miner a greater probability of finding the next block, not certainty. Over a long period, results tend toward the share of work, but short runs can vary widely. This is why individual miners join pools and exchange rare large payouts for more frequent smaller shares.
- the exact time of the next block cannot be scheduled
- ten minutes is the mainnet target for the average frequency
- a mining pool reduces payout variance but can concentrate block-template selection
Difficulty responds every 2,016 blocks
If more computing power joins, blocks would arrive faster under an unchanged target; if power leaves, they would arrive more slowly. After every 2,016-block period on mainnet, Bitcoin Core compares the period's actual duration with a target of roughly two weeks and changes the target for the next period.
A faster period leads to a lower target and therefore higher difficulty; a slower period leads to a higher target. A single adjustment is limited to a fourfold target change. The mechanism does not respond to price or transaction count, and mainnet does not retarget after every individual block.
A stable pace is not perfect stability
After a sharp fall in hash rate, blocks may remain slower until the next adjustment; after a sharp rise, faster. Retargeting does not alter intervals that already occurred, and randomness remains afterwards. It provides only a long-term feedback loop between computing power and required difficulty.
Difficulty is not a direct count of miners or owners either. The same hash rate could be divided among many devices or coordinated by a handful of pools. An assessment of decentralization must distinguish hardware owners, block-building pools, node operators and equipment manufacturers.