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 --]
next prev 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 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$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=decker.christian@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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