CHECKLOCKTIMEVERIFY (CLTV) Soft Fork
January 11, 2018
Uniform Fiscal Object is playing catch up with Bitcoin technology and is doing so fast, only a few months ago the network was on the 0.8 codebase, in the first week of 2018 the 0.11 based client was released, the roadmap plans for a new client based on the next Bitcoin codebase to be released each month until UFO is on par with Bitcoin. The 0.11 release brings several improvements over the previous 0.10 release from the previous month, including an update to eHRC and two soft forks being CLTV, also known as CHECKLOCKTIMEVERIFY (BIP65) and Strict DER Encoding (BIP66), the former of these two soft forks is the more interesting and the focus of this article.
A soft fork is a change to the network that even though old clients may not be able to fully make use of the change can still follow the same blockchain and work as expected, the rest of the network may reject blocks from those older clients once a certain percentage of newly mined blocks have signaled support for the soft fork. The change brought in by the soft fork will activate once set criteria are met. For BIP65 as an example, once 75% of the last 1,000 blocks in the UFO network are version 4, then the soft fork will activate, allowing the network to make use of CHECKLOCKTIMEVERIFY, once the network is at 95% of the last 1,000 blocks any block with a version less than 4 will be rejected.
Hard forks are a change that is not compatible with older versions of the client, once the hard fork has been reached, whether it is based on time or block height, it will be on a chain that old clients are not able to follow, it is preferable to avoid hard forks as everyone has to upgrade so this generates more work.
It is worth noting that the 0.11 client includes a hard fork that improves eHRC and is expected to be the last fork of its kind on the UFO network, this hard fork has been back ported to the older clients with version numbers 0.8.9, 0.9.2 and 0.10.1. Even though 0.8 and 0.9 have been updated for the hard fork they do not support the changes made by the BIP65 soft fork, so will not be able to used in solo mining once the network is 95% upgraded as explained above. These updated older versions are only available as source code on GitHub and need to be compiled manually, binaries for 0.11 are provided via this website or the GitHub release page.
On the surface CHECKLOCKTIMEVERIFY is not particularly exciting, it is a new opcode that prevents a transaction from being spendable until some time in the future, however we had this already in the form of nLockTime, the problem with nLockTime is that it could not prove that it was impossible to spend an output until that output could be spent. CHECKLOCKTIMEVERIFY improves nLockTime, by using both we can verify that the output is unspendable until the block height or time as specified in the time lock has been reached.
This has a few applications other than simply locking funds till later, you can use this time lock with multiple signature transactions creating a reliable escrow between two or more parties, non-interactive time-locked refunds, two-factor wallets where you hold one key and the service holds the other, if the service disappears the funds can be moved once the time lock expires and payment channels.
A Spillman style payment channel can be set up between two parties, one transaction creates a time locked fund and a second transaction releases that fund, a refund transaction can be created so that the payor can get their funds back if the payee disappears. This type of payment channel was vulnerable to the malleability issue that famously affected MtGox and caused them to go bankrupt, the malleability issue is that transaction hashes could be changed. The refund transaction in a Spillman style payment channel was vulnerable to the malleability issue, invalidating the refund transaction and making this no longer a trustless payment channel, as the customer would then have to rely on the merchant to refund if needed.
CHECKLOCKTIMEVERIFY does not solve the malleability issue directly but does allow for new style of payment channel where it is no longer a concern. In this new type of payment channel the merchant gives the customer their public key, the customer uses this key with their own to create a P2SH address, both parties are required to sign any transaction from the P2SH address and just the customer can sign transactions to spend the P2SH transaction but only after the locktime has expired. The customer than generates the deposit transaction to the P2SH address. Both parties can now sign to move the funds or the time will expire and the funds can be spent by the customer. If a refund transaction is created and suffers from malleability, then the customer can use their own private key to create a new transaction to move those funds, this type of payment channel was not possible before CHECKLOCKTIMEVERIFY.
This feature has been used by decentralised exchanges to allow users to trade between each other without having to rely on a central service, but by using native blockchain software features to create transactions between users that can either be fully committed if both parties fulfill the requirements, or refunded if one or both fail to meet them. There are now several exchanges making good use of this features and once UFO activate the CHECKLOCKTIMEVERIFY soft fork it can participate on these exchanges.