public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Andy Parkins <andyparkins@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Addressing rapid changes in mining power
Date: Wed, 23 Nov 2011 13:13:12 +0000	[thread overview]
Message-ID: <201111231313.12534.andyparkins@gmail.com> (raw)
In-Reply-To: <CALxbBHVEvCqun0aX_9awGhW39h5cx0jLPx2ptoesBcmKGO-_Dw@mail.gmail.com>

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

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

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

  reply	other threads:[~2011-11-23 13:13 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 [this message]
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
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=201111231313.12534.andyparkins@gmail.com \
    --to=andyparkins@gmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    /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