[Bitcoin-development] Addressing rapid changes in mining power

Alan Reiner etotheipi at gmail.com
Wed Nov 23 15:35:06 UTC 2011

I can substantiate Gavin's point quite powerfully: a couple months ago I 
did a search for the "hardest" block in the network and found a *very 
**impressive* one:


That block has a difficulty of **36 billion** when the network had a 
difficulty of **1.5 million**, which is 24,000 times harder than the 
target.  If we were going by the /actual /hardest chain instead 
target-based-hardest chain, /then this block produced in July would 
might still represent the longest chain!/

Yes, that means that whichever miner produced this block, could've held 
onto it for 2-4 months without doing anything else, and then broadcast 
it to fork the blockchain from a block produced months ago.  That's not 
theoretical, that's real data in the blockchain and it would be a disaster.


On 11/23/2011 10:09 AM, Gavin Andresen wrote:
> On Wed, Nov 23, 2011 at 9:38 AM, Christian Decker
> <decker.christian at gmail.com>  wrote:
>> At some point you might find an incredibly hard block that makes your forked
>> chain the hardest one in the network
> Seems to me that's the real problem with any "hardest block found in X
> minutes" scheme.
> If I get lucky and find a really extremely hard block then I have an
> incentive to keep it secret and build a couple more blocks on top of
> it, then announce them all at the same time.
> If the rest of the network rejects my longer chain because I didn't
> announce the extremely hard block in a timely fashion... then how
> could the network ever recover from a real network split?  A network
> split/rejoin will look exactly the same.
> Bitcoin as-is doesn't have the "I got lucky and found an extremely
> hard block" problem because the difficulty TARGET is used to compute
> chain difficulty, not the actual hashes found.
> ---
> PS: I proposed a different method for dealing with large hash power
> drops for the testnet on the Forums yesterday, and am testing it
> today.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111123/c80449ce/attachment.html>

More information about the bitcoin-dev mailing list