For fun: the lowest block hash yet

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

[1715261724]

1715261724

[1715261724]

1715261724

[1715261724]

1715261724

[1715261724]

1715261724

[1715261724]

1715261724

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