public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Peter Todd <pete@petertodd•org>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: [bitcoin-dev] BIP65 / CHECKLOCKTIMEVERIFY deployment
Date: Thu, 25 Jun 2015 18:33:44 -0400	[thread overview]
Message-ID: <20150625223344.GA2406@muck> (raw)

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

BIP66 adoption is quite close to 95% and will likely be enforced for all
blocks in a few more days; now is time to think about how CLTV will be
deployed, particularly given its benefits to much-needed scalability
solutions such as payment channels.

While I'm both a fan and co-author of the Version bits BIP(1) proposal,
it hasn't been implemented yet, and the implementation will be
relatively complex compared to the previous soft-fork mechanism. I think
there is good reason to get CLTV deployed sooner, and I don't think we
have any lack of consensus on it. The CLTV code itself has been
extensively reviewed in the form of the "mempool-only" pull-req, has
been included in the Elements sidechain prototype by Mark Friedenbach,
has been running in production on Viacoin for six months, and has a few
working demos of its functionality implemented. It's also been famously
described as "What you thought nLockTime did until you actually tried to
use it."

To that end I'm proposing that we simply use the existing median block
version mechanism previously used for the nVersion=2 and nVersion=3
soft-forks for CLTV. This mechanism is well-tested and understood, and
would allow CLTV to be easily backported to v0.10.x (even 0.9.x) with
little risk for rapid deployment. In the event that another soft-fork is
proposed prior to BIP65, nVersion=4, enforcement, we do have the option
of setting in motion yet another soft-fork as the median mechanism only
requires forks to be serialized in sequence - it does not prevent
multiple soft-forks from being "in-flight" at the same time.

Thoughts? If there are no objections I'll go ahead and write that code,
using the same thresholds as BIP66.

1) https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07863.html

-- 
'peter'[:-1]@petertodd.org
0000000000000000007fc13ce02072d9cb2a6d51fae41fefcde7b3b283803d24

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

             reply	other threads:[~2015-06-25 22:33 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-25 22:33 Peter Todd [this message]
2015-06-25 23:52 ` Eric Lombrozo
2015-06-26  0:07   ` Tier Nolan
2015-06-28 19:50 ` Peter Todd
2015-08-04 16:54   ` Pieter Wuille

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150625223344.GA2406@muck \
    --to=pete@petertodd$(echo .)org \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox