Block hashing algorithm - Revision history

Junkgoestothisone: Upgraded python code from version 2 to version 3

2021-02-20T17:55:32Z

Upgraded python code from version 2 to version 3

← Older revision		Revision as of 17:55, 20 February 2021
Line 54:		Line 54:
	<source lang="python">		<source lang="python">
	>>> import hashlib		>>> import hashlib
			>>> from binascii import unhexlify, hexlify
	>>> header_hex = ("01000000" +		>>> header_hex = ("01000000" +
	"81cd02ab7e569e8bcd9317e2fe99f2de44d49ab2b8851ba4a308000000000000" +		"81cd02ab7e569e8bcd9317e2fe99f2de44d49ab2b8851ba4a308000000000000" +
Line 60:		Line 61:
	"f2b9441a" +		"f2b9441a" +
	"42a14695")		"42a14695")
	>>> header_bin = header_hex~~.decode('hex'~~)		>>> header_bin = unhexlify(header_hex)
	>>> hash = hashlib.sha256(hashlib.sha256(header_bin).digest()).digest()		>>> hash = hashlib.sha256(hashlib.sha256(header_bin).digest()).digest()
	>>> hash.~~encode~~(~~'hex_codec'~~)		>>> hexlify(hash).decode("utf-8")
	'1dbd981fe6985776b644b173a4d0385ddc1aa2a829688d1e0000000000000000'		'1dbd981fe6985776b644b173a4d0385ddc1aa2a829688d1e0000000000000000'
	>>> hash[::-1].~~encode~~(~~'hex_codec'~~)		>>> hexlify(hash[::-1]).decode("utf-8")
	'00000000000000001e8d6829a8a21adc5d38d0a473b144b6765798e61f98bd1d'		'00000000000000001e8d6829a8a21adc5d38d0a473b144b6765798e61f98bd1d'
	</source>		</source>

Belcher: Add link to block timestamp page

2019-05-13T16:46:35Z

Add link to block timestamp page

← Older revision		Revision as of 16:46, 13 May 2019
Line 27:		Line 27:
	\|-		\|-
	\|Time		\|Time
	\|Current timestamp as seconds since 1970-01-01T00:00 UTC		\|Current [[block timestamp]] as seconds since 1970-01-01T00:00 UTC
	\|Every few seconds		\|Every few seconds
	\|4		\|4

Wargo: Formatting

2015-12-12T16:27:58Z

Formatting

