diff options
| author | Gavin Andresen <gavinandresen@gmail.com> | 2016-02-07 12:09:46 -0500 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2016-02-07 17:09:51 +0000 |
| commit | 6bf22574ddb0a07d6ed9e1efb059d5bffe52866d (patch) | |
| tree | 974bffc53bf18b68d33860cc389de54733d29f8e | |
| parent | c59384cb97e49237516ebdf3f8bdb05504c5947c (diff) | |
| download | pi-bitcoindev-6bf22574ddb0a07d6ed9e1efb059d5bffe52866d.tar.gz pi-bitcoindev-6bf22574ddb0a07d6ed9e1efb059d5bffe52866d.zip | |
Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes
| -rw-r--r-- | 55/392dbe91866cdb18d183aa5a3dc3caf0e258b8 | 163 |
1 files changed, 163 insertions, 0 deletions
diff --git a/55/392dbe91866cdb18d183aa5a3dc3caf0e258b8 b/55/392dbe91866cdb18d183aa5a3dc3caf0e258b8 new file mode 100644 index 000000000..a20eda7a9 --- /dev/null +++ b/55/392dbe91866cdb18d183aa5a3dc3caf0e258b8 @@ -0,0 +1,163 @@ +Return-Path: <gavinandresen@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 44A1B1001 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 7 Feb 2016 17:09:51 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-lf0-f43.google.com (mail-lf0-f43.google.com + [209.85.215.43]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9ECE72F + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 7 Feb 2016 17:09:48 +0000 (UTC) +Received: by mail-lf0-f43.google.com with SMTP id 78so83266406lfy.3 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 07 Feb 2016 09:09:48 -0800 (PST) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; + h=mime-version:in-reply-to:references:date:message-id:subject:from:to + :content-type; bh=KYdiV/c2SJdrJe0YNTAVNbw/9Pzq09puJ/abbBWEu9c=; + b=r4WQlgTXLxqub0gc8bXyZ1vS4GDxX/qWGc4uSSiJ7CVejDS5nZwTzng3k9YRjvj/TZ + 2pyLH8msqaBIBct+2/q417Jl9OJNqn/YcP/fdhR7Id7RWemnJs++1IrC6L3MNpo3BbYw + n1A0Cp0CX8A9Bwq5X5BRodnlgco8F94LTWLIsw1mct7YWg4q4PkLaqS5twF8dCkCJIus + hbnTsZqpYQAVTWUBOPWYsSgW6mx1wZwUCVwVgxh7/EDeMp6HJm+6X47x6T1irtBuyWJY + 9+io7EFid4nWe9GP5/Dj+HjBBoDovtVgFy84L+0SoqnlzyO8scAMmKew+pvC+85j8zSy + 3L9w== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20130820; + h=x-gm-message-state:mime-version:in-reply-to:references:date + :message-id:subject:from:to:content-type; + bh=KYdiV/c2SJdrJe0YNTAVNbw/9Pzq09puJ/abbBWEu9c=; + b=Wgxf5hiVwjCuQ8qLvdp9VNoI2FdBIHKV3fIaQbC4SVpuDc+skhOyxmjU1K2r+B+W3Q + nEM1QgpgyW10pQYyAgQUpHKPXiZL8SYtqrNqYOpoT4mQjWMuDxirredtzzEqj5tjMIjg + BcPk0zBxeuxkMdvo8byM+9fhzmrU8iuADgWOIL2o6NThlZyX21BA8T5yDYBtiX3YWVb/ + fxxf9/yk2p8aaAfYPzkw/1STkE4yGS5g99tn20HILDVbu3HP+TB5OhXhblP4s3afdsIf + +jdglikUgGczPjeS1qlldmnDkjcQsqF0Ai2GWZlvl8jWb4nUISAiruZON9l4AcbAu08h + x+3w== +X-Gm-Message-State: AG10YOTT4dGgmcXBfDkE2NvrfiTVdrPJlTSoZg2KEfq3imM8Ru/QJHSi5esl5PU6b0JsBFgkqTVC4L6rnUwDmA== +MIME-Version: 1.0 +X-Received: by 10.25.213.134 with SMTP id m128mr9905878lfg.87.1454864987135; + Sun, 07 Feb 2016 09:09:47 -0800 (PST) +Received: by 10.25.206.68 with HTTP; Sun, 7 Feb 2016 09:09:46 -0800 (PST) +In-Reply-To: <CAHcfU-V7V8oerKPzuxE1iwZezFnQ1WTCC9g_rGmp7C56wpT19w@mail.gmail.com> +References: <CABsx9T1Bd0-aQg-9uRa4u3dGA5fKxaj8-mEkxVzX8mhdj4Gt2g@mail.gmail.com> + <CAHcfU-V7V8oerKPzuxE1iwZezFnQ1WTCC9g_rGmp7C56wpT19w@mail.gmail.com> +Date: Sun, 7 Feb 2016 12:09:46 -0500 +Message-ID: <CABsx9T0nXVUqZOfH0izsEwv3oU85GKmt8RLgLfXXZk5S-N1OZA@mail.gmail.com> +From: Gavin Andresen <gavinandresen@gmail.com> +To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary=001a11420fbac124f1052b3126ee +X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW + autolearn=ham version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +X-Mailman-Approved-At: Sun, 07 Feb 2016 17:19:43 +0000 +Subject: Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 + megabytes +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.12 +Precedence: list +List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Sun, 07 Feb 2016 17:09:51 -0000 + +--001a11420fbac124f1052b3126ee +Content-Type: text/plain; charset=UTF-8 + +As I feared, request on feedback for this specific BIP has devolved into a +general debate about the merits of soft-forks versus hard-forks (versus +semi-hard Kosher Free Range forks...). + +I've replied to several people privately off-list to not waste people's +time rehashing arguments that have been argued to death in the past. + +I do want to briefly address all of the concerns that stem from "what if a +significant fraction of hashpower (e.g. 25%) stick with the 1mb branch of +the chain." + +Proof of work cannot be spoofed. If there is very little (a few percent) of +hashpower mining a minority chain, confirmations on that chain take orders +of magnitude longer. I wrote about why the incentives are extremely strong +for only the stronger branch to survive here: + http://gavinandresen.ninja/minority-branches + +... the debate about whether or not that is correct doesn't belong here in +bitcoin-dev, in my humble opinion. + +All of the security concerns I have seen flow from an assumption that +significant hashpower continues on the weaker branch. The BIP that is under +discussion assumes that analysis is correct. I have not seen any evidence +that it is not correct; all experience with previous forks (of both Bitcoin +and altcoins) is that the stronger branch survives and the weaker branch +very quickly dies. + + +As for the argument that creating and testing a patch for Core would take +longer than 28 days: + +The glib answer is "people should just run Classic, then." + +A less glib answer is it would be trivial to create a patch for Core that +accepted a more proof-of-work chain with larger blocks, but refused to mine +larger blocks. + +That would be a trivial patch that would require very little testing +(extensive testing of 8 and 20mb blocks has already been done), and perhaps +would be the best compromise until we can agree on a permanent solution +that eliminates the arbitrary, contentious limits. + +-- +-- +Gavin Andresen + +--001a11420fbac124f1052b3126ee +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div class=3D"gmail_extra">As I feared, request on feedbac= +k for this specific BIP has devolved into a general debate about the merits= + of soft-forks versus hard-forks (versus semi-hard Kosher Free Range forks.= +..).</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">I= +'ve replied to several people privately off-list to not waste people= +9;s time rehashing arguments that have been argued to death in the past.</d= +iv><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">I do wan= +t to briefly address all of the concerns that stem from "what if a sig= +nificant fraction of hashpower (e.g. 25%) stick with the 1mb branch of the = +chain."</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_= +extra">Proof of work cannot be spoofed. If there is very little (a few perc= +ent) of hashpower mining a minority chain, confirmations on that chain take= + orders of magnitude longer.=C2=A0 I wrote about why the incentives are ext= +remely strong for only the stronger branch to survive here:</div><div class= +=3D"gmail_extra">=C2=A0<a href=3D"http://gavinandresen.ninja/minority-branc= +hes">http://gavinandresen.ninja/minority-branches</a></div><div class=3D"gm= +ail_extra"><br></div><div class=3D"gmail_extra">... the debate about whethe= +r or not that is correct doesn't belong here in bitcoin-dev, in my humb= +le opinion.</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_e= +xtra">All of the security concerns I have seen flow from an assumption that= + significant hashpower continues on the weaker branch. The BIP that is unde= +r discussion assumes that analysis is correct. I have not seen any evidence= + that it is not correct; all experience with previous forks (of both Bitcoi= +n and altcoins) is that the stronger branch survives and the weaker branch = +very quickly dies.</div><div class=3D"gmail_extra"><br></div><div class=3D"= +gmail_extra"><div><br></div><div>As for the argument that creating and test= +ing a patch for Core would take longer than 28 days:</div><div><br></div><d= +iv>The glib answer is "people should just run Classic, then."</di= +v><div><br></div><div>A less glib answer is it would be trivial to create a= + patch for Core that accepted a more proof-of-work chain with larger blocks= +, but refused to mine larger blocks.</div><div><br></div><div>That would be= + a trivial patch that would require very little testing (extensive testing = +of 8 and 20mb blocks has already been done), and perhaps would be the best = +compromise until we can agree on a permanent solution that eliminates the a= +rbitrary, contentious limits.</div><div><br></div>-- <br><div class=3D"gmai= +l_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>--<br>Gavin Andres= +en<br></div><div><br></div></div></div></div></div> +</div></div> + +--001a11420fbac124f1052b3126ee-- + |