From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 44A1B1001 for ; 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 ; Sun, 7 Feb 2016 17:09:48 +0000 (UTC) Received: by mail-lf0-f43.google.com with SMTP id 78so83266406lfy.3 for ; 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: References: Date: Sun, 7 Feb 2016 12:09:46 -0500 Message-ID: From: Gavin Andresen To: Bitcoin Dev 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
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.= ..).

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.

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

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:
=C2=A0http://gavinandresen.ninja/minority-branches

... the debate about whethe= r or not that is correct doesn't belong here in bitcoin-dev, in my humb= le 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 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.


As for the argument that creating and test= ing 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 a= rbitrary, contentious limits.

--
--
Gavin Andres= en

--001a11420fbac124f1052b3126ee--