BIP65 / CHECKLOCKTIMEVERIFY deployment
5 messages, 25 Jun to 4 Aug 2015. Started by Peter Todd.
Peter Todd (2), Eric Lombrozo, Tier Nolan, Pieter Wuille
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
Please do it. On Jun 25, 2015 3:33 PM, "Peter Todd" <pete@petertodd•org> wrote:
Quoted text (43 lines)
> 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 > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >
It would be possible to run a simplified version of the bits proposal, until BIP 66 locks.
It's obviously not worth it at this point though, though it could be 1-2 weeks more.
Version 2 means neither option Version 3 means BIP 66 only Version 4 means CLTV only Version 5 means both
If (Version 3 + version 5) > 95%, reject 2 & 4 If (Version 4 + version 5) > 95%, reject 2 & 3
For 2 options at the same time, this isn't much extra overhead.
On Fri, Jun 26, 2015 at 12:52 AM, Eric Lombrozo <elombrozo@gmail•com> wrote:
Quoted text (52 lines)
> Please do it. > On Jun 25, 2015 3:33 PM, "Peter Todd" <pete@petertodd•org> wrote: > >> 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 >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation•org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >
On Thu, Jun 25, 2015 at 06:33:44PM -0400, Peter Todd wrote:
Quoted text (2 lines)
> Thoughts? If there are no objections I'll go ahead and write that code, > using the same thresholds as BIP66.
I've opened a pull-req to deploy CHECKLOCKTIMEVERIFY via the IsSuperMajority() mechanism:
https://github.com/bitcoin/bitcoin/pull/6351
Final step towards CLTV deployment on mainnet.
I've copied the logic and tests from the previous BIP66 (DERSIG)
soft-fork line-by-line for ease of review; any code review applicable to
BIP66 should be applicable to BIP65.
Once merged I'll prepare a backport of the soft-fork logic for the
v0.10.x branch as well.On Sun, Jun 28, 2015 at 9:50 PM, Peter Todd <pete@petertodd•org> wrote:
Quoted text (16 lines)
> On Thu, Jun 25, 2015 at 06:33:44PM -0400, Peter Todd wrote: > > Thoughts? If there are no objections I'll go ahead and write that code, > > using the same thresholds as BIP66. > > I've opened a pull-req to deploy CHECKLOCKTIMEVERIFY via the > IsSuperMajority() mechanism: > > https://github.com/bitcoin/bitcoin/pull/6351 > > Final step towards CLTV deployment on mainnet. > > I've copied the logic and tests from the previous BIP66 (DERSIG) > soft-fork line-by-line for ease of review; any code review applicable > to > BIP66 should be applicable to BIP65. >
ACK on merging using IsSuperMajority.