insane number of solution to 2022 bitcoin blocks.10^71 possibilities?

[supermankid]

Even though mining is intensely difficult, the number of possible in today's term Stull looks like quite a large number.
Based on different arrangements of nonce, headers, txns, it looks like quite a large number of solutions can satisfy solution requirement s. Does the math below make sense? (Which shows quite high number of possible aolutions)

2022 blocks (19 zeroes)
solution => 00000000000000000001b3b857465688e53f3fafc11d50a794690f7bae2f7ff6
No of bits in solution => 256
No of zeroes in solution=> 19
Other Possible solution => 2^ (256-19) => 2^237=> 2.2*10^71

[odolvlobo]

Even though mining is intensely difficult, the number of possible in today's term Stull looks like quite a large number.
Based on different arrangements of nonce, headers, txns, it looks like quite a large number of solutions can satisfy solution requirement s. Does the math below make sense? (Which shows quite high number of possible aolutions)

2022 blocks (19 zeroes)
solution => 00000000000000000001b3b857465688e53f3fafc11d50a794690f7bae2f7ff6
No of bits in solution => 256
No of zeroes in solution=> 19
Other Possible solution => 2^ (256-19) => 2^237=> 2.2*10^71

First of all, Bitcoin does not count the number of 0 bits as many people seem to think. That technique was mentioned in the white paper, but Bitcoin was never implemented like that. The actual problem is to find a hash (treated as a number) that is less than or equal to the target value.

The current target is 955,133,703,543,227,653,230,735,945,040,239,725,552,721,938,878,562,304 (9f8d90000000000000000000000000000000000000000 hex). Any number less than or equal to that is a solution, so there are 955,133,703,543,227,653,230,735,945,040,239,725,552,721,938,878,562,305 possible solutions (0 is a solution).

Note, you are also confusing binary 0 with hexadecimal 0. Your answer should have been, 16^(64-19) = 16⁴⁵ = 1.5x10⁵⁴, which is not too far from the actual answer of 0.955x10⁵⁴.

[supermankid]

Even though mining is intensely difficult, the number of possible in today's term Stull looks like quite a large number.
Based on different arrangements of nonce, headers, txns, it looks like quite a large number of solutions can satisfy solution requirement s. Does the math below make sense? (Which shows quite high number of possible aolutions)

2022 blocks (19 zeroes)
solution => 00000000000000000001b3b857465688e53f3fafc11d50a794690f7bae2f7ff6
No of bits in solution => 256
No of zeroes in solution=> 19
Other Possible solution => 2^ (256-19) => 2^237=> 2.2*10^71

First of all, Bitcoin does not count the number of 0 bits as many people seem to think. That technique was mentioned in the white paper, but Bitcoin was never implemented like that. The actual problem is to find a hash (treated as a number) that is less than or equal to the target value.

The current target is 955,133,703,543,227,653,230,735,945,040,239,725,552,721,938,878,562,304 (9f8d90000000000000000000000000000000000000000 hex). Any number less than or equal to that is a solution, so there are 955,133,703,543,227,653,230,735,945,040,239,725,552,721,938,878,562,305 possible solutions (0 is a solution).

Note, you are also confusing binary 0 with hexadecimal 0. Your answer should have been, 16^(64-19) = 16⁴⁵ = 1.5x10⁵⁴, which is not too far from the actual answer of 0.955x10⁵⁴.

Hello odolvlobo,

Thanks for clearing this up. I have a small question though. How is this target number derived?(9f8d90000000000000000000000000000000000000000 and this has 41 zeros)

Normally the block explorer still shows the hash of the previous block starting with 19 0s'.

and yes thanks for the correction,
number of zeros => 19(hex) => 19*4(bits) => 76
possible solution => 2^(256-76) => 2^180 => 1.5*10^54 which comes exactly to your solution but in a different way.

So, I guess the number of required zeros of the current block to have certain amount of zeroes still seems to be valid. No?

[odolvlobo]

Even though mining is intensely difficult, the number of possible in today's term Stull looks like quite a large number.
Based on different arrangements of nonce, headers, txns, it looks like quite a large number of solutions can satisfy solution requirement s. Does the math below make sense? (Which shows quite high number of possible aolutions)

2022 blocks (19 zeroes)
solution => 00000000000000000001b3b857465688e53f3fafc11d50a794690f7bae2f7ff6
No of bits in solution => 256
No of zeroes in solution=> 19
Other Possible solution => 2^ (256-19) => 2^237=> 2.2*10^71

First of all, Bitcoin does not count the number of 0 bits as many people seem to think. That technique was mentioned in the white paper, but Bitcoin was never implemented like that. The actual problem is to find a hash (treated as a number) that is less than or equal to the target value.

The current target is 955,133,703,543,227,653,230,735,945,040,239,725,552,721,938,878,562,304 (9f8d90000000000000000000000000000000000000000 hex). Any number less than or equal to that is a solution, so there are 955,133,703,543,227,653,230,735,945,040,239,725,552,721,938,878,562,305 possible solutions (0 is a solution).

Note, you are also confusing binary 0 with hexadecimal 0. Your answer should have been, 16^(64-19) = 16⁴⁵ = 1.5x10⁵⁴, which is not too far from the actual answer of 0.955x10⁵⁴.

Thanks for clearing this up. I have a small question though. How is this target number derived?(9f8d90000000000000000000000000000000000000000 and this has 41 zeros)
Normally the block explorer still shows the hash of the previous block starting with 19 0s'.

and yes thanks for the correction,
number of zeros => 19(hex) => 19*4(bits) => 76
possible solution => 2^(256-76) => 2^180 => 1.5*10^54 which comes exactly to your solution but in a different way.

So, I guess the number of required zeros of the current block to have certain amount of zeroes still seems to be valid. No?

Again, the number of zeros is irrelevant. Counting zeros happens to give similar results, but it is not how it actually works.

The block's hash is 256 bits or 64 hexadecimal digits, so you will see all of the digits when showing the hash. However, the target is a number and I generally don't show preceding zeros when writing a number because there are an infinite number of them.

The target is computed by taking the previous target and multiplying it by a factor determined by comparing the time it took to mine the previous 2015 blocks to the time it was supposed to take the last 2016 blocks (1209600 seconds). For example, if the total hash rate has increased and it took only 1100000 seconds to mine the last 2015 blocks, then the new target is the previous target multiplied by 1100000/1209600 = 0.91. Note that target is stored as a floating point number with a precision of about 24 bits.

Also, the time for the previous 2015 blocks is used instead of 2016 blocks due to a bug that will probably never be fixed. The result is that the nominal block time is actually 10.005 minutes.

[supermankid]

🙏Thanks a lot. I got more digging to do.