For fun: the lowest block hash yet

[etotheipi]

Since I finally figured out how to read the block chain, I decided it would be fun to find the lowest hash produced, yet.  The hash for a block doesn't have to be AT that difficulty, it just has to beat it, and I figured there's gotta be some blocks with major overkill in terms target hash, just by luck.  Well here it is, block 125,552:

http://blockexplorer.com/block/00000000000000001e8d6829a8a21adc5d38d0a473b144b6765798e61f98bd1d

If I did the difficulty calculation correctly (no guarantees), I believe this block would've been valid even at difficulty 35,987,768,035  (current difficulty is 1,564,057).  Can someone verify that?

[1679411407]

1679411407

[1679411407]

1679411407

[1679411407]

1679411407

[1679411407]

1679411407

[hashcoin]

Quite cool!

Here's an easy way to do the math:  think of putting a "0." before the target hash value, and now you have a number between 0 and 1 written in hex.  (E.g., 0.A in hex is 0xA/0x10).

Call this number p.  But now observe p is precisely the probability you beat that target.  So it would take on average, 1/p hashes to beat.

So to get the # of hashes, just get 1/p.  To get the difficulty, divide that by 2^32 since difficulty 1 = 2^32 hashes (equivalently, difficulty 1 = dot shifted over 8 places to right).

If you have a python interpreter handy, you can see:

Code:

>>> pinv = (2**256)/0x00000000000000001e8d6829a8a21adc5d38d0a473b144b6765798e61f98bd1dL
>>> pinv
154566286767518877857L
>>> pinv/2**32
35987768035L

If you want to go another step, you could compute the probability this happened by now in a parallel bitcoin world.  If you have your script handy, just compute the SUM of all difficulties, over all blocks.  That * 2^32 is roughly how many hashes have been done since bitcoin was born.

[etotheipi]

That's high, but it's not ludicrous given the amount of hashing that has been done in the last year.  At the current global hashrate, it seems it would take 150 days (on average) to find another hash just as good.  The blockchain has been in generation for over a year, but with much lower rates for most of that time.

Well okay, let's be more precise:  I summed up all the difficulties up to block 136,496.  The total value is 10,939,043,020.8.  Take the log-base-2 and add 32 for the difficulty=1 size:  you get 65.35.  So the network has executed on somewhere around 2^65.35 hashes to produce the 136,496 blocks with their associated difficulties.  This isn't terribly far from the block in question, requiring on average 2^67.07 hashes.   It is only 3.3 times higher (1.72 bits) higher than the total difficulty sum.  

This is well within the scope of the exponential distribution of block generation.  This is like having enough computational power on the network for the difficulty to be at 35 billion, and then the network solving a block at that difficulty in 3 minutes.  Three-minute blocks happen all the time.

[Noitev]

Has anyone beaten this yet considering the 2 year gap and insane difficulty increase (and  consequently, hashrate) since this thread started?

[gmaxwell]

SetBestChain: new best=000000000000000004ae693a1a8e740a33dd996c27ccc64217ed647e0b90d910  height=244583  log2_work=70.572612  tx=20254333  date=2013-07-03 14:50:02 progress=0.645633

Effective "difficulty": 234,873,483,844  or about 69.77 bits, thats somewhat behind relative to the cumulative work at that point (and our current amount: log2_work=71.682609)

Block 125552 is now the 20th best, fwiw. The current top 20 are:


000000000000000004ae693a1a8e740a33dd996c27ccc64217ed647e0b90d910
000000000000000006582fa9652895fda92c757ae6beee9dfbc3932125b5ab8e
00000000000000000ae2dba9951e28a3e6308ac7e9e8536104c503aa772c848f
00000000000000000c5da159125977d610e97afaad2b52c5641cf5d107cbb4c8
00000000000000000ce84e315900096f772ddce728fe74eb01cb2f5ca9b8a608
00000000000000000eab32386b8854581ca95f672ec9ccd96d2201c493f2c644
00000000000000001115d0f81474bbb9ebb9a45e04597f2df39e0eba903b679f
0000000000000000139008bfda982356c5065c9035d6c7d588069d3e1b35746a
000000000000000013b542b70897dcb248a0379e7a2cf9763f5fb3e90759072a
000000000000000014d28626334cb5bcd8aad5b3a313239b7d669b232dfe7021
000000000000000017f9c4f0af122d4a8cd9607acfecaffa7445ba3fc4523297
0000000000000000193f0908548ed5a36237a0a6f9fa480d79d107d31eb329d2
000000000000000019e6cf209f3509db56f45ad6f1f85287c1202f634911e87b
00000000000000001a956b37c9e81414c43086acd14ec1c0e32fd3ff995efc6b
00000000000000001b0490e228c3f66442fc0b4ac740a3223a90ce71e2cf9026
00000000000000001b81cb08052cff1f1468d3e9bdb42fb7487cea6a9d62f233
00000000000000001bfaa06e0d8c9aa94ce50ecf685d153e81f65e56546cf0bb
00000000000000001c0ac3a94007add81dee24ab9ab4d7dc87636a6c9260483d
00000000000000001ceb24157a3316477b4529b0c4d9be7636aedb05f8981003
00000000000000001e8d6829a8a21adc5d38d0a473b144b6765798e61f98bd1d

[Noitev]

ty!

[David Rabahy]

Which hash has the most trailing 0s?  Is a hash of *all* 0s possible?

[David Rabahy]

Can a hash *ever* repeat?

[eb3full]

To answer both your questions David, yes a hash can repeat and yes a hash with all zeroes exists (an infinite number of strings can produce it, in fact).

http://en.wikipedia.org/wiki/Cryptographic_hash_function

However, neither of those situations are even remotely likely given what we understand about hash functions, in particular SHA-2.

[gmaxwell]

To answer both your questions David, yes a hash can repeat and yes a hash with all zeroes exists (an infinite number of strings can produce it, in fact).

I don't actually know that we know if there is a hash with all zeros.  The state space of the SHA2-256 compression function is 'only' 768 bits and it's not at all constructed like a permutation on the input. There is clearly internal cancellation, so  AFAICT some outputs may be unreachable but we don't know which ones are.

[kjj]

Can a hash *ever* repeat?

This question is oddly difficult in bitcoin.  In bitcoin, the hashes are used as identifiers.

As pointed out by others already, cryptographic hashing systems are essentially lossy compression.  For a given sha256 output, there is at least one input that creates it, and possibly an infinite number.  A block header is 80 bytes long, and a sha256 output is 256 bits long.  If we assume an even distribution for both the bits of a header (known to be false) and for sha256 (see previous posts, and my addition below), we can expect about 2³⁸⁴ possible block headers per block ID, with 384 being 640-256.

It gets messy in reality.  Large portions of the block header are not evenly distributed, and several of those portions are moving targets.  Someone could probably work up reasonable estimates for the actual bits of freedom for a given block header candidate, and from that estimate how many such candidates we can expect per output.  I find it interesting enough, but it is late, and I'm tired, so I won't bother.

With that pointless aside out of the way, back to identifiers.  We use the block header hashes as identifiers for the block.  The network enforces uniqueness of these identifiers in an odd way.  Say you are hashing along, and you find a nonce that satisfies a header for the next block, but by a strange twist of fate, that hash just happens to be equal to a freakishly low hash previously found*, perhaps one listed in this thread.  Your node announces this to peers by sending them a message with the new block's identifier.  They all ignore you, because they already "have" that block and so there is no point asking you for the rest of it.  I'm actually not sure how your node would even handle it.  I'd have to check the code to see if it would overwrite the old block, or drop the new one.  Odds are good that we'll never find out the hard way.

