CheckLockTimeVerify (CLTV) has been merged into Bitcoin Core. This is generally considered great news, because it means that Bitcoin's potential has improved drastically. In particular, the patch that was proposed by Bitcoin Core developer Peter Todd allows for the proper establishment of payment channels. This means that Bitcoin users will be able to transact cheaper, faster, and at a higher volume than usual, while maintaining all of the advantages as offered by the blockchain.
What is CheckLockTimeVerify?
The CLTV concept is fairly simple. Essentially, it allows users to create a bitcoin transaction of which the transaction outputs are spendable only at some point in the future. As such, the bitcoin sent in that transaction are time-locked until either a specified date, or until a certain number of blocks has been mined.
This in itself is a neat addition that can be used for various purposes. It would be easy, for example, for a dad to grant his son bitcoin as a present, but which the son could use only when he turns 18. Or it could perhaps be used to pay rent on a specific date.
These sorts of applications are relatively straightforward. But CLTV gets really interesting when combined with additional Bitcoin tricks.
What are payment channels?
As perhaps its most important function, CLTV is necessary for properly functional payment channels. These channels are effectively a series of “off-chain” transactions, that benefit from all the security of typical on-chain transactions, and with some added benefits.
Lets say that Bob streams a video, which costs one satoshi per second to watch, and Alice wants to watch that video. It would not be a great idea to use regular bitcoin transactions worth a satoshi for each individual second streamed, since a typical transaction fee costs more than one satoshi, and transactions confirm only once every 10 minutes on average. On top of that, the Bitcoin network is currently limited to a handful of transactions per second, which means that Alice's transactions would be a huge burden on the system. Moreover, only a handful of people could watch Bob's stream at the same time before the whole Bitcoin network clogged up.
Therefore, Alice and Bob decide to open a payment channel instead. Before she starts watching the video, Alice sends – say – one bitcoin to a multi-signature address. And Alice and Bob each control one of two keys required to send funds from that address.
Now, Alice wants to start watching the video. She signs a transaction from the multisig address, in which she sends 99,999,999 satoshi's to herself, and one satoshi to Bob. Bob could now sign this transaction at any time, and claim the satoshi attributed to him. Therefore, he allows Alice to watch one second of his stream.
However, and importantly, Bob doesn't actually claim his satoshi right away, because he believes Alice will probably want to watch longer than one second. And here comes the trick: Alice signs a new transaction from the same multisig address, this time sending herself 99,999,998 satoshi's, and sending Bob 2 satoshi's. Once again, Bob could sign this transaction at any time, and claim the two satoshi's attributed to him. But he could not sign and broadcast both transactions, as that would constitute a double spend! Therefore, he would have to choose. And unless Bob is keen on losing money, he would always sign the biggest transaction. If he does, he will effectively receive one satoshi per second – even though he didn't actually receive a new transaction worth a single satoshi every second.
This process can be repeated as long as Bob doesn't sign his part of the transactions. So for every second that Alice watches the video, Bob can claim an additional satoshi, with no need to wait for confirmations on the blockchain. And since only one transaction – the last one for Bob to claim – is actually recorded on the blockchain, Alice and Bob do not clog up the Bitcoin network with micro-transactions, and they need to pay only a single mining fee.
So why do payment channels require CLTV?
There is one problem. What if, for some unforeseeable reason, Bob cannot or will not transmit the transaction at all? Perhaps because he falls of a cliff, or he loses his private key, or maybe he holds Alice's bitcoin ransom and demands a bigger cut, or some other reason. In that case, Alice will have lost her bitcoin, even if she didn't watch Bob's video stream long enough for it to be worth a bitcoin.
That's where CLTV comes in.
Alice can add CLTV to the initial bitcoin transaction, using it to send the whole bitcoin back to her own address. This transaction is validated – for example – one day later, but only if Alice and Bob didn't sign the multi-signature transaction before that time. Now, if Bob doesn't sign the transaction at all for whatever reason, Alice can sign it by herself and is guaranteed to get her money back.
Worst case scenario for Alice is that she would need to wait a day. She might be a bit annoyed, but she will not lose any money. As such, the whole process has been made completely trustless.
Activation
On a final note, it should be mentioned that the CLTV concept is actually not new at all; it has existed in Bitcoin since the early days. With the previous incarnation of the time-locked concept, however, locked transactions were not actually included in the blockchain until a certain point in time. Rather, they were kept by Alice and (more importantly) Bob, to transmit over the Bitcoin network once the time-lock expired.
By actually baking it into the protocol as CLTV does, the payment channel process is better streamlined and more robust. Perhaps most importantly, it disables payment channel failures caused by transaction malleability .
Although CLTV is officially merged into Bitcoin Core now, it's not quite in use yet. First, it will be rolled out with the latest version of Bitcoin Core: 0.12. This is scheduled for early 2016. Alternatively, CLTV might be implemented in an update to Bitcoin Core 0.11, in which case CLTV will be available at an earlier (so-far unspecified) date.
After that, a super-majority of Bitcoin miners – 75 percent of hashing power – will need to signify they are ready and prepared to allow CLTV. This seems unlikely to cause much trouble, as there is no real opposition to the patch.
Thanks to Blocktrail CTO Ruben de Vries and Bitonic CEO Jouke Hofman for added feedback.