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 EB1128ED for ; Tue, 4 Aug 2015 14:45:39 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f180.google.com (mail-io0-f180.google.com [209.85.223.180]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 61CC51C8 for ; Tue, 4 Aug 2015 14:45:39 +0000 (UTC) Received: by ioii16 with SMTP id i16so19088057ioi.0 for ; Tue, 04 Aug 2015 07:45:38 -0700 (PDT) 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 :cc:content-type; bh=OxikNpD96DlvHj5JIB7r35VrlD8dsXMRzPuqytaPsv0=; b=LVS5V9usTxETu7QcZ3rC7WSS90QOjQNh56rMBKwaW2HPtwjqRAWPEwuPUk7PeDsYcr HO5NMReC5X0qPGs0KaS8M9eBcis0xBz9Zo77LIuZxPFb++eMhMcokVFRGyVRzWTEMIN6 wtF5c6NstxiVjynGKZuXPct3WXGOaZs7dls43EkRY11R3DHphorZSiTgPBYYM8lTNLfq 3gSmndCuyndi226BX+lqKU93LQ7PbP99Xqxt8D1n/BZnglRDXmpcYv52W0onlo9RGxK+ +CdLcs6cT1o2M++E1ZUZcid6xePlRuy4jXKT94PxOXCrbOzjoS1qi3zi/tcL00l+P+CF psgA== MIME-Version: 1.0 X-Received: by 10.107.3.224 with SMTP id e93mr4112069ioi.160.1438699538898; Tue, 04 Aug 2015 07:45:38 -0700 (PDT) Received: by 10.64.241.137 with HTTP; Tue, 4 Aug 2015 07:45:38 -0700 (PDT) In-Reply-To: References: Date: Tue, 4 Aug 2015 10:45:38 -0400 Message-ID: From: Alex Morcos To: Gavin Andresen Content-Type: multipart/alternative; boundary=001a113df88ef46666051c7d56c0 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 Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] Block size following technological growth 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: Tue, 04 Aug 2015 14:45:40 -0000 --001a113df88ef46666051c7d56c0 Content-Type: text/plain; charset=UTF-8 On Tue, Aug 4, 2015 at 9:12 AM, Gavin Andresen via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Tue, Aug 4, 2015 at 7:27 AM, Pieter Wuille via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> I would say that things already demonstrately got terrible. The mining >> landscape is very centralized, with apparently a majority depending on >> agreements to trust each other's announced blocks without validation. >> > And that is a problem... why? > > As far as I can tell, nobody besides miners running old and/or buggy > software lost money due to outsourced mining validation (please correct me > if I'm wrong-- I'm looking forward to Greg's post-mortem). The operators of > bitcoin.org seem to have freaked out and pushed the panic button (with > dire warnings of not trusting transactions until 20 confirmations), but > theymos was well known for using an old, patched version of Core for > blockexplorer.com so maybe that's not surprising. > > I'm also looking forward to Greg's post-mortem, because I had a completely different takeaway from the BIP66 mini-forks. My view is that despite the extremely cautious and conservative planning for the completely uncontentious fork, the damage could and would have been very significant if it had not been for several core devs manually monitoring, intervening and problem solving for other network participants. I don't believe thats the way the system should work. Participants in the Bitcoin community have come to rely on the devs for just making sure everything works for them. That's not sustainable. The system needs to be made fundamentally more secure if its going to succeed, not depend on the good will of any particular parties, otherwise it certainly will no longer be permissionless. The BIP66 fork was urgently required to fix an undisclosed consensus bug, unanimously agreed on and without technical objection, and it was still fraught with problems. That's the most clear cut example of when we should have a fork. A change to a consensus limit that a significant proportion of the community disagrees with for economic or technical reasons or both should be raising a sea of red flags. --001a113df88ef46666051c7d56c0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Aug 4, 2015 at 9:12 AM, Gavin Andresen via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
On Tue, Aug 4, 2015 at 7:27 A= M, Pieter Wuille via bitcoin-dev <bitcoin-dev@lists.li= nuxfoundation.org> wrote:
<= p dir=3D"ltr">I would say that things already demonstrately got terrible. T= he mining landscape is very centralized, with apparently a majority dependi= ng on agreements to trust each other's announced blocks without validat= ion.

And that is a problem... why?
As far as I can tell, nobody besides miners running old and/or= buggy software lost money due to outsourced mining validation (please corr= ect me if I'm wrong-- I'm looking forward to Greg's post-mortem= ). The operators of bitcoi= n.org seem to have freaked out and pushed the panic button (with dire w= arnings of not trusting transactions until 20 confirmations), but theymos w= as well known for using an old, patched version of Core for blockexplorer.com so maybe that= 's not surprising.

<= div>
I'm also looking forward to Greg's post-mortem, = because I had a completely different takeaway from the BIP66 mini-forks.=C2= =A0 My view is that despite the extremely cautious and conservative plannin= g for the completely uncontentious fork, the damage could and would have be= en very significant if it had not been for several core devs manually monit= oring, intervening and problem solving for other network participants.=C2= =A0 I don't believe thats the way the system should work.=C2=A0 Partici= pants in the Bitcoin community have come to rely on the devs for just makin= g sure everything works for them.=C2=A0 That's not sustainable.=C2=A0 T= he system needs to be made fundamentally more secure if its going to succee= d, not depend on the good will of any particular parties, otherwise it cert= ainly will no longer be permissionless.

The BIP66 = fork was urgently required to fix an undisclosed consensus bug, unanimously= agreed on and without technical objection, and it was still fraught with p= roblems.=C2=A0 That's the most clear cut example of when we should have= a fork.=C2=A0 A change to a consensus limit that a significant proportion = of the community disagrees with for economic or technical reasons or both s= hould be raising a sea of red flags.


--001a113df88ef46666051c7d56c0--