With transactions, it is even worse.  The same mechanism exists, but nodes do not (by default) keep full track of all transactions, just unspent ones.  It is possible** to create a new transaction that happens to have the same hash as an old transaction.  Again, I'm not sure how it would end up without reading the code.

* I'm not sure if this would qualify for impossibly good luck, or impossibly bad luck.  Certainly one of these extremes though

**  Not really.  The birthday attack on 2²⁵⁶ is still impossibly huge.

I don't actually know that we know if there is a hash with all zeros.  The state space of the SHA2-256 compression function is 'only' 768 bits and it's not at all constructed like a permutation on the input. There is clearly internal cancellation, so  AFAICT some outputs may be unreachable but we don't know which ones are.

Indeed.  The output space of sha256 is currently unknown.  We suspect (hope) that it is close to [0-2²⁵⁶], but we don't exactly know that.  Cryptographic hashes look a hell of a lot like random numbers, by design.  One of the standard tests is to generate pairs of hashes from pairs of inputs that differ by a single flipped bit.  We expect that about half of the output bits will change between pairs, on average, and we expect a fairly flat distribution of flip counts for each bit position, again, on average.  The sha family passes these tests, and from this, we gain confidence (but not certainty) about the distribution of outputs.

[etotheipi]

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. 

[w00dy]

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. 

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.

[lophie]

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. 

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 ^_^.

[grau]

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?

[fpgaminer]

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 ⁽¹⁾ 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

[David Rabahy]

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.

[David Rabahy]

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.

[grau]

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.

[David Rabahy]

The nonce is only 32 bits; could there come a day with the difficulty is high enough that no nonce works?

[David Rabahy]

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.

[kjj]

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).

[David Rabahy]

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?

[David Rabahy]

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?

[kjj]

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.

[David Rabahy]

https://en.bitcoin.it/wiki/Block_hashing_algorithm

[TierNolan]

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.

[grau]

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.

[David Rabahy]

Block 1045 hash is 00000000198fcebe08bddec72991be0dacb438d0ab5a9bbc589cd44cad250005 which is close but no cigar for trailing 0's.

[David Rabahy]

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.

[David Rabahy]

http://nedbatchelder.com/text/hexwords.html

[David Rabahy]

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.

[TierNolan]

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.

Three zeros should happen once every 4096 blocks on average, so there should be loads.

[David Rabahy]

N trailing 0's should appear with an average of 1:2^(4N).

N 0's anywhere in 64 hexdigits is 1:2^(4N-6).

Excluding the leading 0's cuts into our odds.

[gmaxwell]

2013-09-16 06:36:03 SetBestChain: new best=0000000000000000004bb6e7e2661661ba9809062d90c3121933d6d02c8bd763  height=258283  log2_work=71.955296  tx=23869863  date=2013-09-16 06:35:37 progress=0.999997

We're pretty lucky now with a 73.75 bit solution on 71.95 in effort.

[gmaxwell]

2013-10-27 14:55:42 SetBestChain: new best=000000000000000000028c32e6952731326747bae4be8db0f832d6eea0362050  height=266381  log2_work=73.237967  tx=26093998  date=2013-10-27 14:49:44 progress=0.999972

In [592]: math.log((2**256)/0x000000000000000000028c32e6952731326747bae4be8db0f832d6eea0362050,2)
Out[592]: 78.65083195521588

[Ecurb123]

Since I finally figured out how to read the block chain, I decided it would be fun to find the lowest hash produced, yet.  The hash for a block doesn't have to be AT that difficulty, it just has to beat it, and I figured there's gotta be some blocks with major overkill in terms target hash, just by luck.  Well here it is, block 125,552:

http://blockexplorer.com/block/00000000000000001e8d6829a8a21adc5d38d0a473b144b6765798e61f98bd1d

If I did the difficulty calculation correctly (no guarantees), I believe this block would've been valid even at difficulty 35,987,768,035  (current difficulty is 1,564,057).  Can someone verify that?

How did you figure out how to read the block chain? can you recommend any sites? 

[kjj]

Since I finally figured out how to read the block chain...

How did you figure out how to read the block chain? can you recommend any sites? 

It is like that scene in the Matrix.  Just set your terminal to green and let it scroll by for a while.  After a while you'll be able to just "see" things.

[hahahafr]

2013-10-27 14:55:42 SetBestChain: new best=000000000000000000028c32e6952731326747bae4be8db0f832d6eea0362050  height=266381  log2_work=73.237967  tx=26093998  date=2013-10-27 14:49:44 progress=0.999972

In [592]: math.log((2**256)/0x000000000000000000028c32e6952731326747bae4be8db0f832d6eea0362050,2)
Out[592]: 78.65083195521588

This basically mean that brute-forcing something of 78.65 bits (80 almost) is possible?

[David Rabahy]

This basically mean that brute-forcing something of 78.65 bits (80 almost) is possible?

Um, short of (getting all of that computing power to cooperate to brute-force attack is unlikely in the extreme) but even 78.65 bits (rounding up to 80 is not reasonable; it is over 2.5x harder)  is a very long way from 160.  Whatever computing power it took to get to this 78.65 bit result is 81.35 bits short, i.e. over 3 billion trillion times.  If you can gather even 1/65536th of it I'd be stunned but that would put you at 62.65 bits, i.e. over 200 trillion trillion times short.  Spend your energy pursuing something a little more likely to bear fruit.

[gmaxwell]

Really the network has only done about 73.6 bits of work so far, our lowest is lucky.

[e4xit]

Really the network has only done about 73.6 bits of work so far, our lowest is lucky.

Statistically, as the block hashes (I assume) form some kind of distribution, I would say in laymans terms, that we are likely within the 73.6 bits of work done so far to have some outliers or 'lucky' results.

My question would therefore be, would the amount of 'luck' required for our lowest yet fall outside the expected distribuition (and therefore be truely 'lucky') or is this "expected luck"?

[elgreco]

Update please 

[gmaxwell]

Not too much has happened, I was waiting to get one with apparent work > 2^80 to update again.

Best right now is 0x000000000000000000049bb3b6b9c135f66536e066704369905043df809c2441 ... or about 2^77.79, the cumulative block measured work level on the network is at 2^79.3 so we're behind.

[sile16]

What is the best block for litecoin?

[abcdefyyy]

Ok, I scan the blockchain in python and calculated the achieved difficulty for each block.

If anyone is interested I can put the data here.

Interesting thing is that the block 0 (genesis block) have achieved difficulty equal to 2536.

[abcdefyyy]

Currently, the highest achieved difficulty has block 266381:

https://blockchain.info/block/000000000000000000028c32e6952731326747bae4be8db0f832d6eea0362050

Achieved difficulty: 110,484,089,548,580

[gmaxwell]

Currently, the highest achieved difficulty has block 266381:

https://blockchain.info/block/000000000000000000028c32e6952731326747bae4be8db0f832d6eea0362050

Achieved difficulty: 110,484,089,548,580

See also: https://bitcointalk.org/index.php?topic=29675.msg3490536#msg3490536

[gmaxwell]

00000000000000000000b7de9e5c19e52be073156924b7cf235efb27ae8a202a

math.log((2**256)/0x00000000000000000000b7de9e5c19e52be073156924b7cf235efb27ae8a202a,2) = 80.47746080768307

"Apparent difficulty" of 391,895,084,984,304.

And pretty much just on track with the regular block measured work: UpdateTip: new best=00000000000000000000b7de9e5c19e52be073156924b7cf235efb27ae8a202a  height=313338  log2_work=79.978295  tx=43580048  date=2014-07-31 13:29:05 progress=0.999999

This is the first block solution we've found which is a >80 bit partial preimage of 0.

[amaclin]

