Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <andyparkins@gmail.com>) id 1RTABM-0004W1-NZ
	for bitcoin-development@lists.sourceforge.net;
	Wed, 23 Nov 2011 10:36:00 +0000
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; 
Received: from mail-ww0-f53.google.com ([74.125.82.53])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1RTABL-00056V-Tb
	for bitcoin-development@lists.sourceforge.net;
	Wed, 23 Nov 2011 10:36:00 +0000
Received: by wwf27 with SMTP id 27so1860064wwf.10
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 23 Nov 2011 02:35:51 -0800 (PST)
Received: by 10.216.134.209 with SMTP id s59mr4028130wei.62.1322044551526;
	Wed, 23 Nov 2011 02:35:51 -0800 (PST)
Received: from dvr.localnet (mail.360visiontechnology.com. [92.42.121.178])
	by mx.google.com with ESMTPS id co5sm8014859wib.8.2011.11.23.02.35.49
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 23 Nov 2011 02:35:50 -0800 (PST)
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>
X-Spam-Score: -1.6 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(andyparkins[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1RTABL-00056V-Tb
Subject: [Bitcoin-development] Addressing rapid changes in mining power
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Wed, 23 Nov 2011 10:36:00 -0000

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