From: Christian Decker <decker.christian@gmail•com>
To: Andy Parkins <andyparkins@gmail•com>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Addressing rapid changes in mining power
Date: Wed, 23 Nov 2011 15:38:55 +0100 [thread overview]
Message-ID: <CALxbBHW2KGv=sEvYqpGGsy8jjJ3+yE02BegwPhjGapuT9z7v_Q@mail.gmail.com> (raw)
In-Reply-To: <201111231313.12534.andyparkins@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4700 bytes --]
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 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.
Regards,
Chris
On Wed, Nov 23, 2011 at 2:13 PM, Andy Parkins <andyparkins@gmail•com> wrote:
> On 2011 November 23 Wednesday, Christian Decker wrote:
>
> > The current block generation with a fixed difficulty was chosen because
> it
> > it clear when to adjust and to what target difficulty it has to be
> > adjusted. If we were to use synchronized time windows and select the
> > hardest block it gets incredibly complicated as synchronization is not
> > possible in distributed systems. Even the smallest drift would allow for
> > forks in the chain all over the place. Furthermore the delay in
> propagation
> > will also cause forks.
> >
> > If 1/2 of the network see one block as the hardest, and for the rest of
> the
> > network it came too late then we'll have a fork that stays with us quite
> a
> > while.
> >
> > The block chain is described as a timestamp server in the paper, but it
> is
> > more of a proof-of-existence before, as the contained timestamp cannot be
> > trusted anyway.
>
> These are reasonable objections. My counter is this:
>
> Let's view block difficulty as a measure of time, not time itself. The
> timestamp is merely a convenience for the block. You cannot fake the
> computing power needed for a particular difficulty; so the hardest chain
> always wins (note: hardest chain).
>
> If I am a miner, I have two choices:
>
> (a) try to replace the top block on the current hardest chain
> (b) try to append to the current hardest chain
>
> Either of these is acceptable; but in case (a) I have to generate a more
> difficult block to replace it; in case (b), at the start of the window, any
> difficulty is acceptable (however, I'm competing with other miners, so
> _any_
> difficulty won't beat them).
>
> The rule then is that you're trying to win the one block reward that is
> available every 10 minutes; and your peers will be rejecting blocks with
> timestamps that are lies.
>
> Perhaps an example...
>
> - I (a node), download the blockchain
> - The blockchain has N potential heads. Each of those heads has a time, t
> and a sum_of_difficulty.
> - The next block reward is going to go to the highest difficulty with
> t < timestamp < (t + T) _and_ verified timestamp (i.e. not received more
> than, say 5 minutes, from its claimed timestamp).
> - I can choose any head to start generating from, but given that it's the
> highest difficulty chain that's going to win the next reward (not the
> highest difficulty block), I will surely pick the most difficult?
> - A rogue miner then issues a block with a fake timestamp; it actually
> generated at (t + T + 5) but claims (t + 5). Should I start using
> that block as my new head? Obviously not, because my peers might decide
> that it is a lie and reject it because it was received too late, making
> my
> work useless. It is in my interest to pick a head that is honest.
>
> Resolving forks is easy:
>
> - 50 coins every ten minutes only
> - most difficult chain wins
>
> I'm certainly not saying it's a simple change. There are certainly areas I
> haven't thought about, and could be game-overs; but I do like the idea of
> there being no target difficulty, and instead the blocks are issued at a
> fixed
> ten minute rate (or rather the rewards are).
>
>
> Andy
>
> --
> Dr Andy Parkins
> andyparkins@gmail•com
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
[-- Attachment #2: Type: text/html, Size: 5660 bytes --]
next prev parent reply other threads:[~2011-11-23 14:39 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 [this message]
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
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='CALxbBHW2KGv=sEvYqpGGsy8jjJ3+yE02BegwPhjGapuT9z7v_Q@mail.gmail.com' \
--to=decker.christian@gmail$(echo .)com \
--cc=andyparkins@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/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