diff options
| author | NotMike Hearn <not.mike.hearn@gmail.com> | 2015-10-01 21:57:38 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-10-02 01:57:39 +0000 |
| commit | d9b27a7aaf3e86dfb1a7e35f64de827ce7181ce8 (patch) | |
| tree | 1cc2e01127aa0f78f4d4d11aedd260a58fd0a962 | |
| parent | eaaeab82555689d6ddcef5f86dddd927249f157c (diff) | |
| download | pi-bitcoindev-d9b27a7aaf3e86dfb1a7e35f64de827ce7181ce8.tar.gz pi-bitcoindev-d9b27a7aaf3e86dfb1a7e35f64de827ce7181ce8.zip | |
Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
| -rw-r--r-- | fe/75a19a86175386112587fe2f47235dc5a9dd38 | 130 |
1 files changed, 130 insertions, 0 deletions
diff --git a/fe/75a19a86175386112587fe2f47235dc5a9dd38 b/fe/75a19a86175386112587fe2f47235dc5a9dd38 new file mode 100644 index 000000000..14be408f0 --- /dev/null +++ b/fe/75a19a86175386112587fe2f47235dc5a9dd38 @@ -0,0 +1,130 @@ +Return-Path: <not.mike.hearn@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id F27B7B1D + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 2 Oct 2015 01:57:39 +0000 (UTC) +Received: by ioii196 with SMTP id i196so9177941ioi.2 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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: <CAKfs=Z_jVKtjeSHM1a6n+ch6WcazkshmDgN4Wi1K_kLBUE4o4w@mail.gmail.com> +From: NotMike Hearn <not.mike.hearn@gmail.com> +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 +<bitcoin-dev@lists.linuxfoundation.org> 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 + +<div dir=3D"ltr"><div>On 28 September 2015 at 06:48, Mike Hearn via bitcoin= +-dev</div><div><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org"= +>bitcoin-dev@lists.linuxfoundation.org</a>> wrote:</div><div>> There = +is no consensus on using a soft fork to deploy this feature. It will</div><= +div>> result in the same problems as all the other soft forks - SPV wall= +ets will</div><div>> become less reliable during the rollout period. I a= +m against that, as it's</div><div>> entirely avoidable.</div><div>&g= +t;</div><div>> Make it a hard fork and my objection will be dropped.</di= +v><div>></div><div>> Until then, as there is no consensus, you need t= +o do one of two things:</div><div>></div><div>> 1) Drop the "eve= +ryone must agree to make changes" idea that people here like</div><div= +>> to peddle, and do it loudly, so everyone in the community is correctl= +y</div><div>> informed</div><div>></div><div>> 2) Do nothing</div>= +<div>></div><div>></div><div><br></div><div>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.<br><br>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.</= +div><div><br>Thank you.</div><div><br></div><div>></div><div>> ______= +_________________________________________</div><div>> bitcoin-dev mailin= +g list</div><div>> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.o= +rg">bitcoin-dev@lists.linuxfoundation.org</a></div><div>> <a href=3D"htt= +ps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.= +linuxfoundation.org/mailman/listinfo/bitcoin-dev</a></div><div>></div><d= +iv><br></div></div> + +--001a113eacda016e640521157d72-- + |