Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id C4356DA5 for ; Sat, 26 Dec 2015 16:44:42 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f174.google.com (mail-io0-f174.google.com [209.85.223.174]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 297F6EC for ; Sat, 26 Dec 2015 16:44:42 +0000 (UTC) Received: by mail-io0-f174.google.com with SMTP id e126so276693186ioa.1 for ; Sat, 26 Dec 2015 08:44:42 -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 :cc:content-type; bh=BftQBZ//eLuul3vR+XVOoYuvc0/hmC3mkOh9O9Ig4n8=; b=Ewpyowdfqjl8IoJu/FGfR59jmowL55XJjOUaOmQ2m6xxU3ckQLPizjVylbu/ao1ItU Qw73MatZFICII1bEeuQjSzZu2jOluS48cgzDxn+SZ9zuTypiRBRstKVjTfKNBcqsyf5j NGXuvwxwQPcLYVMXXhwtOlJ+zBdMgbrNq9/5x6djUo7JStxLoPXQNLYSoGSoMq0LRQsq oGNEW1lSast2rfSuKkqdszSs45z74noA3eZP9u1b1L0PKG1dKboX2+R6mShBdh2h+EEl TdUbHuqWZUVo3PiNjWW4zLVyTXiIfRr9FI3SoQ8jHOb7ZG15N8vcH8HC2xPDIp7YNXAi q2Ig== MIME-Version: 1.0 X-Received: by 10.107.165.197 with SMTP id o188mr45867908ioe.132.1451148281620; Sat, 26 Dec 2015 08:44:41 -0800 (PST) Received: by 10.36.80.6 with HTTP; Sat, 26 Dec 2015 08:44:41 -0800 (PST) Received: by 10.36.80.6 with HTTP; Sat, 26 Dec 2015 08:44:41 -0800 (PST) In-Reply-To: <751DFAA9-9013-4C54-BC1E-5F7ECB7469CC@gmail.com> References: <751DFAA9-9013-4C54-BC1E-5F7ECB7469CC@gmail.com> Date: Sat, 26 Dec 2015 17:44:41 +0100 Message-ID: From: Pieter Wuille To: digitsu Content-Type: multipart/alternative; boundary=001a11350734d7aff90527cfc98f 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: It's economics & user preparation & moral hazard 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: Sat, 26 Dec 2015 16:44:42 -0000 --001a11350734d7aff90527cfc98f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable That's exactly the point: a hard fork does not just affect miners, and cannot just get decided by miners. All full nodes must have accepted the new rules, or they will be forked off when the hashrate percentage triggers= . Furthermore, 75% is pretty terrible as a switchover point, as it guarantees that old nodes will still see a 25% forked off chain temporarily. My opinion is that the role of Bitcoin Core maintainers is judging whether consensus for a hard fork exists, and is technically necessary and safe. We don't need a hashpower vote to decide whether a hardfork is accepted or not, we need to be sure that full noded will accept it, and adopt it in time. A hashpower vote can still be used to be sure that miners _also_ agree. Currently, a large amount of developers and others believe that the treshhold for a hardfork is not reached, especially given the fact that we scale in the short term, as well as make many changes that long-term benefit scalability, with just a softfork (which does not require forking off nodes that don't adopt the new rules, for whatever reason). --=20 Pieter On Dec 26, 2015 17:25, "digitsu" wrote: > So it seems that everyone is in agreement then, since a hard fork to 2M i= s > orthogonal to SW, and also that core should not be involved in dictating > what the consensus rules should be, then why not put BIP102 into play wit= h > a 75% mining majority activation and let the market decide. > > As it=E2=80=99s activation only involves the miners, and its implementati= on > doesn=E2=80=99t affect users or exchanges, then it poses no complication = to SW > which can do done in parallel. > > > > --001a11350734d7aff90527cfc98f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

That's exactly the point: a hard fork does not just affe= ct miners, and cannot just get decided by miners. All full nodes must have = accepted the new rules, or they will be forked off when the hashrate percen= tage triggers.

Furthermore, 75% is pretty terrible as a switchover point, a= s it guarantees that old nodes will still see a 25% forked off chain tempor= arily.

My opinion is that the role of Bitcoin Core maintainers is j= udging whether consensus for a hard fork exists, and is technically necessa= ry and safe. We don't need a hashpower vote to decide whether a hardfor= k is accepted or not, we need to be sure that full noded will accept it, an= d adopt it in time. A hashpower vote can still be used to be sure that mine= rs _also_ agree.

Currently, a large amount of developers and others believe t= hat the treshhold for a hardfork is not reached, especially given the fact = that we scale in the short term, as well as make many changes that long-ter= m benefit scalability, with just a softfork (which does not require forking= off nodes that don't adopt the new rules, for whatever reason).

--
Pieter

On Dec 26, 2015 17:25, "digitsu" <<= a href=3D"mailto:jerry.d.chan@bittoku.co.jp">jerry.d.chan@bittoku.co.jp= > wrote:
So it se= ems that everyone is in agreement then, since a hard fork to 2M is orthogon= al to SW, and also that core should not be involved in dictating what the c= onsensus rules should be, then why not put BIP102 into play with a 75% mini= ng majority activation and let the market decide.

As it=E2=80=99s activation only involves the miners, and its implementation= doesn=E2=80=99t affect users or exchanges, then it poses no complication t= o SW which can do done in parallel.



--001a11350734d7aff90527cfc98f--