← Older revision		Revision as of 16:27, 12 December 2015
Line 52:		Line 52:

	For example, this python code will calculate the hash of the block with the smallest hash as of June 2011, [http://blockexplorer.com/block/00000000000000001e8d6829a8a21adc5d38d0a473b144b6765798e61f98bd1d Block 125552]. The header is built from the six fields described above, concatenated together as little-endian values in hex notation:		For example, this python code will calculate the hash of the block with the smallest hash as of June 2011, [http://blockexplorer.com/block/00000000000000001e8d6829a8a21adc5d38d0a473b144b6765798e61f98bd1d Block 125552]. The header is built from the six fields described above, concatenated together as little-endian values in hex notation:
			<source lang="python">
			>>> 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'
			</source>

	~~>>> import hashlib~~		==Endianess==
	~~>>> 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 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.		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.

Line 74:		Line 76:

	Here is the same example in plain PHP without any optimization.		Here is the same example in plain PHP without any optimization.
			<source lang="php">
	<?		<?
	//This reverses and then swaps every other char		//This reverses and then swaps every other char
	function SwapOrder($in){		function SwapOrder($in){
	$Split = str_split(strrev($in));		$Split = str_split(strrev($in));
	$x='';		$x='';
	for ($i = 0; $i < count($Split); $i+=2) {		for ($i = 0; $i < count($Split); $i+=2) {
	$x .= $Split[$i+1].$Split[$i];		$x .= $Split[$i+1].$Split[$i];
	}		}
	return $x;		return $x;
	}		}

	//makes the littleEndian		//makes the littleEndian
	function littleEndian($value){		function littleEndian($value){
	return implode (unpack('H',pack("V",$value)));		return implode (unpack('H',pack("V",$value)));
	}		}

	$version = littleEndian(1);		$version = littleEndian(1);
	$prevBlockHash = SwapOrder('00000000000008a3a41b85b8b29ad444def299fee21793cd8b9e567eab02cd81');		$prevBlockHash = SwapOrder('00000000000008a3a41b85b8b29ad444def299fee21793cd8b9e567eab02cd81');
	$rootHash = SwapOrder('2b12fcf1b09288fcaff797d71e950e71ae42b91e8bdb2304758dfcffc2b620e3');		$rootHash = SwapOrder('2b12fcf1b09288fcaff797d71e950e71ae42b91e8bdb2304758dfcffc2b620e3');
	$time = littleEndian(1305998791);		$time = littleEndian(1305998791);
	$bits =littleEndian( 440711666);		$bits = littleEndian(440711666);
	$nonce = littleEndian(2504433986);		$nonce = littleEndian(2504433986);

	//concat it all		//concat it all
	$header_hex = $version . $prevBlockHash . $rootHash . $time . $bits . $nonce;		$header_hex = $version . $prevBlockHash . $rootHash . $time . $bits . $nonce;

	//convert from hex to binary		//convert from hex to binary
	$header_bin = hex2bin($header_hex);		$header_bin = hex2bin($header_hex);
	//hash it then convert from hex to binary		//hash it then convert from hex to binary
	$pass1 = hex2bin( hash('sha256', $header_bin ) );		$pass1 = hex2bin( hash('sha256', $header_bin ) );
	//Hash it for the seconded time		//Hash it for the seconded time
	$pass2 = hash('sha256', $pass1);		$pass2 = hash('sha256', $pass1);
	//fix the order		//fix the order
	$FinalHash = SwapOrder($pass2);		$FinalHash = SwapOrder($pass2);

	echo $FinalHash;		echo $FinalHash;
	?>		?>
			</source>

	[[Category:Technical]]		[[Category:Technical]]

Geremia: clarified paragraph on endianness

2015-06-10T10:15:51Z

clarified paragraph on endianness

← Older revision		Revision as of 10:15, 10 June 2015
Line 67:		Line 67:
	'00000000000000001e8d6829a8a21adc5d38d0a473b144b6765798e61f98bd1d'		'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.		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.
	The output of [http://blockexplorer.com blockexplorer] 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.
			The output of [http://blockexplorer.com blockexplorer] displays the hash values as big-endian numbers; notation for numbers is usual (leading digits are the most significant digits read from left to right).

	For another example, [http://pastebin.com/bW3fQA2a here] is a version in plain C without any optimization, threading or error checking.		For another example, [http://pastebin.com/bW3fQA2a here] is a version in plain C without any optimization, threading or error checking.

Koubiac at 15:41, 3 November 2014

2014-11-03T15:41:38Z

← Older revision		Revision as of 15:41, 3 November 2014
Line 47:		Line 47:
	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.		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.

	~~The nonce parameter (extraNonce field in bitcoin) is designed to prevent different miners accidentally or maliciously generating the same hash. In addition~~ it is extremely unlikely ~~for two people 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.		Moreover, it is extremely unlikely 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.		Bitcoin uses: SHA256(SHA256(Block_Header)) but you have to be careful about byte-order.

Adam3us: refer to hashcash page rather than duplicating a simplified partial explanation inline

2014-11-02T00:07:16Z

refer to hashcash page rather than duplicating a simplified partial explanation inline

← Older revision		Revision as of 00:07, 2 November 2014
Line 1:		Line 1:
	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:		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 stores the nonce 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 small at 32-bits so each time it wraps the extraNonce field must be incremented (or otherwise changed) to avoid repeating work.
			The basics of the hashcash algorithm are quite easy to understand and it is described in more detail [[hashcash\|here]].
			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, as the coinbase transaction is the left most leaf node. The block is also occasionally updated as you are working on it.

			A block header contains these fields:
	{\| class="wikitable"		{\| class="wikitable"
	\|-		\|-
Line 16:		Line 20:
	\|A new block comes in		\|A new block comes in
	\|32		\|32
	\|-		\|-d
	\|hashMerkleRoot		\|hashMerkleRoot
	\|256-bit hash based on all of the transactions in the block		\|256-bit hash based on all of the transactions in the block
Line 43:		Line 47:
	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.		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.		The nonce parameter (extraNonce field in bitcoin) is designed to prevent different miners accidentally or maliciously generating the same hash. In addition it is extremely unlikely for two people 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.		Bitcoin uses: SHA256(SHA256(Block_Header)) but you have to be careful about byte-order.

RomanKnight at 00:07, 12 January 2014

2014-01-12T00:07:36Z

← Older revision		Revision as of 00:07, 12 January 2014
Line 68:		Line 68:
	For another example, [http://pastebin.com/bW3fQA2a here] is a version in plain C without any optimization, threading or error checking.		For another example, [http://pastebin.com/bW3fQA2a here] is a version in plain C without any optimization, threading or error checking.

	Here is same example in plain PHP without any optimization.		Here is the same example in plain PHP without any optimization.

	<?		<?

RomanKnight at 15:20, 11 January 2014

2014-01-11T15:20:17Z

← Older revision		Revision as of 15:20, 11 January 2014
Line 67:		Line 67:

	For another example, [http://pastebin.com/bW3fQA2a here] is a version in plain C without any optimization, threading or error checking.		For another example, [http://pastebin.com/bW3fQA2a here] is a version in plain C without any optimization, threading or error checking.

			Here is same example in plain PHP without any optimization.

			<?
			//This reverses and then swaps every other char
			function SwapOrder($in){
			$Split = str_split(strrev($in));
			$x='';
			for ($i = 0; $i < count($Split); $i+=2) {
			$x .= $Split[$i+1].$Split[$i];
			}
			return $x;
			}

			//makes the littleEndian
			function littleEndian($value){
			return implode (unpack('H',pack("V",$value)));
			}

			$version = littleEndian(1);
			$prevBlockHash = SwapOrder('00000000000008a3a41b85b8b29ad444def299fee21793cd8b9e567eab02cd81');
			$rootHash = SwapOrder('2b12fcf1b09288fcaff797d71e950e71ae42b91e8bdb2304758dfcffc2b620e3');
			$time = littleEndian(1305998791);
			$bits =littleEndian( 440711666);
			$nonce = littleEndian(2504433986);

			//concat it all
			$header_hex = $version . $prevBlockHash . $rootHash . $time . $bits . $nonce;

			//convert from hex to binary
			$header_bin = hex2bin($header_hex);
			//hash it then convert from hex to binary
			$pass1 = hex2bin( hash('sha256', $header_bin ) );
			//Hash it for the seconded time
			$pass2 = hash('sha256', $pass1);
			//fix the order
			$FinalHash = SwapOrder($pass2);

			echo $FinalHash;
			?>


	[[Category:Technical]]		[[Category:Technical]]

XertroV: Updated pastebin contents to compile correctly without warnings.

2013-06-24T10:18:02Z

Updated pastebin contents to compile correctly without warnings.

← Older revision		Revision as of 10:18, 24 June 2013
Line 66:		Line 66:
	The output of [http://blockexplorer.com blockexplorer] 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.		The output of [http://blockexplorer.com blockexplorer] 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/bW3fQA2a here] is a version in plain C without any optimization, threading or error checking.

	[[Category:Technical]]		[[Category:Technical]]

Smtp at 15:14, 16 January 2013

2013-01-16T15:14:11Z

← Older revision		Revision as of 15:14, 16 January 2013
Line 13:		Line 13:
	\|-		\|-
	\|hashPrevBlock		\|hashPrevBlock
	\|~~Hash~~ of the previous block header		\|256-bit hash of the previous block header
	\|A new block comes in		\|A new block comes in
	\|32		\|32