Topic: For fun: the lowest block hash yet - page 4. (Read 21206 times)
The Block 2162 hash 00000000aaf0ab905dcdd85a8aac5bfff33b22211222bcdf94b571c00d93d999 is loaded with triples; F's, 2's, 2's again, and 9's (trailing) but still the trailing triple 0's eludes us.
The block 1720 hash 00000000349ece8e0646fff3b5d97166f2331177bbb693111ed51fd9ba1d7886 seems unlikely triple F's, B's and 1's as well as the hex word "ba1d". It is an FBI hairless wonder.
Block 1045 hash is 00000000198fcebe08bddec72991be0dacb438d0ab5a9bbc589cd44cad250005 which is close but no cigar for trailing 0's.
The nonce is only 32 bits; could there come a day with the difficulty is high enough that no nonce works?
This was solved at least a year ago. The nonce is exhausted in sub-second at a miner working faster than 4 GH/s, but one can step the create time of the block and also alter the block by including new transactions. Actually having a small nonce incentives including new transactions to alter the hash. 
The nonce is only 32 bits; could there come a day with the difficulty is high enough that no nonce works?
It has already happened.
There is a 2nd "extra nonce" in the coinbase transaction.
This is 100 bytes long (at most). If you change that, then the merkle root changes.
This has to be done once for every 4 billion nonces.
Miners that can do that themselves use much less bandwidth for pools.
The nonce is only 32 bits; could there come a day with the difficulty is high enough that no nonce works?
That day was back in like 2009 or 2010. A difficulty of 1 corresponds to an average of 1 valid block per nonce range. At difficulty 2, you expect to find one valid block per 2 full iterations through the range (on average).
Oh, I see. How does one change the block contents after a full iteration fails to find a suitable hash?
The traditional method is to increment extraNonce, an optional "field" in the coinbase garbage string, which changes the generate transaction, which changes the merkle tree root, which changes the header. You can also fudge the timestamp.
The nonce is only 32 bits; could there come a day with the difficulty is high enough that no nonce works?
That day was back in like 2009 or 2010. A difficulty of 1 corresponds to an average of 1 valid block per nonce range. At difficulty 2, you expect to find one valid block per 2 full iterations through the range (on average).
Oh, I see. How does one change the block contents after a full iteration fails to find a suitable hash?
We have had over 250,000 blocks produced so far; what's the distribution of nonces looking like?
How do miners avoid using a nonce that some other miner has already checked?
How do miners avoid using a nonce that some other miner has already checked?
The nonce is only 32 bits; could there come a day with the difficulty is high enough that no nonce works?
That day was back in like 2009 or 2010. A difficulty of 1 corresponds to an average of 1 valid block per nonce range. At difficulty 2, you expect to find one valid block per 2 full iterations through the range (on average).
Satoshi could have had us searching for hashes greater than some number in which case we would be seeing hashes with leading F's instead. Then I would be looking for trailing F's. So, ok, in that sense leading and trailing 0's and F's are different. Still the mathematically inclined would have taken a little delight in seeing the decimal representation of PI appearing digit by digit over time.
The nonce is only 32 bits; could there come a day with the difficulty is high enough that no nonce works?
I fully realize trailing 0's are no more interesting than any other arbitrary sequence but Satoshi started it with his leading 0's. Why not leading 1's? Why not a leading sequence of 3.1415926535...? No, the cat is out of the bag.
Mining blocks is not about constructing a block hash with leading zeros, but a hash numerically less than a target number. Leading zeros in the hash are just the consequence of that target being less and less with increasing difficulty.
Difficulty is the ratio of initial/current target.
I fully realize trailing 0's are no more interesting than any other arbitrary sequence but Satoshi started it with his leading 0's. Why not leading 1's? Why not a leading sequence of 3.1415926535...? No, the cat is out of the bag.
The very first occurrence of a trailing 0 is;
http://blockexplorer.com/b/42 with a hash of 00000000ac21f2862aaab177fd3c5c8b395de842f84d88c9cf3420b2d393e550
but then very soon after that we have a trailing double 0;
http://blockexplorer.com/b/49
00000000f067c09041ff0fcee3d91aeb7fbcc5654d3f766af2b4377aaee68d00
but it takes a long time until another trailing double 0 comes along;
http://blockexplorer.com/b/665
000000008b3292ededf3a3a675c44bb2a2ac378878fad1c10cef4219f2d95100
One wonders when a trailing triple 0 appears.
http://blockexplorer.com/b/42 with a hash of 00000000ac21f2862aaab177fd3c5c8b395de842f84d88c9cf3420b2d393e550
but then very soon after that we have a trailing double 0;
http://blockexplorer.com/b/49
00000000f067c09041ff0fcee3d91aeb7fbcc5654d3f766af2b4377aaee68d00
but it takes a long time until another trailing double 0 comes along;
http://blockexplorer.com/b/665
000000008b3292ededf3a3a675c44bb2a2ac378878fad1c10cef4219f2d95100
One wonders when a trailing triple 0 appears.
Quote
Not doubting this, just curious what the actual math is convincing you that SHA256 is solid. Do you have a pointer?
On a related note, if a solid (1) hash function actually did exist, it would have some groundbreaking implications: Theoretical implications of one-way functions.(1) "In computer science, a one-way function is a function that is easy to compute on every input, but hard to invert given the image of a random input. Here, "easy" and "hard" are to be understood in the sense of computational complexity theory, specifically the theory of polynomial time problems." ~ Wikipedia:One-way function
If you have a solid hash function (which SHA256 is) and you come across a collision, then either:
(1) SHA256 is broken
(2) You hashed two things that were identical
End of story.
Not doubting this, just curious what the actual math is convincing you that SHA256 is solid. Do you have a pointer? (1) SHA256 is broken
(2) You hashed two things that were identical
End of story.
People like to take the idea "hash collisions are theoretically possible!" and pretend like they could actually happen and that something in life should accommodate that possibility. If you have a solid hash function (which SHA256 is) and you come across a collision, then either:
(1) SHA256 is broken
(2) You hashed two things that were identical
End of story. There's about as many different SHA256 hash values as there are atoms in the universe. From the perspective of a human, a proper hash function that outputs more than 128 bits do not have collisions. They won't even happen in the future due to increasing computational speed -- Bruce Schneier showed that the thermodynamic lower-bound of energy to find such a collision is many billion times more energy than the sun contains.
(1) SHA256 is broken
(2) You hashed two things that were identical
End of story. There's about as many different SHA256 hash values as there are atoms in the universe. From the perspective of a human, a proper hash function that outputs more than 128 bits do not have collisions. They won't even happen in the future due to increasing computational speed -- Bruce Schneier showed that the thermodynamic lower-bound of energy to find such a collision is many billion times more energy than the sun contains.
well... whatever some1 says... they CAN happen. Just because the chance is VERY-low*10^whateverhere does not mean it's impossible.
Math don't care about Atoms in the Universe or a human lifetime.
End of story.
Not the end of story by far and here where people start losing grasp of the link between math, natural sciences and their real life implications. What to be considered impossible to occur in nature is well defined even though it is within the boundaries of mathematical calculations.
Start from here please http://en.wikipedia.org/wiki/Fermi_paradox, The journey has just started ^_^.
People like to take the idea "hash collisions are theoretically possible!" and pretend like they could actually happen and that something in life should accommodate that possibility. If you have a solid hash function (which SHA256 is) and you come across a collision, then either:
(1) SHA256 is broken
(2) You hashed two things that were identical
End of story. There's about as many different SHA256 hash values as there are atoms in the universe. From the perspective of a human, a proper hash function that outputs more than 128 bits do not have collisions. They won't even happen in the future due to increasing computational speed -- Bruce Schneier showed that the thermodynamic lower-bound of energy to find such a collision is many billion times more energy than the sun contains.
(1) SHA256 is broken
(2) You hashed two things that were identical
End of story. There's about as many different SHA256 hash values as there are atoms in the universe. From the perspective of a human, a proper hash function that outputs more than 128 bits do not have collisions. They won't even happen in the future due to increasing computational speed -- Bruce Schneier showed that the thermodynamic lower-bound of energy to find such a collision is many billion times more energy than the sun contains.
well... whatever some1 says... they CAN happen. Just because the chance is VERY-low*10^whateverhere does not mean it's impossible.
Math don't care about Atoms in the Universe or a human lifetime.
End of story.
Jump to: