Mining Target

For illustration only, imagine a limit of 20: results of 19 and 20 would qualify, while 21 would not. Real mining uses much larger numbers, but the relationship is the same: hash ≤ target. The symbol means less than or equal to, not strictly less than. Bitcoin Core is software that network participants use to verify blocks and transactions. The referenced version, v29.0, performs this comparison on the hash of the entire header. The nonce, a value miners vary during the search, is one of the inputs. The resulting hash is what gets compared with the target. [1]

Jana sees a picture of a successful hash starting with a long row of zeroes. This is a useful visual aid: for a fixed-length representation, more leading zeroes mean a smaller number. But two hashes with the same number of leading zeroes can fall on opposite sides of the target. The remaining digits matter too. Zeroes do not replace the full comparison hash ≤ target. The rule is a precise numerical condition, not a contest to produce a pleasing pattern of characters. [1]

A bit stores a zero or a one; eight bits make a byte. Instead of storing the entire long number in the header, Bitcoin uses the 32-bit nBits field. It encodes a target in the space of 256-bit numbers, using a coefficient, an exponent determining the shift and a sign bit. For example, 0x04123456 decodes to 0x12345600; the 0x prefix denotes hexadecimal notation, which also uses letters. This illustrates the encoding, not today’s network target. For a basic understanding, distinguish the number itself from its compact representation. [3] [5]

When reading raw data, the same number may seem reversed. In the 80-byte header, nBits occupies four bytes stored as little-endian: the least significant byte comes first. The numerical value 0x1d00ffff therefore appears in the data as ff ff 00 1d. Byte order does not change the target; it describes storage. This detail matters when working with raw data. Ordinary readers of a block explorer do not need to reverse the numbers on screen. [2]

Jana might suggest storing a larger number to make the search easier. But software checks more than whether it can read nBits. DeriveTarget in Bitcoin Core v29.0 rejects a negative target, zero, overflow beyond the numerical range and values above powLimit, the highest permitted target for that network. Successful decoding therefore only establishes which number the encoding represents; it does not itself grant permission to use it. [1]

Even a target within the permitted range may be wrong for a particular block. Bitcoin Core compares nBits with GetNextWorkRequired, a calculation based on the previous block and the network rules. A mismatch produces bad-diffbits. A low hash under a miner’s own easier target does not excuse the wrong header value. Jana cannot obtain an accepted block merely by lowering the requirement: other nodes, the computers that enforce the rules, reject that attempt. [4]

In a model with uniformly distributed 256-bit hashes, every possible result has the same probability. For an allowed target T, the accepted values run from zero through T inclusive. That gives p = (T + 1) / 2^256 for one attempt, where p is the probability of success. The added one includes zero. This relationship explains why a lower target makes the search harder. It does not say how many attempts a machine performs per second or exactly when the next block will arrive. [1]

When Jana meets the condition, she has demonstrated the required computational work, not the correctness of everything inside the block. Bitcoin Core also checks the combined transaction fingerprint, the special reward transaction called coinbase, block limits and transaction validity. Here coinbase is the technical name for the first transaction in a block, not the exchange. A low hash cannot repair invalid contents. The target is an important part of the rules, not permission to bypass the rest. [4]