Difference between revisions of "Block hashing algorithm"

From Bitcoin Wiki
Jump to: navigation, search
(256 bits)
(a little remember about endianess and typical interpretation (number/string))
Line 62: Line 62:
 
   '00000000000000001e8d6829a8a21adc5d38d0a473b144b6765798e61f98bd1d'
 
   '00000000000000001e8d6829a8a21adc5d38d0a473b144b6765798e61f98bd1d'
  
Note that the actual hash has lots of trailing zero bits when interpreted (by default) as a 256-bit big-endian number (in keeping with the big-endian constants in the definition of SHA-256. But when interpreted as bitcoin does as a little-endian number, the hash has lots of leading zero bits, and this is what shows up e.g. in the output of blockexplorer.
+
Note that the actual hash, which is a 256-bit number, has lots of leading zero bits. When stored or printed as a big-endian hexadecimal constant, but it has leading zero bytes and if stored or printed as little-endian, these are the trailing zero bytes. E.g. if interpretation as a string -- lowest (or start of) string address keeps lowest significant byte, thus little-endian.
 +
The output of [http://blockexplorer.com] displays the hash values as big-endians numbers as notation for numbers is usual -- leading digits are the most significant digits read from left to right.
  
 
For another example, [http://pastebin.com/n8UEGA86 here] is a version in plain C without any optimization, threading or error checking.
 
For another example, [http://pastebin.com/n8UEGA86 here] is a version in plain C without any optimization, threading or error checking.
  
 
[[Category:Technical]]
 
[[Category:Technical]]

Revision as of 14:59, 16 January 2013

When generating, you constantly hash the block header. The block is also occasionally updated as you are working on it. 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
Previous hash Hash of the previous block A new block comes in 32
Merkle root 256-bit hash based on all of the transactions A transaction is accepted 32
Timestamp Current timestamp 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.

Most of these fields will be the same for all users. There might be some minor variation in the timestamps. The nonce will usually be different, but it increases in a strictly linear way. "Nonce" starts at 0 and is incremented for each hash. Whenever Nonce overflows (which it does frequently), the extraNonce portion of the generation transaction is incremented, which changes the Merkle root.

Given just those fields, people would frequently generate the exact same sequence of hashes as each other and the fastest CPU would almost always win. However, it is (nearly) impossible for two people to have the same Merkle root because the first transaction in your block is a generation "sent" to one of your unique Bitcoin addresses. Since your block is different from everyone else's blocks, you are (nearly) guaranteed to produce different hashes. Every hash you calculate has the same chance of winning as every other hash calculated by the network.

Bitcoin uses: SHA256(SHA256(Block_Header)) but you have to be careful about byte-order.

For example, this python code will calculate the hash of the block with the smallest hash as of June 2011, Block 125552. The header is built from the six fields described above, concatenated together as little-endian values in hex notation:

  >>> import hashlib
  >>> header_hex = ("01000000" +
    "81cd02ab7e569e8bcd9317e2fe99f2de44d49ab2b8851ba4a308000000000000" +
    "e320b6c2fffc8d750423db8b1eb942ae710e951ed797f7affc8892b0f1fc122b" +
    "c7f5d74d" +
    "f2b9441a" +
     "42a14695")
  >>> header_bin = header_hex.decode('hex')
  >>> hash = hashlib.sha256(hashlib.sha256(header_bin).digest()).digest()
  >>> hash.encode('hex_codec')
  '1dbd981fe6985776b644b173a4d0385ddc1aa2a829688d1e0000000000000000'
  >>> hash[::-1].encode('hex_codec')
  '00000000000000001e8d6829a8a21adc5d38d0a473b144b6765798e61f98bd1d'

Note that the actual hash, which is a 256-bit number, has lots of leading zero bits. When stored or printed as a big-endian hexadecimal constant, but it has leading zero bytes and if stored or printed as little-endian, these are the trailing zero bytes. E.g. if interpretation as a string -- lowest (or start of) string address keeps lowest significant byte, thus little-endian. The output of [1] displays the hash values as big-endians numbers as notation for numbers is usual -- leading digits are the most significant digits read from left to right.

For another example, here is a version in plain C without any optimization, threading or error checking.