Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from <etotheipi@gmail.com>) id 1RTEqS-0000K3-Uy for bitcoin-development@lists.sourceforge.net; Wed, 23 Nov 2011 15:34:44 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.212.47 as permitted sender) client-ip=209.85.212.47; envelope-from=etotheipi@gmail.com; helo=mail-vw0-f47.google.com; Received: from mail-vw0-f47.google.com ([209.85.212.47]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1RTEqO-0007LR-W9 for bitcoin-development@lists.sourceforge.net; Wed, 23 Nov 2011 15:34:44 +0000 Received: by vbbfc21 with SMTP id fc21so258282vbb.34 for <bitcoin-development@lists.sourceforge.net>; Wed, 23 Nov 2011 07:34:35 -0800 (PST) Received: by 10.52.36.41 with SMTP id n9mr26008791vdj.41.1322062475525; Wed, 23 Nov 2011 07:34:35 -0800 (PST) Received: from [192.168.1.85] (c-76-111-108-35.hsd1.md.comcast.net. [76.111.108.35]) by mx.google.com with ESMTPS id a2sm18787231vdj.3.2011.11.23.07.34.34 (version=SSLv3 cipher=OTHER); Wed, 23 Nov 2011 07:34:34 -0800 (PST) Message-ID: <4ECD12AA.6080605@gmail.com> Date: Wed, 23 Nov 2011 10:35:06 -0500 From: Alan Reiner <etotheipi@gmail.com> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: bitcoin-development@lists.sourceforge.net References: <201111231035.48690.andyparkins@gmail.com> <CAGQP0AEZ9CUNd9ERyMsx741bqjLptY4pPRU6EmxQcD7kR8bdbw@mail.gmail.com> <CALxbBHVEvCqun0aX_9awGhW39h5cx0jLPx2ptoesBcmKGO-_Dw@mail.gmail.com> <201111231313.12534.andyparkins@gmail.com> <CALxbBHW2KGv=sEvYqpGGsy8jjJ3+yE02BegwPhjGapuT9z7v_Q@mail.gmail.com> <CABsx9T0VH5i0HrEjxfxxtzO2MtmN7UEyAUXoq9puc-1nKw3G4Q@mail.gmail.com> In-Reply-To: <CABsx9T0VH5i0HrEjxfxxtzO2MtmN7UEyAUXoq9puc-1nKw3G4Q@mail.gmail.com> Content-Type: multipart/alternative; boundary="------------020304080106000507000405" X-Spam-Score: -0.8 (/) 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 (etotheipi[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -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 -0.2 AWL AWL: From: address is in the auto white-list X-Headers-End: 1RTEqO-0007LR-W9 Subject: Re: [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 15:34:45 -0000 This is a multi-part message in MIME format. --------------020304080106000507000405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I can substantiate Gavin's point quite powerfully: a couple months ago I did a search for the "hardest" block in the network and found a *very **impressive* one: https://bitcointalk.org/index.php?topic=29675.0 That block has a difficulty of **36 billion** when the network had a difficulty of **1.5 million**, which is 24,000 times harder than the target. If we were going by the /actual /hardest chain instead target-based-hardest chain, /then this block produced in July would might still represent the longest chain!/ Yes, that means that whichever miner produced this block, could've held onto it for 2-4 months without doing anything else, and then broadcast it to fork the blockchain from a block produced months ago. That's not theoretical, that's real data in the blockchain and it would be a disaster. -Alan On 11/23/2011 10:09 AM, Gavin Andresen wrote: > On Wed, Nov 23, 2011 at 9:38 AM, Christian Decker > <decker.christian@gmail.com> wrote: >> At some point you might find an incredibly hard block that makes your forked >> chain the hardest one in the network > Seems to me that's the real problem with any "hardest block found in X > minutes" scheme. > > If I get lucky and find a really extremely hard block then I have an > incentive to keep it secret and build a couple more blocks on top of > it, then announce them all at the same time. > > If the rest of the network rejects my longer chain because I didn't > announce the extremely hard block in a timely fashion... then how > could the network ever recover from a real network split? A network > split/rejoin will look exactly the same. > > Bitcoin as-is doesn't have the "I got lucky and found an extremely > hard block" problem because the difficulty TARGET is used to compute > chain difficulty, not the actual hashes found. > > > --- > > PS: I proposed a different method for dealing with large hash power > drops for the testnet on the Forums yesterday, and am testing it > today. > --------------020304080106000507000405 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> I can substantiate Gavin's point quite powerfully: a couple months ago I did a search for the "hardest" block in the network and found a <b>very </b><b>impressive</b> one:<br> <br> <a href="https://bitcointalk.org/index.php?topic=29675.0">https://bitcointalk.org/index.php?topic=29675.0</a><br> <br> That block has a difficulty of <b>*36 billion</b>* when the network had a difficulty of *<b>1.5 million</b>*, which is 24,000 times harder than the target. If we were going by the <i>actual </i>hardest chain instead target-based-hardest chain, <i>then this block produced in July would might still represent the longest chain!</i> <br> <br> Yes, that means that whichever miner produced this block, could've held onto it for 2-4 months without doing anything else, and then broadcast it to fork the blockchain from a block produced months ago. That's not theoretical, that's real data in the blockchain and it would be a disaster.<br> <br> -Alan<br> <br> <br> <br> On 11/23/2011 10:09 AM, Gavin Andresen wrote: <blockquote cite="mid:CABsx9T0VH5i0HrEjxfxxtzO2MtmN7UEyAUXoq9puc-1nKw3G4Q@mail.gmail.com" type="cite"> <pre wrap="">On Wed, Nov 23, 2011 at 9:38 AM, Christian Decker <a class="moz-txt-link-rfc2396E" href="mailto:decker.christian@gmail.com"><decker.christian@gmail.com></a> wrote: </pre> <blockquote type="cite"> <pre wrap="">At some point you might find an incredibly hard block that makes your forked chain the hardest one in the network </pre> </blockquote> <pre wrap=""> Seems to me that's the real problem with any "hardest block found in X minutes" scheme. If I get lucky and find a really extremely hard block then I have an incentive to keep it secret and build a couple more blocks on top of it, then announce them all at the same time. If the rest of the network rejects my longer chain because I didn't announce the extremely hard block in a timely fashion... then how could the network ever recover from a real network split? A network split/rejoin will look exactly the same. Bitcoin as-is doesn't have the "I got lucky and found an extremely hard block" problem because the difficulty TARGET is used to compute chain difficulty, not the actual hashes found. --- PS: I proposed a different method for dealing with large hash power drops for the testnet on the Forums yesterday, and am testing it today. </pre> </blockquote> <br> </body> </html> --------------020304080106000507000405--