Difference between revisions of "Block hashing algorithm"

Line 1: Line 1:
Bitcoin mining uses the [[hashcash]] proof of work function; the hashcash algorithm requires the following parameters: a service string, a nonce, and a counter.  In bitcoin the service string is encoded in the block header data structure, and includes a version field, the hash of the previous block, the root hash of the merkle tree of all transactions in the block, the current time, and the difficulty.  Bitcoin miners commonly make use of two nonce fields.  One in the block header and a second one in the extraNonce field which is part of the coinbase transaction, which is stored as the left most leaf node in the merkle tree (the coinbase is the special first transaction in the block).  The counter parameter is equivilent to the nonce field in the header, it is relatively small at 32-bits so each time it wraps the extraNonce field must be incremented (or otherwise changed) to avoid repeating work.
+
Bitcoin mining uses the [[hashcash]] proof of work function; the hashcash algorithm requires the following parameters: a service string, a nonce, and a counter.  In Bitcoin the service string is encoded in the block header data structure, and includes a version field, the hash of the previous block, the root hash of the merkle tree of all transactions in the block, the current time, and the difficulty.  Bitcoin miners commonly make use of two nonce fields.  One in the block header and a second one in the extraNonce field which is part of the coinbase transaction, which is stored as the left most leaf node in the merkle tree (the coinbase is the special first transaction in the block).  The counter parameter is equivilent to the nonce field in the header, it is relatively small at 32-bits so each time it wraps the extraNonce field must be incremented (or otherwise changed) to avoid repeating work.
When mining bitcoin, the hashcash algorithm repeatedly hashes the block header while incrementing the counter & extraNonce fields.  Incrementing the extraNonce field entails recomputing the merkle tree root, as the coinbase transaction is changed.
+
When mining Bitcoin, the hashcash algorithm repeatedly hashes the block header while incrementing the counter & extraNonce fields.  Incrementing the extraNonce field entails recomputing the merkle tree root, as the coinbase transaction is changed.
  
 
==Block Header==
 
==Block Header==

Revision as of 10:43, 17 February 2020

Bitcoin mining uses the hashcash proof of work function; the hashcash algorithm requires the following parameters: a service string, a nonce, and a counter. In Bitcoin the service string is encoded in the block header data structure, and includes a version field, the hash of the previous block, the root hash of the merkle tree of all transactions in the block, the current time, and the difficulty. Bitcoin miners commonly make use of two nonce fields. One in the block header and a second one in the extraNonce field which is part of the coinbase transaction, which is stored as the left most leaf node in the merkle tree (the coinbase is the special first transaction in the block). The counter parameter is equivilent to the nonce field in the header, it is relatively small at 32-bits so each time it wraps the extraNonce field must be incremented (or otherwise changed) to avoid repeating work. When mining Bitcoin, the hashcash algorithm repeatedly hashes the block header while incrementing the counter & extraNonce fields. Incrementing the extraNonce field entails recomputing the merkle tree root, as the coinbase transaction is changed.

Block Header

A block header contains these fields:

Field Purpose Updated when... Size (Bytes)
Version Block version number You upgrade the software and it specifies a new version 4
hashPrevBlock 256-bit hash of the previous block header A new block comes in 32
hashMerkleRoot 256-bit hash based on all of the transactions in the block A transaction is accepted 32
Time Current block timestamp as seconds since 1970-01-01T00:00 UTC Every few seconds 4
Bits Current target in compact format The difficulty is adjusted 4
Nonce 32-bit number (starts at 0) A hash is tried (increments) 4

The body of the block contains the transactions. These are hashed only indirectly through the Merkle root. Because transactions aren't hashed directly, hashing a block with 1 transaction takes exactly the same amount of effort as hashing a block with 10,000 transactions.

The format of target is a floating-point encoding using a 3 byte mantissa, the leading byte as exponent (where only the 5 lowest bits are used) and its base is 256.

The Nonce is increased by the mining machine, usually in a strictly linear way, to generate new hash results in an attempt to solve the proof of work for the block. Starting at 0, the field is incremented for each hash attempt. If the Nonce overflows (meaning 2^32 hash attempts have been made), the extraNonce portion of the Coinbase transaction is incremented, which changes the Merkle root and the Nonce value is reset to zero so a further 2^32 attempts can be made.

It is not possible for two nodes to be working on the same Merkle root because the Coinbase transaction is unique to that node, generating a different hash output. Every hash attempt made has the same chance of winning as every other hash calculated across the network.

Endianess

Note that the hash, which is a 256-bit number, has lots of leading zero bytes when stored or printed as a big-endian hexadecimal constant, but it has trailing zero bytes when stored or printed in little-endian. For example, if interpreted as a string and the lowest (or start of) the string address keeps lowest significant byte, it is little-endian.

Most block explorers display the hash values as big-endian numbers; notation for numbers is usual (leading digits are the most significant digits read from left to right).