blockchain – How does fixing a block work in relation to the primary letter/quantity after the 0’s?

The comparability used is numeric

These are numbers not strings of characters. You’ll be able to see this by trying on the code within the 2009 most important.cpp of the Bitcoin reference implementation:

        uint256 hashTarget = CBigNum().SetCompact(pblock->nBits).getuint256();
        uint256 hash;

[...]

           if (hash <= hashTarget)
            {
                pblock->nNonce = tmp.block.nNonce;
                assert(hash == pblock->GetHash());

                    //// debug print
                    printf("BitcoinMiner:n");
                    printf("proof-of-work discovered  n  hash: %s  ntarget: %sn", hash.GetHex().c_str(), hashTarget.GetHex().c_str());

Observe that if (hash <= hashTarget) is a numeric comparability. Each hash and hashTarget are kind uint256 – an unsigned integer.

Numbers expressed in hexadecimal are nonetheless numbers

There’s a selection of visible representations however the selection made doesn’t change the underlying nature of the quantity or the way in which by which numbers are in contrast arithmetically or at a machine stage in a pc.

Your instance, 00005fad, is a quantity expressed in hexadecimal (base 16), the identical quantity could be written in regular decimal (base 10) as 24493. Anybody unfamiliar with non-decimal representations reminiscent of hexadecimal, octal and binary can test this utilizing one thing just like the Home windows 10 calculator, within the menu select “Programmer Mode” then click on on “hex” and enter 5fad – it reveals the identical worth in a number of completely different representations.

Possibly it will make it clearer?

Regardless that the block hashes have the identical variety of main zeroes, one is a failure and the opposite a hit.

Main zeroes

The notion that Bitcoin cares in regards to the variety of main zeroes in, say, a hexadecimal illustration, is a generally repeated mistake (do not ask me how I do know this).

In the event you insist on writing numbers with main zeroes it’s nonetheless clearly true that 000015 (fifteen) with 4 main zeroes is smaller than 000150 (100 and fifty) with solely three main zeroes. It could nevertheless be a mistake to assume that smaller numbers at all times have extra main zeroes. Each you and Bitcoin know that 000017 (seventeen) is smaller than 000019 (nineteen) regardless that each have the identical variety of main zeroes.

It’s true that a is lower than b in precisely the identical method that 7 is lower than 8 or that 2 is lower than 3. However it’s in all probability a mistake to start out evaluating particular person digits in a selected visible illustration. The hash and hash targets are abnormal numbers (although giant) which can be in contrast in an abnormal method.

So the place does this speak of main zeroes come from? In accordance with a outstanding contributor:

hashcash, the unique PoW system, had a “issue” that was really the variety of zero bits up entrance within the hash. Bitcoin’s proof of labor is predicated on it, however generalized to a giant integer comparability.

See

Examples

Lets take a look at some current blocks (most up-to-date at prime, reverse chronological order)

Discover that the problem elevated after block 669311 however the variety of main zeroes within the hashes has not elevated (not in hexadecimal and never in binary).

Implementations

If you wish to see actual particulars you could possibly take a look at early variations of the Bitcoin reference implementation in C++. Nevertheless I might recommend as an alternative trying on the present BTCD implementation in go-lang as a result of that’s effectively commented and, for my part, a better language to learn.

e.g. https://github.com/btcsuite/btcd/blob/grasp/chaincfg/params.go

    // TargetTimespan is the specified period of time that ought to elapse
    // earlier than the block issue requirement is examined to find out how
    // it ought to be modified in an effort to keep the specified block
    // era fee.
    TargetTimespan time.Period

    // TargetTimePerBlock is the specified period of time to generate every
    // block.
    TargetTimePerBlock time.Period

and https://github.com/btcsuite/btcd/blob/grasp/blockchain/issue.go

    // Calculate new goal issue as:
    //  currentDifficulty * (adjustedTimespan / targetTimespan)
    // The end result makes use of integer division which suggests will probably be barely
    // rounded down.  Bitcoind additionally makes use of integer division to calculate this
    // end result.
    oldTarget := CompactToBig(lastNode.bits)
    newTarget := new(huge.Int).Mul(oldTarget, huge.NewInt(adjustedTimespan))
    targetTimeSpan := int64(b.chainParams.TargetTimespan / time.Second)
    newTarget.Div(newTarget, huge.NewInt(targetTimeSpan))

Calculating the hash goal

See