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 F27B7B1D for ; Fri, 2 Oct 2015 01:57:39 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f196.google.com (mail-io0-f196.google.com [209.85.223.196]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6959B100 for ; Fri, 2 Oct 2015 01:57:39 +0000 (UTC) Received: by ioii196 with SMTP id i196so9177941ioi.2 for ; Thu, 01 Oct 2015 18:57:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=7alewBc+UyLVw+CJG0zkiwbdTrH5ZXCRtmO/lfxZYUU=; b=OLTkKPRMFociTGXipWA8HnR1tZnuTMXpdpyBpInMxttDiNQ1Do+LviayZm7jnYOjv5 NuYEyrPVBsMSl3AFtcoLUK6ysOwjWsNhsHg7DI2htefhfzSe8nIEPgNFV1xhk+uAT4Ng hl64YIel6Mm3DRIMVYzb36XXoEaPZzkZP6w7+eLKGncOjG4IoSFnXgum4ZhDBp3wNTL0 TGMVEhzM3XdUMv6l9XkKtSa3L/xqr2fOpA5kww9Y/d/g0XxMdUwhJ4Ytbb9Tfkjn2zEo ykBQUSzfjfYiUHRxAAGBr2oAVxTZNbNOVOZyp7MWTwq5xPv8MlH3aFtgOhGvKeE0Vlvk 5z/Q== MIME-Version: 1.0 X-Received: by 10.107.137.162 with SMTP id t34mr17012658ioi.103.1443751058819; Thu, 01 Oct 2015 18:57:38 -0700 (PDT) Received: by 10.64.223.164 with HTTP; Thu, 1 Oct 2015 18:57:38 -0700 (PDT) Date: Thu, 1 Oct 2015 21:57:38 -0400 Message-ID: From: NotMike Hearn To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary=001a113eacda016e640521157d72 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 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 01:57:40 -0000 --001a113eacda016e640521157d72 Content-Type: text/plain; charset=UTF-8 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 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 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 like > 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 > --001a113eacda016e640521157d72 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 28 September 2015 at 06:48, Mike Hearn via bitcoin= -dev
> There = is no consensus on using a soft fork to deploy this feature. It will
<= div>> result in the same problems as all the other soft forks - SPV wall= ets will
> become less reliable during the rollout period. I a= m against that, as it's
> entirely avoidable.
&g= t;
> Make it a hard fork and my objection will be dropped.
>
> Until then, as there is no consensus, you need t= o do one of two things:
>
> 1) Drop the "eve= ryone must agree to make changes" idea that people here like
> to peddle, and do it loudly, so everyone in the community is correctl= y
> informed
>
> 2) Do nothing
=
>
>

I agree with Mike Hearn t= hat there is no consensus on using a soft fork to deploy this feature. Eith= er everyone agrees that we should all agree on consensus or else there is a= rbitrary disagreement. You cannot have it both ways.

It is very impo= rtant 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 ta= ken re: blocksize. If we use one set of rules for that decision we should u= se the same set of rules for all decisions and there is no middle ground.

Thank you.

>
> ______= _________________________________________
> bitcoin-dev mailin= g list
>

--001a113eacda016e640521157d72--