From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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--