Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

[Peter Todd <pete@petertodd.org>]

[-- Attachment #1: Type: text/plain, Size: 4538 bytes --]

On Mon, Sep 28, 2015 at 12:48:57PM +0200, Mike Hearn 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

Hmm? You didn't quote any of my email, so I'll remind you what I did say
we had consensus about:

    2) We have consensus on the semantics of the CLTV opcode

and

    3) We have consensus that Bitcoin should adopt CLTV

    The broad peer review and discussion that got #6124 merged is a clear
    sign that we expect CLTV to be eventually adopted.  __The question isn't
    if CLTV should be added to the Bitcoin protocol, but rather when.__

(emphasis mine)

Both those statements of consensus are *not* about how CLTV is to be
deployed. I did discuss deployment later:

    6) We have the __necessary consensus__ to deploy CLTV via IsSuperMajority()

    The various "nVersion bits" proposals - which I am a co-author of - have
    the primary advantage of being able to cleanly deal with the case where
    a soft-fork fails to get adopted. However, we do have broad consensus,
    including across all sides of the blocksize debate, that CLTV should be
    adopted. __The risk of CLTV failing to get miner adoption, and thus
    blocking other soft-forks, is very low.__

I probably could have worded this section a bit more clearly; when I say
"necessary consensus" I'm referring to the consensus required for a
soft-fork deployment. At minimum a simple majority of hashing power -
your approval isn't required.

For a safe soft-fork, we'd like a super majority of miners to be on
board. For a IsSuperMajority() soft-fork - as opposed to nVersion bits -
we also need the probability of the soft-fork being rejected to be very
low. To achieve that, having consensus that CLTV is a good idea is the
best situation to be in. But that's not to say that a few dissenting
voices should be seen as a blocker to progress - rather is just makes
the deployment a bit more risky, being a sign that the consensus may
change in the future, with the soft-fork being later rejected. For
example strong objections by a respected Bitcoin developer who has made
significant contributions to the consensus codebase and protocol
development would be a strong sign that a IsSuperMajority() soft-fork
might fail, and deployment via nVersion bits is probably a better
approach. Fortunately we're not in that situation.

Hard-forks are a very different situation, with significantly more need
for very broad consensus, but that's been well discussed elsewhere.


I have three questions to you:

1) Do you agree that CLTV should be added to the Bitcoin protocol?

Ignoring the question how exactly it is added, hard-fork or soft-fork.


2) Will you add a IsSuperMajority() CLTV soft-fork to Bitcoin XT if it
   is added to Bitcoin Core?

If you refuse to do this the risk of the soft-fork is increased a bit,
although miner support for XT has remained extremely low, and the 95%
switch-over threshold has a significant margin for error. (there's a 75%
threshold to consider as well, however as XT has adopted my pull-req
#5000 - Discourage NOPs reserved for soft-fork upgrades - those miners
will only produce valid blocks under CLTV rules)


3) Will you add soft-fork detection to bitcoinj, to allow SPV clients to
   detect advertised soft-forks and correctly handle them?

Notably, if you do this your objections against soft-forks will be met,
as the behavior of a SPV client with soft-fork detection during a
soft-fork will be identical to that client during a hard-fork. In
particular, the SPV client will correct reject invalid blocks, and
continue to follow only the longest valid chain. (modulo unadvertised
forks of course, an inherently unavoidable problem with the SPV security
model) Secondly, that code should also detect forks it doesn't know
about - as is done in Bitcoin Core already - and warn the user.

-- 
'peter'[:-1]@petertodd.org
00000000000000000d74f5def1087f3ec1571cb468e471e71f96063253988c78

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]