Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.82.53 as permitted sender)
	client-ip=74.125.82.53; envelope-from=andyparkins@gmail.com;
	helo=mail-ww0-f53.google.com; 
From: Andy Parkins <andyparkins@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Date: Wed, 23 Nov 2011 10:35:42 +0000
User-Agent: KMail/1.13.6 (Linux/3.0.0-1-686-pae; KDE/4.6.3; i686; ; )
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1819154.H5s9Egm0ks";
	protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <201111231035.48690.andyparkins@gmail.com>
Subject: [Bitcoin-development] Addressing rapid changes in mining power
Precedence: list

--nextPart1819154.H5s9Egm0ks
Content-Type: Text/Plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello,

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

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

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

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

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

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

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

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



Andy
=2D-=20
Dr Andy Parkins
andyparkins@gmail.com

--nextPart1819154.H5s9Egm0ks
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEABECAAYFAk7MzH8ACgkQwQJ9gE9xL234zgCg2Ccrm8EjKqKZ2awfa0p8SZ0x
vrEAni5jRq1RMnu1VT8E77gTd9ZBK62C
=w6Wf
-----END PGP SIGNATURE-----

--nextPart1819154.H5s9Egm0ks--