1) My explanation wasn't clear at all on this point. Let me try again.
First, the target. I'll keep the same block example. In the left column, you have a bits field, with the value 402690497. This is the target bits. This number expresses the Proof-of-Work target as a coefficient/exponent format.
If we convert this number in hexadecimal, we get this: 0x180091C1.
The first two hexadecimals digits ( 18 ) are the exponent, the next six ( 0091C1 ) are the coefficient. Here is the formula used to calculate the target from this:
target = coefficient * 28 * (exponent - 3)
So by using the hexadecimal value above, we can calculate the target:
This means that compared to the first block every mined ( where the difficulty was 1 ), this block was 1.9 trillion times more difficult to solve. I may have skipped the decimals in this, but I hope you get the idea.
2) Well, I suppose the Bitcoin core developers are responsible for this. You can find the code used for the calculation here. They take the last 14 days worth of blocks and adjust the difficulty based on their findings.
3) Well, not every miner is using the same informations. I may not have explained this very well. Once a block is mined, everyone has access to the same informations and can make sure that the data is valid.
But, they won't be mining the block using the same informations. First, the merkle root will be different for everyone. The first transaction in the block ( coinbase transaction) sends bitcoins to the miner personal wallet. Each wallet address will be different, therefore the merkle root will be different too. It is also very unlikely that they will use the same timestamp for the block. So Joe finds the proper nonce at 2469953656 with its data, but other miners may not have a valid hash with this nonce because their timestamp and/or their merkle root was different.
As for the randomness of the nonces, I want to say you are right. Although I'm not quite sure how to prove it. Mining is absolutely a lottery.
If we have 2 dices, and the target is 2 ( the lowest possible ), we have only one throw possible to reach the target ( 1 on each dice ). This would mean that 1 throw out of 36 possible solves the problem, which is 2%. So, if I manage to hit the target with my dices, it doesn't mean I've thrown the dices 36 times, but the probability should be enough to prove that I've put the effort.
I'm not sure if that last paragraph has a lot to do with what you mean :D. I was just freelancing.
Sorry for the long answer. Let me know if anything isn't clear enough.
1) Amazing. This sent me on another rabbit hole to learn more about hexadecimals but was very educational.
3) Okay, I had gotten a bit confused about how the list of transactions was generated in a miner's candidate block. I now understand that they're drawn from the transaction pool and added to the candidate block at the miner's discretion. The specific transactions drawn, the order they're in, and the initial coinbase transaction will ensure the merkle tree is different for everyone. Additionally, as you point out, the timestamp would also be different.
The concept of fees and reward is really interesting. This is a block with zero transactions where the miner simply went after the reward.
I've held a fascination about blockchains for a while, but have found it really un-approachable and confusing. Your articles and explanations have been awesome. Thanks for the reply to my questions!
1) My explanation wasn't clear at all on this point. Let me try again.
First, the target. I'll keep the same block example. In the left column, you have a bits field, with the value 402690497. This is the target bits. This number expresses the Proof-of-Work target as a coefficient/exponent format.
If we convert this number in hexadecimal, we get this: 0x180091C1.
The first two hexadecimals digits ( 18 ) are the exponent, the next six ( 0091C1 ) are the coefficient. Here is the formula used to calculate the target from this:
So by using the hexadecimal value above, we can calculate the target:
Which in decimal is =>
Back to hexadecimal (and a 64 length string) is =>
This represents the higher limit the hash must have. If the hash is lower than this target, it is valid ( here => 18 leading zeros ).
As for the difficulty, we divide the highest difficulty possible by the target found:
00000000FFFF00000000000000000000 /
00000000000000000091C100000013DE
= 1C1A0B3CF57
Which in decimals => 1,931,136,454,487
This means that compared to the first block every mined ( where the difficulty was 1 ), this block was 1.9 trillion times more difficult to solve. I may have skipped the decimals in this, but I hope you get the idea.
2) Well, I suppose the Bitcoin core developers are responsible for this. You can find the code used for the calculation here. They take the last 14 days worth of blocks and adjust the difficulty based on their findings.
3) Well, not every miner is using the same informations. I may not have explained this very well. Once a block is mined, everyone has access to the same informations and can make sure that the data is valid.
But, they won't be mining the block using the same informations. First, the merkle root will be different for everyone. The first transaction in the block ( coinbase transaction) sends bitcoins to the miner personal wallet. Each wallet address will be different, therefore the merkle root will be different too. It is also very unlikely that they will use the same timestamp for the block. So Joe finds the proper nonce at 2469953656 with its data, but other miners may not have a valid hash with this nonce because their timestamp and/or their merkle root was different.
As for the randomness of the nonces, I want to say you are right. Although I'm not quite sure how to prove it. Mining is absolutely a lottery.
If we have 2 dices, and the target is 2 ( the lowest possible ), we have only one throw possible to reach the target ( 1 on each dice ). This would mean that 1 throw out of 36 possible solves the problem, which is 2%. So, if I manage to hit the target with my dices, it doesn't mean I've thrown the dices 36 times, but the probability should be enough to prove that I've put the effort.
I'm not sure if that last paragraph has a lot to do with what you mean :D. I was just freelancing.
Sorry for the long answer. Let me know if anything isn't clear enough.
1) Amazing. This sent me on another rabbit hole to learn more about hexadecimals but was very educational.
3) Okay, I had gotten a bit confused about how the list of transactions was generated in a miner's candidate block. I now understand that they're drawn from the transaction pool and added to the candidate block at the miner's discretion. The specific transactions drawn, the order they're in, and the initial coinbase transaction will ensure the merkle tree is different for everyone. Additionally, as you point out, the timestamp would also be different.
The concept of fees and reward is really interesting. This is a block with zero transactions where the miner simply went after the reward.
I've held a fascination about blockchains for a while, but have found it really un-approachable and confusing. Your articles and explanations have been awesome. Thanks for the reply to my questions!
Happy to help :) These questions force me to learn on a more deeper level. Always welcomed.