Timelocks
Timelocks allow for limits on when bitcoin can be spent. There are absolute and relative timelocks, existing on the transactional and UTXO level.
A time-locked Bitcoin transaction is one that is only valid after a certain period of time. Such timelocks are used extensively in the Lightning Network and broadly fall under two categories, absolute timelocks and relative timelocks.
Absolute Timelock | Relative Timelock | |
Transaction Level | nLockTime | nSequence |
UTXO Level | CheckLockTimeVerify | CheckSequenceVerify |
(or Script Level) | CLTV | CSV |
Absolute timelocks restrict a transaction to only be valid after a certain point in time, for instance a time stamp or a block height. Today, block height is primarily used.
The most commonly used timelock, nLocktime, has been a feature of bitcoin since its inception. Each bitcoin transaction specifies a nLocktime close to the most recently mined bitcoin block, meaning a miner can not include this transaction as part of a block reorg concerning previous blocks. It only began to be widely used around 2016, when it was included in Bitcoin Core 0.11.
Check-locktime verify (CLTV) is the timelock used in Hash Timelock Contracts (HTLC), which make up an important part of the mechanism behind Lightning Network transactions. CLTV is an absolute timelock that uses block height to determine when transactions become valid.
Differences between timelocks of incoming and outgoing HTLCs, called CLTV deltas, ensure that an incoming HTLC that is resolved on-chain can also be resolved in time in the outgoing channel.
CLTV differs from nLocktime in that it enforces the timelock on the script level, while the nLocktime timelock is enforced at the time of the signature. So while it is possible to add nLocktime when spending any coin, a CLTV condition has to be defined at the time the address is created, and the owner cannot alter it anymore.
CLTV was introduced with BIP65 and activated through a soft fork in 2015. In addition to block height, the protocol also allows CLTVs to use timestamps to define the validity of transactions.
There’s no limit to how far in the future a CLTV transaction can be locked.
A relative timelock describes a period after which a transaction becomes valid, rather than a fixed timestamp of block height. This period refers to the number of blocks or seconds between inputs being confirmed on the blockchain, and the outputs being valid.
Analogous to nLocktime, nSequence is enforced at the transaction level, rather than the script level. That difference means that you can add information about the minimum number of blocks that need to have passed since its input was confirmed when signing the transaction that spends it.
CSV plays an important role in commitment transactions in the Lightning Network, ensuring that the funds from a non-cooperative closure can only be recovered a certain number of blocks after the force closure has been initiated. CSV is the key component of allowing Lightning Network channels to exist indefinitely, rather than for a limited time.
The “CSV Delay”, defined at a channels’ creation, is dependent on its size. It can also be configured manually with the –max_local_csv flag of lncli openchannel. It expresses the number of blocks that need to pass before the initiator of a force close can spend their side of the balance, while the other party can always spend their funds immediately.
Relative timelocks can also be used to prevent transactions having unconfirmed parents, or pinning attacks, in which a transaction is prevented from being confirmed by submitting large, low-paying descendants.
Unlike CLTV, CSV can only be defined for up to 65535 blocks (about 15 months).
No timelocks exist that make a transaction invalid after a certain time. This follows a design principle of bitcoin that transactions can only become more permissible over time, not more restrictive. This principle is supposed to prevent funds being destroyed by becoming locked forever.
Last modified 3mo ago