We should start "Guinness facts for Bitcoin" project with an answers to all popular (and even dumb) questions

1. What is the lowest block hash seen?
2. What is the maximum tx (in bytes, in funds, in fees)
3. What is the longest scriptPub and scriptSig?
4. How many zeros does your publicKey have in hex representation?
5. The first and last (alphabet order) address (need signature verifying)
6. Maximum transactions count in block
... etc

[teukon]

00000000000000000000b7de9e5c19e52be073156924b7cf235efb27ae8a202a

math.log((2**256)/0x00000000000000000000b7de9e5c19e52be073156924b7cf235efb27ae8a202a,2) = 80.47746080768307

"Apparent difficulty" of 391,895,084,984,304.

And pretty much just on track with the regular block measured work: UpdateTip: new best=00000000000000000000b7de9e5c19e52be073156924b7cf235efb27ae8a202a  height=313338  log2_work=79.978295  tx=43580048  date=2014-07-31 13:29:05 progress=0.999999

This is the first block solution we've found which is a >80 bit partial preimage of 0.

Oh, nice!

May I ask how you are calculating/estimating the total work done by the network?

[gmaxwell]

Oh, nice!
May I ask how you are calculating/estimating the total work done by the network?

The smallest block hash yet found is an estimate of the total work done by the network.  Also, the sum of the difficulties (well *2^32) on the blocks so far is an estimate, which is the one returned in the bitcoin core logs or in the getblockchaininfo rpc.

[teukon]

The smallest block hash yet found is an estimate of the total work done by the network.  Also, the sum of the difficulties (well *2^32) on the blocks so far is an estimate, which is the one returned in the bitcoin core logs or in the getblockchaininfo rpc.

I see, thanks.

Interestingly, it seems to me that we should be "ahead" in this sense about 2/3 of the time.  I believe this follows from the fact that given some amount of work done, n say (number of hashes), the probability that we are behind at that point is simply (1 - 1/n)^n which converges to exp(-1) as n tends to infinity.

[TheRealSteve]

The current top 20 are:

Time for an update, as another thread was posted that basically asked the same thing

The current top 20 are:

height   hash                                                               note
334261   000000000000000000002d414bb8f9175ba6c6563721e1ba2c1373c2bd94f29f
336175   000000000000000000005a5e143087632fbf0eea743ad99646d9fc67d40f7441
331908   000000000000000000006836c4009ab00485cd1de4d5958ca7839184d0b80067
326055   000000000000000000007e1166d92acf81d4e2d95934fcdec1276b09a7db9390
343775   000000000000000000007eef13ee1f2fcf1b469bd862fcc93b48ec49548ecf6d
340483   000000000000000000008ac86ba28085be84af2ebd6fc6935a004e57fb60c083
313338   00000000000000000000b7de9e5c19e52be073156924b7cf235efb27ae8a202a
331987   00000000000000000000ec03e3183bacc8b18437180f63f6a563267a186225bc
334151   0000000000000000000119adb3da72742b1eba98f9dc26f73858e91652b42287
333904   0000000000000000000119f88871f8a3c3b7be053c98b31e9c4676df30243cfe
320736   0000000000000000000137130c5a047157e7b0e063de6f3d30246a4f2005a818
315024   0000000000000000000181f37629e8b80debca2c295c350cb1bd156e7e1a25ee
340600   00000000000000000001a092bb0f2311bf00987a8f7d92e2ed6b36a522054741
324204   00000000000000000001bdebf80d8c40d9b30a6fe76b962ff59c8d3cdeec3473
343641   000000000000000000020fc1ca1268a27de8646059ae2bcca61d13d16890b5db
326091   000000000000000000024b7dea2b63b4e2be64ef1663369fe2f22504587d094b
330140   000000000000000000026ccbc4bbb6a608e90132329190291127f971a604e5c9
266381   000000000000000000028c32e6952731326747bae4be8db0f832d6eea0362050   lowest block height
349240   00000000000000000002a133e4691d2f8894a3af7a1b3624e8c2e8c7a8a4fe3c   highest block height
330727   00000000000000000003107221e16ef91fdf83b3729c5f370dafb754bf6443b2

[TheRealSteve]

Just to poke at some of David Rabahy's trivia questions:

Is a hash of *all* 0s possible?

Current block with the most number of 0's (anywhere, not just leading) in the hash:

height   hash                                                               note
326799   000000000000000003fec4b5cd08090ab80010345952ab08048e088a00c2b09b   29/64* zeros

(* see earlier discussion on whether all zeros is even theoretically possible )

One wonders when a trailing triple 0 appears.

