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 895162247 for ; Wed, 30 Sep 2015 22:17:14 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CDF0C1D2 for ; Wed, 30 Sep 2015 22:17:13 +0000 (UTC) Received: by wicgb1 with SMTP id gb1so3350642wic.1 for ; Wed, 30 Sep 2015 15:17:12 -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=r2PHbINCfDc6loPtqertKONaSKtvbzvW+V6WGX34Ejk=; b=dD81c3plLgJ1whXAUUkEYSrfRrm3V7fJqePGOF7czInB6GMNRQ/qC3lt0f7Nb4Ot5m l3qD1bRLmwyGwcbpi14g5Yne+udt+82yHGRbUePtFWNkVNR0N/ik7FyNO3CmLrxST03p zJZ0gtMVIsoKtLAX9FuJUQg24XkdtOMBYmpEKCPKJzVT7hLsV4EU74PcKN8mzYK2rWxw 2gFhB2Ve2nLzp4gVC+L6ClGpSUDKLxgDRiqaOf9xPS/Vbzo1xeRVdK9CwSanw8VuHcHo GM1mGPfgbA6J/j5yfQIuDp5qm1eHZmbus6UB5Bm2YboiINsX37M/p8Vc8pB6T48PkqHS RyMA== MIME-Version: 1.0 X-Received: by 10.194.78.10 with SMTP id x10mr6757588wjw.108.1443651432601; Wed, 30 Sep 2015 15:17:12 -0700 (PDT) Received: by 10.28.158.9 with HTTP; Wed, 30 Sep 2015 15:17:12 -0700 (PDT) In-Reply-To: References: <20150927185031.GA20599@savin.petertodd.org> Date: Wed, 30 Sep 2015 18:17:12 -0400 Message-ID: From: Jeff Garzik To: Mike Hearn Content-Type: multipart/alternative; boundary=047d7bfcfd86d1dd790520fe4a73 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] Let's deploy BIP65 CHECKLOCKTIMEVERIFY! 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: Wed, 30 Sep 2015 22:17:14 -0000 --047d7bfcfd86d1dd790520fe4a73 Content-Type: text/plain; charset=UTF-8 On Wed, Sep 30, 2015 at 3:56 PM, Mike Hearn wrote: > Field experience shows it successfully delivers new features to end users >> without a global software upgrade. >> > > The global upgrade is required for all full nodes in both types. If a full > node doesn't upgrade then it no longer does what it was designed to do; if > the user is OK with that, they should just run an SPV wallet or use > blockchain.info or some other mechanism that consumes way fewer resources. > > But if you want the software you installed to achieve its stated goal, you > *must* upgrade. There is no way around that. > It is correct that security is slightly reduced for full nodes that have not upgraded. It is not correct that the choice is binary, full node or SPV. Any user running a not-upgraded full node still retains protection against many attacks outside the subset related to the feature being introduced. The field observable end result is that we do receive new features, secured by hashpower and user full nodes, via soft fork, without a global flag day upgrade. Yes, a flag day hard fork upgrade is cleaner and results in higher security due to the entire network validating the new rules. However, the difficulty of executing hard forks would mean fewer total features to users, if that route were chosen instead. --047d7bfcfd86d1dd790520fe4a73 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Sep 30, 2015 at 3:56 PM, Mike Hearn <hearn@vinu= meris.com> wrote:
Field experience = shows it successfully delivers new features to end users without a global s= oftware upgrade.

The glo= bal upgrade is required for all full nodes in both types. If a full node do= esn't upgrade then it no longer does what it was designed to do; if the= user is OK with that, they should just run an SPV wallet or use blockchain.info or some othe= r mechanism that consumes way fewer resources.

But= if you want the software you installed to achieve its stated goal, you = must=C2=A0upgrade. There is no way around that.
=

It is correct that security is slightly re= duced for full nodes that have not upgraded.=C2=A0 It is not correct that t= he choice is binary, full node or SPV.

Any user ru= nning a not-upgraded full node still retains protection against many attack= s outside the subset related to the feature being introduced.
The field observable end result is that we do receive new featu= res, secured by hashpower and user full nodes, via soft fork, without a glo= bal flag day upgrade.

Yes, a flag day hard fork up= grade is cleaner and results in higher security due to the entire network v= alidating the new rules.=C2=A0 However, the difficulty of executing hard fo= rks would mean fewer total features to users, if that route were chosen ins= tead.


--047d7bfcfd86d1dd790520fe4a73--