When we look at this block – what does the first number
Hash: 0xfe88c94d860f01a17f961bf4bdfb6e0c6cd10d3fda5cc861e805ca1240c58553
actually mean? How is it calculated?
"Nonce" is the value that is changed during mining, but what is hash?
[Ethereum] a block hash
block-headerblockchainethashhashhash-algorithm
Related Solutions
In the Ethereum blockchain, the difficulty is used to calculate a target.
Here are the ethminer logs for block number 1257006 :
ℹ 35:02:42.89 ethminer Solution found; Submitting to http://192.168.4.120:8545 ...
ℹ 35:02:42.89 ethminer Nonce: ff4136b6b6a244ec
ℹ 35:02:42.89 ethminer Mixhash: 47da5e47804594550791c24331163c1f1fde5bc622170e83515843b2b13dbe14
ℹ 35:02:42.89 ethminer Header-hash: f5afa3074287b2b33e975468ae613e023e478112530bc19d4187693c13943445
ℹ 35:02:42.89 ethminer Seedhash: 1730dd810f27fdefcac730fcab75814b7286002ecf541af5cdf7875440203215
ℹ 35:02:42.89 ethminer Target: 00000000000baef6895d630131521d65d984555906990f43f352be4350291f92
ℹ 35:02:42.89 ethminer Ethash: 0000000000095d18875acd4a2c2a5ff476c9acf283b4975d7af8d6c33d119c74
ℹ 35:02:42.89 ethminer B-) Submitted and accepted.
Here is a snippet of Java to compute the difficulty from the target :
import java.math.BigInteger;
public class DifficultyDemo {
public static void main(String[] args) {
BigInteger numTwoPow256 = new BigInteger("2").pow(256);
BigInteger target = new BigInteger("00000000000baef6895d630131521d65d984555906990f43f352be4350291f92", 16);
BigInteger difficulty = numTwoPow256.divide(target);
System.out.println(difficulty.toString());
}
}
And the difficulty is calculated as 24091770185844 which corresponds to the difficulty in the blockchain explorer screen.
We can use ethminer --check-pow <headerHash> <seedHash> <difficulty> <nonce> to check the proof-of-work for validity as follows:
beefee@Rasterbator:~$ ethminer --check-pow f5afa3074287b2b33e975468ae613e023e478112530bc19d4187693c13943445 1730dd810f27fdefcac730fcab75814b7286002ecf541af5cdf7875440203215 24091770185844 ff4136b6b6a244ec
VALID :-)
0000000000095d18875acd4a2c2a5ff476c9acf283b4975d7af8d6c33d119c74 < 00000000000baef6895d630131521d65d984555906990f43f352be4350291f93
where 00000000000baef6895d630131521d65d984555906990f43f352be4350291f93 = 2^256 / 24091770185844
and 0000000000095d18875acd4a2c2a5ff476c9acf283b4975d7af8d6c33d119c74 = ethash(f5afa3074287b2b33e975468ae613e023e478112530bc19d4187693c13943445, ff4136b6b6a244ec)
with seed as 1730dd810f27fdefcac730fcab75814b7286002ecf541af5cdf7875440203215
(mixHash = 47da5e47804594550791c24331163c1f1fde5bc622170e83515843b2b13dbe14)
SHA3( light(seed) ) = 35ded12eecf2ce2e8da2e15c06d463aae9b84cb2530a00b932e4bbc484cde353
The miner's GPU would iterate through a range of random Nonces. This Nonce, combined with the Seedhash and Header-hash using a hash function need to calculate a number below the Target. If this calculated number is below the target, the miner has successfully mined a block and the block details will be submitted to the Ethereum network nodes.
In the example above, the calculated hash Ethash is larger than the Target and is therefore an incorrectly mined block (which is mentioned in the bug report).
In Bitcoin, the target is the block hash. As difficulty rises, you will see the number of leading zeroes increase.
Block 405390 has 17 leading zeroes. Block 40539 has 8 leading zeroes (mined in 2010).
The Ethereum Target is sort of equivalent to the Bitcoin block hash.
Question 2: Why the number of blocks keeps increasing in a private chain even though no transaction is being sent to the chain?
If you carefully look at how a blockchain works, this is something important to assure the integrity of the blockchin data. Normally a blockchain protocol works in a way to keep the block rate constant, in order to make it difficult to create a another chain which is longer. In ethereum a block is generated nearly every 14 seconds, and the difficulty is what keeps the average blockrate at that rate. You may refer this answer.
So whether there are transactions or not, miner s keep mining blocks and that's how the protocol is defined for a public network and since you are using the same protocol in your private chain (default geth client), In your private chain also its the same. The code @StevenJaxon had linked can be used to alter your private chain but then it would not be simulating the public chain anyhow for testing purposes that won't matter and it will save your computing power as well.
Question 1: How to get the hash value head/current block in a private chain?
This pretty straight forward if you refer the web3 API reference here and here,
web3.eth.blockNumber // return current block number
web3.eth.getBlock(blockHashOrBlockNumber [, returnTransactionObjects] [, callback]) // returns a block given the hash or number
//combine both
currentBlock = web3.eth.blockNumber;
web3.eth.getBlock(currentBlock, function(block){
//do whatever with the block details
});
If what you want to do this inside a smart contract, you only be able to get the previous block number, and you can use the following code, refer this question.
contract Test {
uint public blockNumber;
bytes32 public blockHashNow;
bytes32 public blockHashPrevious;
function setValues() {
blockNumber = block.number;
blockHashNow = block.blockhash(blockNumber);
blockHashPrevious = block.blockhash(blockNumber - 1);
}
}
Best Answer
The block header is the hash returned from generating a Merkle tree that is below the current difficulty target for the blocks data.
What's a hash?
In order to understand what the block header is you need to understand what a hashing function is. A hashing function is a one way(non invertible function) that maps a set of inputs to a set of outputs hash(s) -> p, where for our purposes s and p are both strings. For any string s we can find the hash by applying our hashing function, which will return a new string. This is a deterministic procedure in that given an s, the same hash() will produce the same p. There is no inverse of the hash operation, so you cannot go from output to input hash^-1(p) -> s. A hash function will ideally map the domain uniformly over the range such that any input that is in the domain will have a pretty even probability of being anywhere in the range vs more likely to be in a certain section.
You use hashing operations for many different applications from data storage and lookup to logging into any password protected environments. It is also used to verify the integrity of data. Lets say you have a large file F. You can take the hash of the file by converting it to a string and then taking the hash of it, hash(F) -> G. G will be a string representation of (in this case) a 5 digit hexadecimal number(hashes like sha give you 40 digit hex numbers), lets say 0x5a3b1. Now some interesting properties can be examined. First is data integrity, if you wanted to download a copy of the file, you would need a verified copy already to compare with to ensure that it was the same one and not tampered with to go through and make sure every byte is the same. With a hash we can do this much more easily. Since the hash of the original file always maps to the same G with the same hash function, the recipient can just take the hash of the file and compare it with a published hash of the file and see that they match. Changing even a single bit would change the value returned by the hash function.
So what's a merkle tree?
Blah blah, that's boring, what does any of this have to do with ethereum and blockchains? Well, the data in the blockchain can be "stored" by storing the hashes of data, such that you can at least verify that that's the datum whose hash was stored if you have the datum to hash yourself and check against the one in the blockchain. A Merkle tree is one way of doing this.
So to construct a Merkle tree you make a tree data structure with each of the leaf nodes containing the hash of a section of the data to be stored. From there you take the hash of the concatenation of the child nodes, and propagate the value up to the parent, continuing this process up the tree until a final hash is generated. A blocks header is the top hash of applying the Merkle procedure to a the data contained in the block. Thus even if a block has a large number of transactions all that is stored is the root hash of the Merkle tree.
Any changes to the source will be apparent if the same merkle procedure is applied to both files, small changes at the leaves propagate upwards and change the resultant hash.
An interesting lemma is that as a "storage" mechanism, hashes are "lossy" such that starting with a 2000 character file, and eventually getting a 40 digit hex number; The original encoding of 2000 characters with 78 possible characters(making bounds on this approximation) has 9.582e+3772 possible files that could be represented, while the hashing function can only map that range to 1.106e+47 outputs in the domain. That's still a large domain, so hash collisions (when two inputs map to the same output) would be extremely rare.