http://btc.blockr.io/block/info/9521 (actually four trailing zeros - other blocks with four trailing: 83373, 293374, 332802)
http://btc.blockr.io/block/info/10169 (actual triple)
( there's none with 5 trailing zeros )

Which hash has the most trailing 0s?

Tie between the above four listed

Why not a leading sequence of 3.1415926535...?

Can't have it leading, of course, but here's one with 314159 in it, at least (only one, thus also no longer sequence yet):

height   hash
234923   0000000000000171ae44bb6c1700314159dc61480b54edf71e5281ee7c6147a7


Here's some other fun ones

height   hash
132928   00000000000011eec4defc0ffee303401e460d2b8406474692d0ff141b9cbbf4
170852   00000000000002b58bf498d718db69dfc25cb318036949d3dad6bc0ffee28744
 57598   00000000051565707437c6626a8f88c92fe9decaf4c19f0c1b77558d3bf03aac
 84177   0000000000161062e2762c06457decaf0298724f662468465c84ff595abde159
137577   00000000000001e06f54fa79354e337678f840a7bc75ddecaf8fd9d089f9eed2
148781   00000000000004c2d5703896fb122b28dc7347f3023b0decaf28e3aacffffcb1
189433   00000000000005decafc4b33943d70fc596dd080f9a6737d94e9b4c88d890bf7
210406   00000000000002de9c1decaf9cb207af4452e8f00baeadc7729618ff3f4ce9e9
272206   00000000000000048d9564d82b8ac4d20decafb08e831ea7c8ddef7b9b5fac90
279275   00000000000000004ada6d6cead5c00a860494582252371c9c294decaf3b422a
303682   00000000000000005a9d3af33c5b4b52cc6b53c8decafc6dfb4259b06681dfaa
317717   000000000000000002e4c9274d83196ef16b0130972e7cc6ddecaf735cc67699
344465   000000000000000006c7cdecaf9dbe50a5fc693e7a555550d57aa1706f3f964b
344545   00000000000000000bbcc57dd86a829d674506e0cb151a09e91a9decafbf292e

No 'deadbeef'... yet.

[Mikestang]

Thanks for the update!

[Har01d]

There is a couple more...

 323453 | 000000000000000012345b434cea9b76ae6bffb49e624ca60182fc15a0a1ee2b
 155644 | 00000000000002ad18f02d363564da3501234596dae6345b93fa1579fc3f7d98
 218505 | 0000000000000141c1e370d4123456771e7d77463e91e4f2a5e572257ef46362

 321252 | 000000000000000010c1948fe886469b0e8d4f6aef7c2373abcdefe8fc9a2e86
 270096 | 0000000000000003606abfa5b19abcdefd839cc1b0da2fea63cbda317597de5a
 112974 | 000000000000b6e76dba167cc240c0014abcdef563ecd8ceec73f1ac57c6f420

and there is no "dead*beef" yet, but there is...

 18851 | 000000005a18c8f3b0c7a32159b76edcdc7af5bada903af00d60dd8fad297c0c

Have fun

[Taras]

Okay, but what about the highest block hash?
I'm predicting it to start with 00000000ffff.

[TheRealSteve]

Okay, but what about the highest block hash?

The current bottom 10 are:

height   hash                                                               note
32009   00000000fff9e01287736bee2fecdd88ae31b5602858c5273d43351cfadecd58   highest block height
 5386   00000000fff91949181449d048aca5a1cc6d0e3e3f34e89c00ab2709696b8da0
27948   00000000fff58158d6ce595a2976d547f16b0ec8aba64b7a9a68c78d469b54b5
31664   00000000fff3d56591bc0eae8cee73a214d1d451d704f86126415ed540850df7
30133   00000000fff31576873d6ec35ba6659e72193ddf621ea1edd7faa462336a2211
 1304   00000000fff0728c5da1548b4f15576aa272f0f4952031ae56a5be355310ba0a   lowest block height
31108   00000000ffeec57f29c3f3df6014774aa1a2f00114ab16bd26b0d270974cd706
 9396   00000000ffeb8e847d94f7085c6cc0359c77d8ebe52b9fb59b90e9ef95a23c44
16250   00000000ffeb2708cfc0aa1b5db3a6eacccc9112eb10cc0de2ec3e98c6c11a7a
28614   00000000ffe5255e229781dd72b1626c4df90e77390d38f6337ce949bc3ff300

I'm predicting it to start with 00000000ffff.

AMAZING!
but wrong :x

[Taras]

Okay, but what about the highest block hash?

The current bottom 10 are:

height   hash                                                               note
32009   00000000fff9e01287736bee2fecdd88ae31b5602858c5273d43351cfadecd58   highest block height
 5386   00000000fff91949181449d048aca5a1cc6d0e3e3f34e89c00ab2709696b8da0
27948   00000000fff58158d6ce595a2976d547f16b0ec8aba64b7a9a68c78d469b54b5
31664   00000000fff3d56591bc0eae8cee73a214d1d451d704f86126415ed540850df7
30133   00000000fff31576873d6ec35ba6659e72193ddf621ea1edd7faa462336a2211
 1304   00000000fff0728c5da1548b4f15576aa272f0f4952031ae56a5be355310ba0a   lowest block height
31108   00000000ffeec57f29c3f3df6014774aa1a2f00114ab16bd26b0d270974cd706
 9396   00000000ffeb8e847d94f7085c6cc0359c77d8ebe52b9fb59b90e9ef95a23c44
16250   00000000ffeb2708cfc0aa1b5db3a6eacccc9112eb10cc0de2ec3e98c6c11a7a
28614   00000000ffe5255e229781dd72b1626c4df90e77390d38f6337ce949bc3ff300

I'm predicting it to start with 00000000ffff.

AMAZING!
but wrong :x

Damn! My Big Gang Mafia intuition was wrong!

I wrote a chain parser myself but only did the first 10,000 blocks. (It can only see blk000000.dat)

What about the hashes with the most zeros anywhere in the hash?

[bitspill]

What about the hashes with the most zeros anywhere in the hash?

Is a hash of *all* 0s possible?

Current block with the most number of 0's (anywhere, not just leading) in the hash:

height   hash                                                               note
326799   000000000000000003fec4b5cd08090ab80010345952ab08048e088a00c2b09b   29/64* zeros

(* see earlier discussion on whether all zeros is even theoretically possible )

[Taras]

What about the hashes with the most zeros anywhere in the hash?

Is a hash of *all* 0s possible?

Current block with the most number of 0's (anywhere, not just leading) in the hash:

height   hash                                                               note
326799   000000000000000003fec4b5cd08090ab80010345952ab08048e088a00c2b09b   29/64* zeros

(* see earlier discussion on whether all zeros is even theoretically possible )

[TheRealSteve]

What about the hashes with the most zeros anywhere in the hash?

I listed the one with the most (at that time) already

[organofcorti]

Some visualisations and explanations of highest difficulty / smallest blockhashes:
http://organofcorti.blogspot.com/2015/05/the-tiniest-blockhashes.html

[TheRealSteve]

I thought this graph...

...was actually more interesting  Any chance you could plot one that hasn't been binned?

[organofcorti]

I thought this graph...

...was actually more interesting  Any chance you could plot one that hasn't been binned?

Sure - but then you just get a lot of overplotting. The colour represents the number of blocks in each bin, so unbinned you'd just  have a scatter plot that was solid black at the bottom and black dots at the top. If I make each point translucent, you might see a bit more detail. Maybe it's just the colours that put you off?

[organofcorti]

This is unbinned with very small, slightly translucent points:

[TheRealSteve]

Yep, that's it.  I thought I noticed some sort of patterning in the color coded one earlier, looks like it's more pronounced in this - I suspect that's just the graphing package and things tricking my eyes, or the ECDF would have shown them as well.  Nice work as always

[organofcorti]

Yep, that's it.  I thought I noticed some sort of patterning in the color coded one earlier, looks like it's more pronounced in this - I suspect that's just the graphing package and things tricking my eyes 

Randomness can be clumpy - if it was all evenly spaced, it wouldn't be random. Humans are very good at pattern recognition, but it's easy to squeeze clumpy randomness into a pattern.

or the ECDF would have shown them as well

Maybe, but the CDF ignores changes over time. If there were strange patterns from time to time,  it might not show up in the CDF / PDF, if the patterns balanced out.

Nice work as always

Cheers!

[TheRealSteve]

Randomness can be clumpy - if it was all evenly spaced, it wouldn't be random.

Just to show what I was seeing - which does go a bit beyond clumping:

If you squint just right and convince your brain that it's there, then you can somewhat see it in the color coded one as well.

But you can see that in the b/w version it's almost certainly just the filtering of samples in the rasterized output.

[TheRealSteve]

While we're in this thread - minor update.  The current top 20 (green = new) are:

height   hash
334261   000000000000000000002d414bb8f9175ba6c6563721e1ba2c1373c2bd94f29f
336175   000000000000000000005a5e143087632fbf0eea743ad99646d9fc67d40f7441
331908   000000000000000000006836c4009ab00485cd1de4d5958ca7839184d0b80067
357845   0000000000000000000072fb4daee93cb0ef53f292898febaa8353743469f9d1
326055   000000000000000000007e1166d92acf81d4e2d95934fcdec1276b09a7db9390
343775   000000000000000000007eef13ee1f2fcf1b469bd862fcc93b48ec49548ecf6d
340483   000000000000000000008ac86ba28085be84af2ebd6fc6935a004e57fb60c083
313338   00000000000000000000b7de9e5c19e52be073156924b7cf235efb27ae8a202a
355287   00000000000000000000bf159dbb0f8fb3fe450337a5aea11ead28c67673788f
331987   00000000000000000000ec03e3183bacc8b18437180f63f6a563267a186225bc
334151   0000000000000000000119adb3da72742b1eba98f9dc26f73858e91652b42287
333904   0000000000000000000119f88871f8a3c3b7be053c98b31e9c4676df30243cfe
320736   0000000000000000000137130c5a047157e7b0e063de6f3d30246a4f2005a818
315024   0000000000000000000181f37629e8b80debca2c295c350cb1bd156e7e1a25ee
340600   00000000000000000001a092bb0f2311bf00987a8f7d92e2ed6b36a522054741
324204   00000000000000000001bdebf80d8c40d9b30a6fe76b962ff59c8d3cdeec3473
353863   00000000000000000001e5b926f30e95405028c7a99039ca6d0d56fe4e6c3fcd
343641   000000000000000000020fc1ca1268a27de8646059ae2bcca61d13d16890b5db
326091   000000000000000000024b7dea2b63b4e2be64ef1663369fe2f22504587d094b
330140   000000000000000000026ccbc4bbb6a608e90132329190291127f971a604e5c9

[kano]

Yep, that's it.  I thought I noticed some sort of patterning in the color coded one earlier, looks like it's more pronounced in this - I suspect that's just the graphing package and things tricking my eyes 

Randomness can be clumpy - if it was all evenly spaced, it wouldn't be random. Humans are very good at pattern recognition, but it's easy to squeeze clumpy randomness into a pattern.

...

Well ... it's not actually random, it's only pseudo random
Given enough data over millions of years it would probably show some artifacts of the pseudo randomness.

[TheRealSteve]

Haven't updated this in a while.  The current top 20:

height   hash
368527   00000000000000000000013712632da34788a7b4ae2cd78f7982c7036610126b
334261   000000000000000000002d414bb8f9175ba6c6563721e1ba2c1373c2bd94f29f
359189   00000000000000000000362e61dba7cfba02b6968a25e1fe97e586a22e87b22f
362662   00000000000000000000408db85bb513d26d72bf0ea42bdae820767f6e2697d4
336175   000000000000000000005a5e143087632fbf0eea743ad99646d9fc67d40f7441
331908   000000000000000000006836c4009ab00485cd1de4d5958ca7839184d0b80067
357845   0000000000000000000072fb4daee93cb0ef53f292898febaa8353743469f9d1
326055   000000000000000000007e1166d92acf81d4e2d95934fcdec1276b09a7db9390
343775   000000000000000000007eef13ee1f2fcf1b469bd862fcc93b48ec49548ecf6d
340483   000000000000000000008ac86ba28085be84af2ebd6fc6935a004e57fb60c083
313338   00000000000000000000b7de9e5c19e52be073156924b7cf235efb27ae8a202a
355287   00000000000000000000bf159dbb0f8fb3fe450337a5aea11ead28c67673788f
359689   00000000000000000000dd919214b66444dcebb4aa0214c1ab7c8b3b633be71f
364962   00000000000000000000e3aadb2227cf42d409efc74cb558915a75f6bc47b156
331987   00000000000000000000ec03e3183bacc8b18437180f63f6a563267a186225bc
369564   00000000000000000000fa6aea584eda3f73baad34a67359cd5d5bf804fb4b22
334151   0000000000000000000119adb3da72742b1eba98f9dc26f73858e91652b42287
333904   0000000000000000000119f88871f8a3c3b7be053c98b31e9c4676df30243cfe
320736   0000000000000000000137130c5a047157e7b0e063de6f3d30246a4f2005a818
368831   000000000000000000015f96db0d6fa3933adc083d316de76684f3a536ce566e

Hurray trivia.

Block 368527 is also the least lucky block hash - which is to say it is the luckiest (lowest hash so far), but it was also the lowest fraction of the target, so the difficulty could have been much higher and it would have still been valid.
Block 331816, in those terms, was the luckiest; clocking in 'just barely' under the target:

00000000000000001b48610000000395e67ff70a0effd0718099cc0000000000 : target
00000000000000001b48534ff39bc165477e3b5459b05679bdcf8ce2a3927fe7 : hash

Actually, the above may not be very precise due to potential conversion issues and big number handling.  The next four contenders are blocks 270605, 50249, 128228 and 316072

[kano]

I keep a dump of the full chain (with a script that simply adds to it by calling bitcoin-cli with one addition, the timestamp converted)
So the best 42 with a few more details:

Code:

height,hash,version,merkleroot,time,stamp,nonce,bits,difficulty,previousblockhash
368527,00000000000000000000013712632da34788a7b4ae2cd78f7982c7036610126b,3,ba9e999ec89abb48ec43e09baa78ad9d71b686b692bea461fdc4aba203ccab22,1438792320,20150805163200UTC,164730193,18150815,52278304845.59168243,000000000000000007f747d18dfe532711ffd235b2e956087a1eeb1e84a023a0
334261,000000000000000000002d414bb8f9175ba6c6563721e1ba2c1373c2bd94f29f,2,927c4cd7cbbd6108a503066235bb8d67433165621403b33ed1e9647726f25d5a,1418549296,20141214102816UTC,1152930690,181b7b74,40007470271.27126312,000000000000000015d614c45d21815067ba6444375137e2b3f0b3f876d27158
359189,00000000000000000000362e61dba7cfba02b6968a25e1fe97e586a22e87b22f,3,bcebb3c1ca42318f2c23fbbb46ed76cb05bed0d8f640920ac39b2bfcbda14a5c,1433306109,20150603043509UTC,2719600444,18171a8b,47589591153.62500763,00000000000000000a0592d859e14b85ffa12465130afcb46956f348433251ab
362662,00000000000000000000408db85bb513d26d72bf0ea42bdae820767f6e2697d4,3,87b42ed742da80247855b0af2d3eaa347e0991fdfcc36905aba52893c0fc4e9f,1435337761,20150626165601UTC,1939858592,18162043,49692386354.89383698,000000000000000002c302ccf8444d3004410dad95d8fb7f1852416f7770c1d1
336175,000000000000000000005a5e143087632fbf0eea743ad99646d9fc67d40f7441,2,2d95a4d46364433aace4e8db0647016c8c44d1714ac7a5ed2b7e92455cf1c023,1419698136,20141227173536UTC,3018248670,181bdd7c,39457671307.13873291,00000000000000000058a64b1c99fbc1e07a88a7fd582fef64f48f7c382f1b45
331908,000000000000000000006836c4009ab00485cd1de4d5958ca7839184d0b80067,2,16740f453b7d5824d4504cbacf42c982fae541be8b7ba4e207317e6d5454a6a8,1417139324,20141128024844UTC,4177274150,181b4861,40300030327.89140320,000000000000000003cd9048dfba61889e4305832094c6c7683e090d6032c4ad
357845,0000000000000000000072fb4daee93cb0ef53f292898febaa8353743469f9d1,2,06fe1c7085409dc75b24f9455a11706bfa76e333f7534ab5fed6cc1e61010078,1432487315,20150524170835UTC,2988452242,181686f5,48807487244.68138123,00000000000000001535cea56463f8fc76d3680893d650c78b208a55edfe493a
326055,000000000000000000007e1166d92acf81d4e2d95934fcdec1276b09a7db9390,2,1130dc9ed745b04282a4e001bedc79c4a711b6cca98fc71d5bff00152805c150,1413741766,20141019190246UTC,532302443,181f6973,35002482026.13323212,00000000000000000983d8f48d0f9c4f569704a1de7821b0a402d1473fb65eff
343775,000000000000000000007eef13ee1f2fcf1b469bd862fcc93b48ec49548ecf6d,2,ffaa3b7a7f1eaaf69c152e6737442eebcedc4f8d6c0fb8387d54273a41ce5c9c,1424114286,20150216201806UTC,159730112,1818bb87,44455415962.34380341,000000000000000013baae8473d0dbf5e957090ac2a800784d938f1f1f8d8548
340483,000000000000000000008ac86ba28085be84af2ebd6fc6935a004e57fb60c083,2,e4505511a79ca29c2c39eb725a3fc4a4e1778571b060a509854e90813d58aea2,1422229537,20150126004537UTC,2630103979,1819012f,43971662056.08957672,0000000000000000028e90bad02c9baa9c1ad1c3da8131098f4eb266a366450c
313338,00000000000000000000b7de9e5c19e52be073156924b7cf235efb27ae8a202a,2,7e4100d82f943e053ba07f73f9d5a086cd2432794530e2603a3a29304914cd18,1406813345,20140731132905UTC,2884015769,183aaea2,18736441558.31023788,00000000000000001e721b3b255fc67519d72ac2f28cb9000864dfe01e95990e
355287,00000000000000000000bf159dbb0f8fb3fe450337a5aea11ead28c67673788f,3,dbea8b4b6df3d59c4f4d8d623a7f7acd122b58d997dfa925d879f1cdd7529076,1430952345,20150506224545UTC,2815845631,181713dd,47643398017.80344391,00000000000000000953e1f084f05d6cc6900798c3aaab8bbba84ce3f1abab82
359689,00000000000000000000dd919214b66444dcebb4aa0214c1ab7c8b3b633be71f,3,197af49ffe2bab138f99881fb4738d2bddcc5f977da57f91a2eaa115dbba9bec,1433603769,20150606151609UTC,3629404841,18171a8b,47589591153.62500763,0000000000000000065f1b19e9da15f1738ab7541afb49112c563437917677b2
364962,00000000000000000000e3aadb2227cf42d409efc74cb558915a75f6bc47b156,3,19e9687a98f744fcc552fe2c2b03412f95dc30a704c55232d710f7dddbf35c0c,1436686259,20150712073059UTC,579964760,181586c8,51076366303.48192596,000000000000000001ba6ff79ce4e7cbcb310096481c388d614444e5717ecd45
331987,00000000000000000000ec03e3183bacc8b18437180f63f6a563267a186225bc,2,ea85597794d5dbe3b2e37966b499bfb79ff3fe2765d9cb88b5f1038029628ac3,1417179603,20141128140003UTC,279866634,181b4861,40300030327.89140320,00000000000000001ae74a30d04b6be7f5fb9dd2ca46a88d0783a726523c3e3c
369564,00000000000000000000fa6aea584eda3f73baad34a67359cd5d5bf804fb4b22,3,442dae106beff1527fae4dd2a225341b2077994ad31843d161313ae292a2921c,1439390175,20150812143615UTC,347869571,1814dd04,52699842409.34700775,000000000000000010de29f86cdfab5a9f64c02c334bf13456ea12b5d8939b19
334151,0000000000000000000119adb3da72742b1eba98f9dc26f73858e91652b42287,2,cae503590a5ffc744627fc28a22cae4f8cdb627f2121dcf7b4c56a6ee909b4a0,1418480434,20141213152034UTC,3374174994,181b7b74,40007470271.27126312,00000000000000000fc8b4bfb9f64ae5563f647665015bc7b0b1b77d055ad884
333904,0000000000000000000119f88871f8a3c3b7be053c98b31e9c4676df30243cfe,2,53c465268742b0454166e7f8cbe415288fc08745cce3074df4f3ee24884b55fe,1418331464,20141211215744UTC,4245885005,181b7b74,40007470271.27126312,00000000000000000a29a344dff0e0dc65f35279fd0dc659fb030ce0035612fb
320736,0000000000000000000137130c5a047157e7b0e063de6f3d30246a4f2005a818,2,e30836d40ad4e383b78d6696d6c0fb2e237b6e3f9047b534aab1b8376adac890,1410743549,20140915011229UTC,1553977946,1824dbe9,29829733124.04041672,00000000000000001140c9b2930258d81214055b1f0cb0c0c18f9c0d72cead3f
368831,000000000000000000015f96db0d6fa3933adc083d316de76684f3a536ce566e,3,89930f2e705635bc4e9087aa795c997efe10dc8f7341d32e24834167e2daf8f5,1438974822,20150807191342UTC,2888902138,18150815,52278304845.59168243,00000000000000000ef5c32d09d87c30d57f2d34d01ee6fe49be875f0e8f8750
315024,0000000000000000000181f37629e8b80debca2c295c350cb1bd156e7e1a25ee,2,735ce08304da3c77d7ab5103d697818b6353dd2a821bb533f8a747eb9c0ad50b,1407737115,20140811060515UTC,1546279659,1837ba62,19729645940.57713318,000000000000000027244c55854b585fa440ed33a19fff96d9b0d9ac18cccd09
340600,00000000000000000001a092bb0f2311bf00987a8f7d92e2ed6b36a522054741,2,47a68c3f00dfb15fba94e04a99dffb9884516c433a139c4eaeb7fba3aa65186d,1422308436,20150126224036UTC,1520544179,1819012f,43971662056.08957672,0000000000000000102fd0a2f64567685af772d5f085057726e77245ba8f26d7
324204,00000000000000000001bdebf80d8c40d9b30a6fe76b962ff59c8d3cdeec3473,2,0e8cb4d727fa3cbee0a0e65e85fb27fad5db44567268d431bfcddeb4a6fb7279,1412648799,20141007032639UTC,2449200073,181fb893,34661425923.97693634,0000000000000000145887c9c123eca9c13a08edc367c4fe8fbd3455c5bee0b7
353863,00000000000000000001e5b926f30e95405028c7a99039ca6d0d56fe4e6c3fcd,2,0b9c87aeb9d1b22a5f6ff2efb26f89a51bd5938bada7e6c3074e796280acb382,1430091539,20150426233859UTC,2166643748,181717f0,47610564513.47126007,000000000000000004d6eec7188cd404379de74c9de05e3c9bb1765ab483c14c
364761,00000000000000000001f1867bcc72256aecac8530538ffdb5b28b779ad44944,3,ced7dc1a2cb0bda14577efc13602ffc98774b45896a276338fc7827c13d11520,1436566421,20150710221341UTC,4201730147,1816418e,49402014931.22746277,00000000000000000829518a4b80ee009587426a410db462701e93330cfeec3b
367921,00000000000000000001f48148bfcacc557f9488058d566e5d71849290ebb65e,3,f272c6831096485bfa54cb6997c9ebd12c3fe2c07e5308c42fa2d2c666889f29,1438425344,20150801103544UTC,133307560,18150815,52278304845.59168243,000000000000000006df1c9d9b516c43e44edc8a3185ba462f8291ac70625853
343641,000000000000000000020fc1ca1268a27de8646059ae2bcca61d13d16890b5db,2,2d1e2553cb2873ca42ca84334bb8a1307eb917bb0db436c4deccbccf9efb70dd,1424040735,20150215235215UTC,2598231841,1818bb87,44455415962.34380341,00000000000000000c71cbf53cdd4230e5230521b684b7451a46013be383e3e9
326091,000000000000000000024b7dea2b63b4e2be64ef1663369fe2f22504587d094b,2,366b6716c17dc11589bad5b3c69b9ee65376ad3a2f09bc7778cafd840ff76a1e,1413763705,20141020010825UTC,4042894635,181f6973,35002482026.13323212,00000000000000000aaaf4dd84c4084f12d16786d3e47d98e2bffef39520ae36
361907,00000000000000000002621a6c0f2ff0be4d170cc21ffe25303a6b2a17be01ca,3,7669a340fbaea5118a79a0f846740d5850182a07e69d623ca6ed7ed31bd486b5,1434898913,20150621150153UTC,2047674194,18162043,49692386354.89383698,00000000000000000daa63279685c4e0c4f46154194745aaff511a663cc86f22
330140,000000000000000000026ccbc4bbb6a608e90132329190291127f971a604e5c9,2,3b01f647c4ff0bf86891d41cb46db89e71a1cd0bfdb9ba29f0689689d188a8eb,1416063608,20141115160008UTC,2907979742,181bc330,39603666252.41841125,0000000000000000058a2f5227d5535c60153b797ce67248964299f9daabc5c4
266381,000000000000000000028c32e6952731326747bae4be8db0f832d6eea0362050,2,d52cd4da83a38201f24b17d1b6c3cf74d18c5f8f27131d54362434e259b88a0a,1382885384,20131027154944UTC,2279206540,190afc85,390928787.63808584,00000000000000015cc813b33430babf69aadb24b6f527966c8209538d390487
349240,00000000000000000002a133e4691d2f8894a3af7a1b3624e8c2e8c7a8a4fe3c,2,77831799f8bb2eb9675796302e89bf158d058e1d07ca1bc382ad2ce82178eb6c,1427324002,20150325235322UTC,3714376115,181788f2,46717549644.70642090,0000000000000000052793d95d23d66dafaa5ca3d7aba31d6c3282765d5aedb2
357716,00000000000000000002c230842340d7955e15786b68fb16f8630b63e51c17ff,3,240e14294addf470bd0e995fda15035a9df73d46c659b76791b52241d76533b1,1432406721,20150523184521UTC,2564578027,181686f5,48807487244.68138123,00000000000000001609818f7b0a109b2f6f53b5b04be0baa91f6089ac09ea65
357289,00000000000000000003004b63171ac06ce6f8e67f5c203b93e3b67dfc953f65,2,3fd109b08ff9b3e69a4432ca84d84de12bfef2f3fb0aecc31b7c4b29c48f6ded,1432141803,20150520171003UTC,13232467,181686f5,48807487244.68138123,0000000000000000131e2c37a475e6c97e77e628363fc956af9ebda83d7f1658
330727,00000000000000000003107221e16ef91fdf83b3729c5f370dafb754bf6443b2,2,9edb646b5611eb92aac396add2f4d88581499a96319717cf9436d00ca287b7b9,1416413591,20141119171311UTC,3886406479,181b4861,40300030327.89140320,0000000000000000173e5c50f8c5ba633a7f32ae15fe29e343acae4ac7df4f2a
369067,00000000000000000003120d4ebe3f05623607a87339b98b66970b3825a14c9f,3,d68659b7bcea6c9839cf4e26d0af6e232840011f75d4cc57c305af842f5740df,1439110756,20150809085916UTC,655651400,1814dd04,52699842409.34700775,0000000000000000101238807f0a2755eb371052dffe02074f21ad9bd26fb9c9
356840,000000000000000000034689570e541599293d08851f9eb00941d9112439cf6f,2,4dc4f971b97f8372693cb9714afb4f39c6ba41d803efa5aae9c9255824d6a18f,1431862378,20150517113258UTC,1760314433,181686f5,48807487244.68138123,00000000000000000b2db372069c8b586a4fc9ee6ba7b4ca17c65a4c2c28f463
366432,000000000000000000035646f09e9e9637d7611254a2506765ecfb324c5a5ba8,3,41d9fb7f97a329419edf50b5efc43a088100004c5e09df58af1c9828756d585b,1437561929,20150722104529UTC,322633431,181586c8,51076366303.48192596,000000000000000012d54a1834be3497eb5f314408d4b8287b3ccff81701f5d0
336920,00000000000000000003565c1c978f85944e222d6e9e65ed57488e34deed8774,2,a66c7ff9cede074b592a3e6f235641df73e27bf36fa542492530ed7b7b7e1781,1420100382,20150101091942UTC,117040972,181b0dca,40640955016.57649231,00000000000000000e74924a279c8090f5fc61dd023487861bfb2459a14d6f32
316203,000000000000000000037be5d0bf7a0d03db565b07f512dab5d8cda0348bbbed,2,860cac4cc458383cb3812e36839deb175d91c196226b441c257c07474bd13296,1408342281,20140818061121UTC,1514325168,1837ba62,19729645940.57713318,000000000000000016754abc5ae5fa93ffdf3c3e5787678784f7dbd60a6fada4
361221,000000000000000000038ae8d3027b466a0cac99f9244eae9a55e8194838bfc2,3,11a4f3f3ccbbf4e139fea010db8fa56cb0b65e4500a37ae0e9deffa0a45725d8,1434488383,20150616205943UTC,2096808613,18162043,49692386354.89383698,000000000000000010a82cf40399c43f0f8158c03adcdf45470eb7dee9e7098f
360158,00000000000000000003bf3e85ccdbf1d678e0d66c6bd3c7a166cd08d3cd3898,2,abf46fae59991465a8527e6d356c057c153e61feb086006e3e8c2d6cd2d71a46,1433861114,20150609144514UTC,473787162,18171a8b,47589591153.62500763,000000000000000002cbf1aac3f94f1133910cb80cdbce4d14cd825489c18958

(which is just sort -t, -k2 blocks.all | head -42)
File is currently 99,500,103 bytes up to block 370068

282 block hashes contain beef

[teukon]

Block 331816, in those terms, was the luckiest; clocking in 'just barely' under the target:

00000000000000001b48610000000395e67ff70a0effd0718099cc0000000000 : target
00000000000000001b48534ff39bc165477e3b5459b05679bdcf8ce2a3927fe7 : hash

Actually, the above may not be very precise due to potential conversion issues and big number handling.  The next four contenders are blocks 270605, 50249, 128228 and 316072

Just an FYI: the "bits" parameter of block 331816 is 0x181b4861.  This value represents the true target and unpacks as

	0x0.1b4861 * 0x1000x18
=	0x1b4861 * 0x1042
=	0x1b4861000000000000000000000000000000000000000000

[teukon]

I keep a dump of the full chain (with a script that simply adds to it by calling bitcoin-cli with one addition, the timestamp converted)

Very cool!

I'd be curious to see grep '000000UTC' blocks.all myself.

[kano]

I keep a dump of the full chain (with a script that simply adds to it by calling bitcoin-cli with one addition, the timestamp converted)

Very cool!

I'd be curious to see grep '000000UTC' blocks.all myself.

Well yeah but there is of course the issue that the block timestamp is far from accurate.
It's simply the timestamp put in the header before hashing it, it doesn't need to be very accurate and can be 7200 seconds (2hrs) ahead in time.
There's 8

Code:

21757,00000000901764e2469aa8e34ccf3688ece4a43f75a6ef876f114c9ebcae6cbb,1,c1f8478a7e46e03b7326e0d55ad6848a7fb1cd8819134d52b88ebaa0752e99e6,1251590400,20090830000000UTC,3593416220,1d00ffff,1.00000000,00000000454e4447e1b3227b6573b610bedb3ae690b7e7862d6b971e4cf51ee5
34274,00000000296e482f492c06e598f35ce9f351f0d1e00220205f11ca932a1b3f8a,1,c1b9332164aed8bb1f9e029463523735c1da10f8548faa13cf6a22810091b17f,1263250800,20100112000000UTC,74552828,1d00c428,1.30506213,0000000013fad98598accf6d68c234b8fb22ab05ae24fb98b043dbd25dc84a6f
84461,0000000000254cb84cbb8ca4b1a2c6f4d15a01af80ccfa9ba243c06a8aba5a46,1,bc6b5309eb0ddf78cf92a6c9d1f93e76b9ed497aa353d3efad41704a8db210c1,1286751600,20101011000000UTC,496010461,1b31b2a3,1318.67005015,0000000000060af2631eb2dc238985d1f8e27279d75a5bfa123febb0f478719e
117090,000000000000a27b8d06b7353e6c1d7f8b0e01449e85cbd4bda93645c6e154f2,1,a7347ce38d6b67ef5459418113af220cb26cb188f366e2d6c9f88ebeb7797057,1302134400,20110407000000UTC,1465509707,1b00cbbd,82345.64411297,000000000000b836fe0c1fcbdaa0229d0608ca7ec9f098871792357b839357c5
160030,0000000000000d575be2b8874bf9ce10c382669a1827ff2e88fae0598eabeba8,1,5b7ca99a397fef3db62397281092b6e444bb0d6fa46c2dfa88534bac7e1a8189,1325372400,20120101000000UTC,2793405837,1a0e76ba,1159929.49722438,0000000000000942122ac20248851ec357b546c4a340eb67392b74202537a299
300936,000000000000000063d5423cadcbdaf25d0e56f2aef3714eb1d55b144f048931,2,56c304bfae885495c28ff7d51249981fca687e8468164c47ffcf1af8b853d584,1400198400,20140516000000UTC,3629228942,187c3053,8853416309.12779999,000000000000000046ca098391e34775ecda24933f56ee1c858e635e2bf12589
321935,00000000000000001533f171b7c1c5d41d734e8ce4c6bce03dfbff6a41c5d862,2,47ee20dd270997423715df7f00daf6f916681964c1c8fb798c2dd03a06dca5f2,1411344000,20140922000000UTC,189477608,1824dbe9,29829733124.04041672,000000000000000017438c1afdbf096d3b763d7f0368407567377d4eec7de7c6
367561,00000000000000000339efa2d9e1c8b7518019b441ba3ad7fbcfbbcd90ff2229,3,798f9f4e4cbd0ffaf7ef26b5e33a526bed0753a44784f350652e3d2406461970,1438214400,20150730000000UTC,634368344,18150815,52278304845.59168243,00000000000000000aa65b2ca4f6a982b5502c86c178cb5b44b0057b0c64e356

[TheRealSteve]

Just an FYI: the "bits" parameter of block 331816 is 0x181b4861.  This value represents the true target and unpacks as

Yeah, I didn't grab nbits so had to make do on the data I had - maybe I'll revisit it, maybe not

282 block hashes contain beef

Tasty

[teukon]

I keep a dump of the full chain (with a script that simply adds to it by calling bitcoin-cli with one addition, the timestamp converted)

Very cool!

I'd be curious to see grep '000000UTC' blocks.all myself.

Well yeah but there is of course the issue that the block timestamp is far from accurate.
It's simply the timestamp put in the header before hashing it, it doesn't need to be very accurate and can be 7200 seconds (2hrs) ahead in time.

Yes, I'm well aware.

There's 8

Code:

21757,00000000901764e2469aa8e34ccf3688ece4a43f75a6ef876f114c9ebcae6cbb,1,c1f8478a7e46e03b7326e0d55ad6848a7fb1cd8819134d52b88ebaa0752e99e6,1251590400,20090830000000UTC,3593416220,1d00ffff,1.00000000,00000000454e4447e1b3227b6573b610bedb3ae690b7e7862d6b971e4cf51ee5
34274,00000000296e482f492c06e598f35ce9f351f0d1e00220205f11ca932a1b3f8a,1,c1b9332164aed8bb1f9e029463523735c1da10f8548faa13cf6a22810091b17f,1263250800,20100112000000UTC,74552828,1d00c428,1.30506213,0000000013fad98598accf6d68c234b8fb22ab05ae24fb98b043dbd25dc84a6f
84461,0000000000254cb84cbb8ca4b1a2c6f4d15a01af80ccfa9ba243c06a8aba5a46,1,bc6b5309eb0ddf78cf92a6c9d1f93e76b9ed497aa353d3efad41704a8db210c1,1286751600,20101011000000UTC,496010461,1b31b2a3,1318.67005015,0000000000060af2631eb2dc238985d1f8e27279d75a5bfa123febb0f478719e
117090,000000000000a27b8d06b7353e6c1d7f8b0e01449e85cbd4bda93645c6e154f2,1,a7347ce38d6b67ef5459418113af220cb26cb188f366e2d6c9f88ebeb7797057,1302134400,20110407000000UTC,1465509707,1b00cbbd,82345.64411297,000000000000b836fe0c1fcbdaa0229d0608ca7ec9f098871792357b839357c5
160030,0000000000000d575be2b8874bf9ce10c382669a1827ff2e88fae0598eabeba8,1,5b7ca99a397fef3db62397281092b6e444bb0d6fa46c2dfa88534bac7e1a8189,1325372400,20120101000000UTC,2793405837,1a0e76ba,1159929.49722438,0000000000000942122ac20248851ec357b546c4a340eb67392b74202537a299
300936,000000000000000063d5423cadcbdaf25d0e56f2aef3714eb1d55b144f048931,2,56c304bfae885495c28ff7d51249981fca687e8468164c47ffcf1af8b853d584,1400198400,20140516000000UTC,3629228942,187c3053,8853416309.12779999,000000000000000046ca098391e34775ecda24933f56ee1c858e635e2bf12589
321935,00000000000000001533f171b7c1c5d41d734e8ce4c6bce03dfbff6a41c5d862,2,47ee20dd270997423715df7f00daf6f916681964c1c8fb798c2dd03a06dca5f2,1411344000,20140922000000UTC,189477608,1824dbe9,29829733124.04041672,000000000000000017438c1afdbf096d3b763d7f0368407567377d4eec7de7c6
367561,00000000000000000339efa2d9e1c8b7518019b441ba3ad7fbcfbbcd90ff2229,3,798f9f4e4cbd0ffaf7ef26b5e33a526bed0753a44784f350652e3d2406461970,1438214400,20150730000000UTC,634368344,18150815,52278304845.59168243,00000000000000000aa65b2ca4f6a982b5502c86c178cb5b44b0057b0c64e356

Thank you.

[teukon]

Just an FYI: the "bits" parameter of block 331816 is 0x181b4861.  This value represents the true target and unpacks as

Yeah, I didn't grab nbits so had to make do on the data I had - maybe I'll revisit it, maybe not

I see.  No worries.

282 block hashes contain beef

Tasty

Perhaps we'll see "decade" within Bitcoin's first 10 years.

[TheRealSteve]

Perhaps we'll see "decade" within Bitcoin's first 10 years.

We have
205218 = 00000000000000b30977ce4980488decade02ace9627955e61f245f845970622

[fronti]

glad, coffee is also included in the Blockchain:
170852 00000000000002b58bf498d718db69dfc25cb318036949d3dad6bc0ffee28744
132928 00000000000011eec4defc0ffee303401e460d2b8406474692d0ff141b9cbbf4

[TheRealSteve]

[ quoted content removed - was fixed ]
There's even more 'decaf', though I don't think any decaf.*c0ffee yet.  Not even a c0ca.*c01a

[fronti]

glad, coffee is also included in the Blockchain:
170853 00000000000002b58bf498d718db69dfc25cb318036949d3dad6bc0ffee28744
132929 00000000000011eec4defc0ffee303401e460d2b8406474692d0ff141b9cbbf4

I think your block indices are off-by-one?
There's even more 'decaf', though I don't think any decaf.*c0ffee yet.  Not even a c0ca.*c01a

i noticed already and fixed it
thanks for pointing out

[teukon]

Perhaps we'll see "decade" within Bitcoin's first 10 years.

We have
205218 = 00000000000000b30977ce4980488decade02ace9627955e61f245f845970622

Ha!  Very nice.  I imagine this is the only instance.

[znort987]

368528 = 00000000000000000000013712632da34788a7b4ae2cd78f7982c7036610126b

[David Rabahy]

368528 = 00000000000000000000013712632da34788a7b4ae2cd78f7982c7036610126b

Off by one?  https://blockchain.info/block-height/368527

[David Rabahy]

368528 = 00000000000000000000013712632da34788a7b4ae2cd78f7982c7036610126b

Previously reported https://bitcointalk.org/index.php?topic=29675.msg12152791#msg12152791

[keystroke]

Any updates?

[arubi]

458091 = 00000000000000000000011246f099d94f91628d71c9d75ad2f9a06e2beb7e92

[PolinaVodovatova]

The nonce is only 32 bits; could there come a day with the difficulty is high enough that no nonce works?

[David Rabahy]

32 bits isn't even close to enough today.  The extra nonce is absolutely required.