MIME-Version: 1.0
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
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
Precedence: list

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