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 --]
next 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