Re: [Bitcoin-development] Addressing rapid changes in mining power

[Andy Parkins <andyparkins@gmail.com>]

[-- Attachment #1: Type: Text/Plain, Size: 1998 bytes --]

On 2011 November 23 Wednesday, Christian Decker wrote:
> Just brainstorming here, no idea if this would work:
> 
>    - Pick any old block
>    - Create a chain fork by creating simpler blocks on top of your chosen
>    one
>    - The chain will not be accepted by others
>    - At some point you might find an incredibly hard block that makes your
>    forked chain the hardest one in the network
>    - Suddenly all your blocks are valid and you force people to switch to
>    your forked chain
> 
> If this is possible it would allow you to revoke all transactions and claim
> all the mined coins since you forked. My point is that the notion of
> hardest chain is not so simple.

The above is a problem in either system (mine or current).  If I can make a 
"hardest chain", then I have indeed reverted all the existing transactions. 

Look at CBlock::AddToBlockIndex(), 

    if (pindexNew->bnChainWork > bnBestChainWork)
        if (!SetBestChain(txdb, pindexNew))
            return false;

If the received block has higher total chain work than the current best chain 
work; then the new block becomes the head of the best chain.  The chain work 
being calculated like this (I've abbreviated for the email):

  pindexNew->bnChainWork = pprev->bnChainWork + pindexNew->GetBlockWork()

I'm not entirely convinced that this method of totalling chain work is the 
best (it's a sum of exponentials I think); but that's a different issue.

> The difficulty of invalidating a chain is dramatically reduced with your
> time window approach, by not requiring a given difficulty, and relying on
> synchronized time windows.

I don't see that it is reduced; it is the same.  Hashes are hashes.  A given 
difficulty isn't required, but a higher difficulty beats a lower difficulty.  
So whatever the hashing power of the network at that moment, it's used.  That 
makes the chain more secure, not less.



Andy

-- 
Dr Andy Parkins
andyparkins@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]