public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Andy Parkins <andyparkins@gmail.com>
To: Christian Decker <decker.christian@gmail.com>
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Addressing rapid changes in mining power
Date: Wed, 23 Nov 2011 15:11:07 +0000	[thread overview]
Message-ID: <201111231511.14980.andyparkins@gmail.com> (raw)
In-Reply-To: <CALxbBHW2KGv=sEvYqpGGsy8jjJ3+yE02BegwPhjGapuT9z7v_Q@mail.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 --]

  parent reply	other threads:[~2011-11-23 15:11 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-23 10:35 [Bitcoin-development] Addressing rapid changes in mining power Andy Parkins
2011-11-23 11:25 ` Jorge Timón
2011-11-23 11:30   ` Andy Parkins
2011-11-23 11:51     ` Jorge Timón
2011-11-23 12:10       ` Christian Decker
2011-11-23 13:13         ` Andy Parkins
2011-11-23 14:38           ` Christian Decker
2011-11-23 15:09             ` Gavin Andresen
2011-11-23 15:35               ` Alan Reiner
2011-11-23 15:39               ` Andy Parkins
2011-11-23 16:26                 ` Joel Joonatan Kaartinen
2011-11-23 15:11             ` Andy Parkins [this message]
2011-11-23 12:54       ` Andy Parkins
2011-11-23 15:10         ` Jorge Timón
2011-11-23 15:29           ` Andy Parkins
2011-11-23 15:38             ` Jorge Timón

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201111231511.14980.andyparkins@gmail.com \
    --to=andyparkins@gmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=decker.christian@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox