Bitcoin Timelocks in a nutshell
TL;DR:
| Absolute Timelock | Relative Timelock |
-------------------- | ------------------- | ------------------- |
Transaction Level | nLockTime | nSequence |
-------------------- | ------------------- | ------------------- |
UTXO Level | CheckLockTimeVerify | CheckSequenceVerify |
(or Script Level) | CLTV | CSV |
------------------------------------------------------------------Before diving into the specific introduction of each different timelock, let me go through the technical terminologies first.
Terminologies
- Absolute timelock: The locktime will be set in an absolute way. It can be interpreted as two ways: by block height or by the time, which will be Unix Epoch timestamp. If it is interpreted as a block height, it will be recorded as at block 479083. If it is interpreted as the time, it will be set as 1507574976, meaning 10/09/2017 @ 6:49pm (UTC).
(Convert the timestamp: https://www.unixtimestamp.com/index.php) - Relative timelock: Same as the absolute timelock, the relative timelock can also be presented by either block height or by the time. For example, if the timelock is interpreted as the block height, the timelock will be like after 144 blocks. If it is interpreted as the time, it will be set as after 86400 seconds. All are relative to the parent block!
- Transaction Level timelock: defines the earliest time that the transaction can be added into the blockchain. That is, it allows the signer to create a transaction, which will only be valid in the future. Additionally, the tx-level timelock is also a field of the bitcoin transaction.
- UTXO or Script Level timelock: This kind of timelock will be added into the script of the UTXO, instead of being a field of the transaction. It allows the UTXO (Unspent Transaction Output) to be spendable only after the specified time/blocks have elapsed/been generated.
After explaining the terminologies, let’s go through each timelock. I’ll introduce through the time that this specific timelock been added into the Bitcoin.
nLockTime (Transaction Locktime)
- nLockTime, as the transaction-level locktime feature, is part of the original Bitcoin implementation. That is, looking into the Bitcoin transaction, you can find a field called “locktime”, which is exactly the nLockTime.
“nLockTime is a field that specifies the earliest time a transaction may be added to a valid block.”
- As I’ve mentioned earlier, all timelocks can be implemented by either unix time or by blockheight. For example, if a transaction has a “3-day nLockTime”, that means this transaction can only be valid after three days and can be added to a block and relay over the network after three days since this transaction has been created.
- Remember, nLockTime is an absolute timelock, so it should be recorded in an absolute way. If nLockTime is recorded below 500 million, it is interpreted as the specific block height. For example, if a transaction’s nLockTime is set to 49,999,999, meaning that this transaction can only be added to the blockchain validly at block 49,999,999. If nLockTime is set larger than 500 million, it means that the timelock is recored as unix timestamp, and this transaction can only be valid after the specified time.
# This is a Bitcoin transaction, and there's actually a field named "locktime".{
"txid" : "c80b343d2ce2b5d829c2de9854c7c8d423c0e33bda264c4013\
8d834aab4c0638",
"hash" : "c80b343d2ce2b5d829c2de9854c7c8d423c0e33bda264c40138d834aab4c0638",
"size" : 85,
"vsize" : 85,
"version" : 1,
"locktime" : 0,
"vin" : [
{
"txid" : "3f4fa19803dec4d6a84fae3821da7ac7577080ef75\
451294e71f9b20e0ab1e7b",
"vout" : 0,
"scriptSig" : {
"asm" : "",
"hex" : ""
},
"sequence" : 4294967295
}
],
"vout" : [
{
"value" : 49.99990000,
"n" : 0,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 cbc20a7664f2f69e5355a\
a427045bc15e7c6c772 OP_EQUALVERIFY OP_CHECKSIG",
"hex" : "76a914cbc20a7664f2f69e5355aa427045bc15e\
7c6c77288ac",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"mz6KvC4aoUeo6wSxtiVQTo7FDwPnkp6URG"
]
}
}
]
}
- nLockTime set to 0 means that the transaction can be added into a block and be appended to the blockchain immediately.
Check Lock Time Verify (CLTV)
- CLTV, an absolute UTXO-level timelock, was added to Bitcoin by a soft fork upgrade in Dec 2015, based on the specification BIP65. CLTV is implemented in the Bitcoin’s script, so it will appear in the Bitcoin’s script as OP_CHECKLOCKTIMEVERIFY.
“CLTV allows transaction outputs (rather than whole transactions) to be encumbered by a timelock.”
“When the CLTV opcode is called, it will cause the script to fail unless the nLockTime on the transaction is equal to or greater than the time parameter provided to the CLTV opcode.”
- To make it simple, what makes CLTV different from nLockTIme is that CLTV restricts the UTXO (spendable bitcoin) to be spendable only after the specified time/blocks has elapsed/been generated, while nLockTime limits the transaction to be valid and can be added to the block / blockchain after certain amount of time.
- Why need CLTV? Here’s a good explanation. (P.S. I’ll try to explain the concept of payment channels and the limitations of nLockTime in the next series of Lightning Network explanation!)
- Application: HTLC in the Lightning Network
(I’ll explain this in my article of Lightning Network!)
Relative Timelocks
- The relative timelcoks, including nSequence and CSV , were activated at May 2016 as a soft fork upgrade, based on the specification BIP68, BIP112 and BIP113.
- Why need relative timelocks instead of using the absolute timelocks, nLockTime and CLTV?
- Relative timelocks are much more flexible, resticting transactions/UTXOs to be valid/spendable after the relative time has elapsed, based on the time that the parent blocks or transactions to be added on the blockchain. (Don’t worry if it sounds quite confusing right now. I’ll give some specific examples later!)
Sequence Number (nSequence)
- nSequence, the sequence number in Bitcoin, is a transaction-level relative timelock, added by the soft work upgrade. It is now in every transaction’s input, represented as “sequence”.
“nSequence allows an input to specify the earliest time it can be added to a block based on how long ago the output being spent by that input was included in a block on the block chain.”
- For example, if a transaction has one input with nSequence set to 10 blocks, it means that this transaction can only be valid after 10 blocks have been added to the blockchain from the time that the referenced UTXO was mined.
- To put it more simply, consider there’s two transactions, A Transaction and B Transaction, and B Tx is going to spend the Bitcoin from A Transaction’s output. If B transaction’s input has a sequence number of 10 blocks, then it means that B transaction can only be added to the (child) block after 10 blocks have been generated since the time A Transaction was included into the (parent) block.
P.S. I hope that this explanation is clear enough, if it isn’t, just leave a comment and I’ll try my best to explain it to you. :)
Check Sequence Verify (CSV)
- CSV, added together with nSequence at the soft fork at May 2016, is a UTXO-level relative timelock. It shows up in the Bitcoin script as the opcode OP_CHECKSEQUENCEVERIFY.
“CSV provides for relative locktime the same feature CLTV provides for absolute locktime.”
“When the CSV opcode is called, it will cause the script to fail unless the nSequence on the transaction indicates an equal or greater amount of relative locktime has passed than the parameter provided to the CSV opcode.”
- Basically what CSV does to the UTXO is exactly the same way as the CLTV, but just in an relative way.
- CSV restricts the UTXO to be spendable after certain amount of time/blocks has elapsed relatively to the time that the UTXO was mined. Simply speaking, imagine the CSV as an lock (or more technically speaking, encumbrance) of an UTXO. For example, 100 blocks. What it means is that this UTXO can only be spent after 100 block time has passed since the UTXO was mined.
- Think of the CSV timelock as a countdown timer, when the UTXO was mined (or you can say that when the transaction was added into the block/blockchain), for example at block height 5000, CSV of 100 blocks started to count down. Only after 100 blocks has been added behind the block 5000, can this UTXO be spendable. In other words, this UTXO can only be spent at least after the block 5100, which is 100 blocks later than the UTXO was mined.
- Application: RSMC in Lightning Network.
Conclusion
That’s it! The brief introduction to four different kind of useful timelocks in Bitcoin. If you’re not familiar with Bitcoin’s Lightning Netowrk, you might get really confused about why these timelocks are super powerful, and what do I mean for something like HTLC, RSMC for Lightning Network as the application of CLTV and CSV.
Everything about the Lightning Network will be introduced and explained comprehensively in my next series of article, mainly about the Lightning Network. Stay tuned!
Thanks for reading!
Robin Hung
