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

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

Hello,

One problem with Bitcoin is that if large numbers of miners suddenly switch 
off, the network takes a long time to adapt (since the adaption time is a 
function of blocks generated, and the block generation rate has changed).  The 
same problem exists in the other direction, but an increased generation rate 
for a little while doesn't really do any harm.

I had this idea as a way of completely normalising the block generation rate, 
regardless of network power.  I hesitate to offer it, as I get shouted down a 
lot, but what the hell...

Let's imagine that the whole network shares a clock (which it does already).  
Let's abandon the idea of a target difficulty.  Instead, every node just 
generates the most difficulty block it can.  Simultaneously, every node is 
listening for "the most difficult block generated before time T"; with T being 
picked to be the block generation rate (10 minutes).

Every node is therefore generating blocks and comparing not against some 
moving average determined target, but rather against the most difficult 
recently received block.  If the generated block is harder than the received 
block, then it gets broadcast.

Clearly, early on in the block, the traffic would be high, but that could be 
limited with a bit of intelligence -- there's no point broadcasting your best 
blocks in minute 0 of the current block... you know everyone will beat it, as 
it was so easy.  So the rule would be broadcasts only start at T/2 plus a 
little randomisation.  There wouldn't be that many because someone will have 
generated a pretty good block by chance in the first half, and that will 
quickly stop anybody else from bothering to broadcast their easier block.  
There is no advantage to broadcasting a lesser block, so there is no incentive 
to cheat.

As always: the most difficult chain wins; and blocks with out-of-bounds times 
are rejected regardless of difficulty.  Everyone therefore has an incentive to 
base their next block on the block with highest difficulty from the previous 
period.

The block period is now guaranteed to be 10 minutes (or in fact, whatever 
period you like, there is no danger at all in changing it to 2 minutes); and 
there is no change of block generation rate with network power.  Changes in 
network power merely adjust the average difficulty of the best block per 
period.  The cost is higher network traffic, because there are block 
broadcasts that don't necessarily make it to the end.  However, there's no 
need to broadcast the full block, only the header.  If that block turns out to 
be the winner, then the other nodes will request the full block at the end of 
the period, and will check it's valid.  If it's not then the next highest on 
the list will be requested.  So again, 

I recognise that this is a pretty large change to make; and so don't really 
expect it to happen.  Perhaps one day though... when all the wishlist items go 
into one huge protocol overhaul.



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 10:36 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-23 10:35 Andy Parkins [this message]
2011-11-23 11:25 ` [Bitcoin-development] Addressing rapid changes in mining power 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
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=201111231035.48690.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