diff options
| author | Adam Back <adam@cypherspace.org> | 2015-09-30 14:15:03 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-09-30 18:15:06 +0000 |
| commit | c462a4020c81f7f6b62657cc21207bd2bb876596 (patch) | |
| tree | 03b1293e93fe831c59e7235595d2d3020f28f934 | |
| parent | c251d4bc3b1979b832472c7564deeb74531473df (diff) | |
| download | pi-bitcoindev-c462a4020c81f7f6b62657cc21207bd2bb876596.tar.gz pi-bitcoindev-c462a4020c81f7f6b62657cc21207bd2bb876596.zip | |
Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
| -rw-r--r-- | 6e/92d28a80610757af3933b819fb142dd5c3cd52 | 119 |
1 files changed, 119 insertions, 0 deletions
diff --git a/6e/92d28a80610757af3933b819fb142dd5c3cd52 b/6e/92d28a80610757af3933b819fb142dd5c3cd52 new file mode 100644 index 000000000..41997563d --- /dev/null +++ b/6e/92d28a80610757af3933b819fb142dd5c3cd52 @@ -0,0 +1,119 @@ +Return-Path: <adam@cypherspace.org> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 2234D1E24 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 30 Sep 2015 18:15:06 +0000 (UTC) +X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 +Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B2ABC18D + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 30 Sep 2015 18:15:05 +0000 (UTC) +Received: from mail-io0-f176.google.com ([209.85.223.176]) by + mrelay.perfora.net (mreueus002) with ESMTPSA (Nemesis) id + 0MS3pM-1a68qQ2fr0-00TFKa for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 30 Sep 2015 20:15:04 +0200 +Received: by ioii196 with SMTP id i196so57513538ioi.3 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 30 Sep 2015 11:15:03 -0700 (PDT) +MIME-Version: 1.0 +X-Received: by 10.107.15.27 with SMTP id x27mr6498356ioi.51.1443636903964; + Wed, 30 Sep 2015 11:15:03 -0700 (PDT) +Received: by 10.50.32.164 with HTTP; Wed, 30 Sep 2015 11:15:03 -0700 (PDT) +In-Reply-To: <CA+w+GKRKGS=KZrLtiW8Zbn4EQH_TELfQR+TfrADCMXLR22Q+tw@mail.gmail.com> +References: <20150927185031.GA20599@savin.petertodd.org> + <CA+w+GKRCVr-9TVk66utp7xLRgTxNpxYoj3XQE-6y_N8JS6eO6Q@mail.gmail.com> + <CAAS2fgSEDGBd67m7i8zCgNRqtmQrZyZMj7a5TsYo41Dh=tdhHQ@mail.gmail.com> + <CA+w+GKRKGS=KZrLtiW8Zbn4EQH_TELfQR+TfrADCMXLR22Q+tw@mail.gmail.com> +Date: Wed, 30 Sep 2015 14:15:03 -0400 +Message-ID: <CALqxMTGqGbJLFNerw+1goR2g54+vn=ECgzx++_oRznrzJWfd4g@mail.gmail.com> +From: Adam Back <adam@cypherspace.org> +To: Mike Hearn <hearn@vinumeris.com> +Content-Type: text/plain; charset=UTF-8 +X-Provags-ID: V03:K0:PX3SA1xlyr/HIUU64Oh6Qj1DTkgWg/zIq7Mb0qGhvk67SP7Om9U + iSV3nNGyi+ZVhsoFGkF0CS9G75mNBfGkR6/ULBBglju7qH+qv58/QO06uh0KbX8MFTZTkep + 6Kf24MNu/PIrlB9E6JTj7vb9W8ouxP8BQQyNx6ivMiyWWd2yKtGx0tYmSozIyfql15qUtdF + GlZCH4w9yBQGlkvpY9m8Q== +X-UI-Out-Filterresults: notjunk:1;V01:K0:xiSRVqB2Q3k=:NpTkvh7STCG84PGcN6XAyN + ibo+OrAcdKeb5isI5yacoB51PgbrB6UUWluU+dX7TV6xcUrCYmVZ3KK6GaFZpK9uqg9tJVWVe + WND+DBWt0lGx1fGVoHmoem8WhOxsUdjgK5mNf3CA1Ci6Be9PMXw/tQPHLsgp5VcLWKHUAZkvR + OPO0JQDpp4PWcL7/jCiQcVrm3OfcFP+11JTVyfsOOfI0O2RuNUGZJkUvo5C6P4HYOJUVEexhQ + NmS8DfWIUCH+B0JYE9QUMUFCe4F/fhwLHHRvOkozL8VA+U/RKYmAQuux/gDU3a8saITUfZOaX + gr0V0XHf7bS11+aXnNrOC39oDbQl1/1Rw6I361MU34fCEzwcehdI4bD2XINioHV46ZnuQqADA + RCko4VAR9JB7JXmUUXua/FaOX86monqZBAC94k4W8JieccMwbflGdDp1bpn2XJ8rgMmXVwamZ + 4Zbr/bPukoTvilaUUW8pGJrSaXeZdf3bNg5Ub2lpFEuLlhRSqPxs0viE1EkSWKGuqF0uD5jWG + Dw4bkNRwGx6Pcx5INEMMm2lhHWw4l5b6HiKAW7PYolVIV4zi1mH/Pr9tzJmgnDKtQx0AdnI8M + JRMXQn89sgc+jNnhcYXNCQIRVCxe8mgDTVmKWrps+XIX1L8Rguj4lkE99ej9QgTxosNV1haye + p/qt4ItzI8xiAweT4Gx1NS8A0JSmxFx+kLlRZoACi6CXxQA== +X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE + 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 <bitcoin-dev@lists.linuxfoundation.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: Wed, 30 Sep 2015 18:15:06 -0000 + +On 30 September 2015 at 13:11, Mike Hearn via bitcoin-dev +<bitcoin-dev@lists.linuxfoundation.org> wrote: +>> Have I missed a proposal to change BIP101 to be a real hardfork +> +> There's no such thing as a "real" hard fork - don't try and move the goal +> posts. SPV clients do not need any changes to do the right thing with BIP +> 101, they will follow the new chain automatically, so it needs no changes. + +BIP101 is a hybrid: in some ways it is a hard-fork and in other ways +it is a soft-fork. It is a hard-fork to full-nodes, but also a +soft-fork to SPV clients, as by definition the SPV miners are having +changes made whether they approve or not as they are not even aware of +the change. + +> To repeat: CLTV does not have consensus at the moment. + +I think people are saying CLTV is long discussed and does have consensus. + +> Several people have asked several times now: given the very real and widely +> acknowledged downsides that come with a soft fork, what is the specific +> benefit to end users of doing them? +> +> Until that question is answered to my satisfaction I continue to object to +> this BIP on the grounds that the deployment creates financial risk +> unnecessarily. + +Let's not conflate CLTV with a discussion about future possible +deployment methods. Forks are an interesting but different topic. + +Soft-forks have a lot of mileage on them at this point, hard-forks do +not, and are anyway inherently higher riskier, even ignoring our lack +of practical experience with planned hard-forks. + +With a soft-fork, while it's clear there is a temporary security model +reduction for SPV nodes (and non-upgraded full nodes) in the period +before they upgrade, this is preferable to the risks of a system-wide +coordinated hard-fork upgrade. There is some limit if the complexity +of soft-forking a feature is quite complicated (eg one could argue +that with soft-fork extension-blocks vs hard-fork method of increasing +block-size for example). So the balance, which I think is easily met +with CLTV, is that soft-fork is simple-enough technically and the +feature is entirely non-controversial and additive functionality +improvement without downside or reason for dissent. + +To my view this is an answer to your question "what is the specific +benefit to end users of doing [soft-forks]" -- it is a lower risk, and +therefore faster way to deploy non-controversial (additive) changes. + +Given the CLTV is useful for improving lightning efficiency this is +good for improving Bitcoin's scalability. + +Adam + |