Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 6A7D41BA1 for ; Fri, 2 Oct 2015 02:10:50 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from BLU004-OMC4S18.hotmail.com (blu004-omc4s18.hotmail.com [65.55.111.157]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0178420C for ; Fri, 2 Oct 2015 02:10:48 +0000 (UTC) Received: from BLU436-SMTP132 ([65.55.111.137]) by BLU004-OMC4S18.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Thu, 1 Oct 2015 19:10:48 -0700 X-TMN: [FwDfxp9z7t8BN3zElT1CATQ793kGLHQZ] X-Originating-Email: [slashdevnull@hotmail.com] Message-ID: User-Agent: Microsoft-MacOutlook/14.4.9.150325 Date: Fri, 2 Oct 2015 10:12:58 +0800 From: GC To: NotMike Hearn , Thread-Topic: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY! References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="B_3526625586_4125295" X-OriginalArrivalTime: 02 Oct 2015 02:10:47.0237 (UTC) FILETIME=[8D3A5750:01D0FCB7] X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM, HTML_MESSAGE,MIME_QP_LONG_LINE,RCVD_IN_DNSWL_LOW,T_RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org 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: Fri, 02 Oct 2015 02:10:50 -0000 --B_3526625586_4125295 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Or, you know, enter some discussions on what exactly are the issues that SP= V clients face during soft forks and see if anything can be done (on all sides) to mitigate the risks. Crazy stuff, I know =8A ;-) From: NotMike Hearn via bitcoin-dev Reply-To: NotMike Hearn Date: Friday, 2 October 2015 9:57 am To: Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY! On 28 September 2015 at 06:48, Mike Hearn via bitcoin-dev wrote: > There is no consensus on using a soft fork to deploy this feature. It wil= l > result in the same problems as all the other soft forks - SPV wallets wil= l > become less reliable during the rollout period. I am against that, as it'= s > entirely avoidable. > > Make it a hard fork and my objection will be dropped. > > Until then, as there is no consensus, you need to do one of two things: > > 1) Drop the "everyone must agree to make changes" idea that people here l= ike > to peddle, and do it loudly, so everyone in the community is correctly > informed > > 2) Do nothing > > I agree with Mike Hearn that there is no consensus on using a soft fork to deploy this feature. Either everyone agrees that we should all agree on consensus or else there is arbitrary disagreement. You cannot have it both ways. It is very important that we reach consensus on consensus or, if you will, meta0consensus. I think we should Do nothing as that is clearly the choice that we have taken re: blocksize. If we use one set of rules for that decision we should use the same set of rules for all decisions and there is no middle ground. Thank you. > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --B_3526625586_4125295 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Or, you know, enter some disc= ussions on what exactly are the issues that SPV clients face during soft for= ks and see if anything can be done (on all sides) to mitigate the risks.

Crazy stuff, I know … ;-)

From: NotMike Hearn via bitcoin-dev <bitcoin-dev@lists.linux= foundation.org>
Reply-To: N= otMike Hearn <not.mike.hearn@gm= ail.com>
Date: Friday, 2 Oc= tober 2015 9:57 am
To: <bitcoin-dev@lists.linuxfound= ation.org>
Subject: Re: [bi= tcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

<= div dir=3D"ltr">
On 28 September 2015 at 06:48, Mike Hearn via bitcoin-dev=
> There is no co= nsensus on using a soft fork to deploy this feature. It will
> = result in the same problems as all the other soft forks - SPV wallets will
> become less reliable during the rollout period. I am against t= hat, as it's
> entirely avoidable.
>
>= ; Make it a hard fork and my objection will be dropped.
>
=
> Until then, as there is no consensus, you need to do one of two th= ings:
>
> 1) Drop the "everyone must agree to make= changes" idea that people here like
> to peddle, and do it lou= dly, so everyone in the community is correctly
> informed
=
>
> 2) Do nothing
>
>

I agree with Mike Hearn that there is no consensus on usin= g a soft fork to deploy this feature. Either everyone agrees that we should = all agree on consensus or else there is arbitrary disagreement. You cannot h= ave it both ways.

It is very important that we reach consensus on con= sensus or, if you will, meta0consensus. I think we should Do nothing as that= is clearly the choice that we have taken re: blocksize. If we use one set o= f rules for that decision we should use the same set of rules for all decisi= ons and there is no middle ground.

Thank you.

>
> _______________________________________________=
> bitcoin-dev mailing list

_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.li= nuxfoundation.org ht= tps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --B_3526625586_4125295--