Bitcoin Timelocks.
Bitcoin transactions have restrictions restricting spending until a point in time in the future referred to as time locks. In this article, we learn about timelocks in Bitcoin.
In Bitcoin timelocks are restrictions placed on transactions or transaction outputs that restrict spending until a specific point in the future has passed. In a Bitcoin transaction, this is implemented using the nLocktime field. Timelocks enable users to lock funds until a specific date passes. Just like paper cheques, timelocks allow bition users to be able to postdate transactions on the blockchain. The use of timelocks has also allowed complexity in multistep smart contracts.
In this article, we learn about timelocks and the different types of time lock implemented in the Bitcoin blockchain.
Timelocks.
Timelocks serve as a means to specify conditions to be met for transactions to be validated and added to the blockchain by miners. It is a type of smart contract primitive that references the block height or specific time a transaction is to be processed. In this case, when the block height or the specified time is reached, miners act on the transaction by including it in the hash of the Merkle tree, and the transaction is added to the blockchain.
In most bitcoin transactions, the default timelock is usually 0x00000000 which is 0 or 0xFFFFFFFF(4294967295).
Bitcoin implements four major smart contract primitive options namely, nLocktime, nSequence, OP_CHECKLOCKTIMEVERIFY(OP_CLTV), and OP_CHECKSEQUENCEVERIFY(OP_CSV).
Key Attributes of Timelocks.
Timelocks in Bitcoin have three common attributes, these include;
Location Timelocks can be based on a location, for example, a timelock can be at a specific transaction level or script level. A timelock at a transaction level will not be validated until a specified time. This applies even if the signature is valid. A timelock on a script level makes sure that the script evaluation of a transaction is invalid until the transaction has been locked. While the former(transaction-level timelock) specifies when a transaction is to be executed, the latter dictates the transactions that can be validated on the blockchain.
Orientation In terms of orientation/target, we have absolute and relative timelocks. Both specify a specific time in the future when a transaction is to be validated. The difference is that, with absolute time locks, there is a specific set time, until then the transaction remains invalid. On the other hand, relative locks use a countdown, for example, a transaction could only be validated after X number of hours or days.
Metric Timelocks can also be based on metrics, specifically two, the first if the block number and the second is the block time stamps. With block numbers, a transaction remains invalid until a certain block number is reached. In terms of block time stamps, a transaction remains invalid until a specific block time passes.
Types of Time Locks.
In this section, we look at the various timelocks in the Bitcoin protocol; 1. nLocktime This is a script-level absolute timelock. It was the first to be implemented by Satoshi Nakamoto in the original bitcoin software. It can be found here. When this parameter is used in a transaction, the transaction remains invalid until the specified time passes. If the specified nLockTime is less the 500 million, the parameter is interpreted as the block height meaning that the transaction is only validated after a specific block number is reached, otherwise if the value is greater than 500 million, it is interpreted as a UNIX time stamp, in this case, the transaction remains invalid until a specific timestamp has passed.
nLockTime can block a transaction for up to 9.500 years using block numbers and 2.106 years using time stamps. In most wallets, this value is usually set to 0 indicating that the transaction is validated immediately after it is constructed.
2. nSequence This was introduced in mid-2016 in a BIP specifically the BIP68 soft fork. Here sequence numbers are used to establish relative time locks at the transaction level. It allows an entry to specify the earliest time that it can be added to a block depending on how long ago the output spent by the input was included in a block on the chain. nSequence allows us to use several different time conditions within one transaction. Here a transaction is only valid when all conditions are met otherwise it is invalid.
It is similar to nLocktime with the distinction that the time here is shortened compared to the former. nSequence uses 18 out of 32 bits. 14 are reserved for future implementations and out of the 18, 16 encode the blocking time. nSequence timelocks are limited to 65535 block units and 18 hours(64800 seconds).
3. OP_CHECKLOCKTIMEVERIFY(OP_CLTV) These provide absolute time blocking at the script level. They were implemented in BIP 65 introduced in late 2015. The can be used to timelock a transaction until a specific date after which the transaction can be validated. It is commonly used to lock funds sent to a recipient until a specific time passes after which the recipient can spend the funds.
These also allow users to change the authentication parameters for multi-signature wallet addresses. Consider the case where we have a multi-signature wallet address of 2-of-3, CLTV can be used to change the parameter when conditions are met to 1-of-3. In this case, a person can recover funds under predefined conditions as specified in the transaction.
4. OP_CHECKSEQUENCEVERIFY(OP_CSV) This is a script-level relative timelock also part of BIP 68 although described in BIP 112. It was implemented in mid-2016. It is similar to CLTV except instead of checking time like CLTV, CSV checks the value that is at the top of the stack with the input fields.
When this opcode is called, the script will fail unless nSequence indicates that a relative amount of lock time that is equal to or greater than the provided parameter provided in the CSV opcode passes to make sure that the transaction can be included in a valid block when the CSV timelock expires.
Here transactions can be blocked for a maximum of 65535 blocks(455 days) or a maximum of 388 days(33523200 seconds)
Summary
The lock time in a transaction specifies the earliest time a transaction can be added to the blockchains. When set to 0, it means that the transaction should execute immediately, otherwise if the lock time is a nonzero value and is less than 500 million, the transactions will not be added to the chain until the specified time passes. In Bitcoin timelocks the following smart contract primitive options; nLocktime, nSequence, OP_CHECKLOCKTIMEVERIFY(OP_CLTV), and OP_CHECKSEQUENCEVERIFY(OP_CSV).