Published on: 2015-08-04T16:54:39+00:00
On June 25, 2015, Peter Todd proposed the deployment of CheckLockTimeVerify (CLTV) considering its benefits to scalability solutions. He suggested using the existing median block version mechanism for CLTV as it is well-tested and understood. Todd stated that there is no lack of consensus on this proposal. He further added that if another soft-fork is proposed prior to BIP65 enforcement, they have the option of setting in motion yet another soft-fork as the median mechanism only requires forks to be serialized in sequence. The CLTV code 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.The adoption of BIP66 is close to 95% and will soon be enforced for all blocks. This leads to the consideration of how CheckLockTimeVerify (CLTV) will be implemented, especially given its benefits to scalability solutions such as payment channels. Peter Todd, a co-author of the Version bits BIP proposal, suggests that CLTV should be deployed sooner as the implementation of the BIP proposal will be complex. The CLTV code has been extensively reviewed and tested, including running in production on Viacoin for six months. Peter Todd proposes using the existing median block version mechanism previously used for nVersion=2 and nVersion=3 soft-forks for CLTV. This approach is well-tested and understood, allowing for easy backporting to v0.10.x (even 0.9.x) with low risk for rapid deployment. If another soft-fork is proposed before BIP65 enforcement, nVersion=4 can be set in motion as the median mechanism only requires forks to be serialized in sequence. Multiple soft-forks can be "in-flight" at the same time.
Updated on: 2023-08-01T13:54:09.592100+00:00