Timelock: Difference between revisions
added warning about not locking up coins too far in the future, added note about time locking investment bitcoins, added link to reddit discussion of the uses of CSV |
m →Relative locktime: edited ref |
||
| (10 intermediate revisions by 5 users not shown) | |||
| Line 1: | Line 1: | ||
A '''Timelock''' is a type of smart contract primitive that restricts the spending of some bitcoins until a specified future time or block height. Timelocks feature prominently in many Bitcoin [[Contracts|smart contracts]], including [[payment channels]] and [[Hashed Timelock Contracts|hashed timelock contracts]]. It can also be used to lock-up bitcoins held as an investment for a period of months or years. Time lock is also used to make [[fee sniping]] less profitable. | A '''Timelock''' is a type of smart contract primitive that restricts the spending of some bitcoins until a specified future time or block height. Timelocks feature prominently in many Bitcoin [[Contracts|smart contracts]], including [[payment channels]] and [[Hashed Timelock Contracts|hashed timelock contracts]]. It can also be used to lock-up bitcoins held as an investment for a period of months or years. Time lock is also used to make [[fee sniping]] less profitable, and for [[Techniques_to_reduce_transaction_fees#Pre-computed_fee_bumping|trustless precomputed fee bumping]]. | ||
== Primitives == | == Primitives == | ||
| Line 7: | Line 7: | ||
''Main article: [[nLockTime]]'' | ''Main article: [[nLockTime]]'' | ||
In the original Bitcoin release, nodes would not relay nor mine transactions with nLockTime equal to or greater than the current block height (unless all inputs' sequence numbers were 0xffffffff), however they would accept blocks containing transactions with any value of nLockTime. In Bitcoin 0.1.6, the interpretation of nLockTime was adjusted to also allow time-based locking.<ref>https://github.com/bitcoin/bitcoin/commit/dd519206a684c772a4a06ceecc87c665ad09d8be#diff-23cfe05393c8433e384d2c385f06ab93R406</ref> Then, starting from block 31001 (December of 2009), the nLockTime restrictions were activated as a rule that also applied to block acceptance.<ref>https://github.com/bitcoin/bitcoin/commit/dd519206a684c772a4a06ceecc87c665ad09d8be#diff-118fcbaaba162ba17933c7893247df3aR1222</ref> Later, in July of 2016, the time based locks were changed to operate on the [[median time past]] instead of the block's timestamp.<ref>https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki</ref> | |||
Although every transaction contains the nLockTime field, every wallet up until recently set nLockTime to <code>0</code>, meaning the transaction was valid in any block. Starting with [[Bitcoin Core]] 0.11.0, every normal transaction automatically generated by began including an nLockTime set to a recent block height as a way to make hypothesized [[fee sniping]] less profitable<ref name="anti_fee_sniping"/>; other wallets are recommended to do the same. | Although every transaction contains the nLockTime field, every wallet up until recently set nLockTime to <code>0</code>, meaning the transaction was valid in any block. Starting with [[Bitcoin Core]] 0.11.0, every normal transaction automatically generated by began including an nLockTime set to a recent block height as a way to make hypothesized [[fee sniping]] less profitable<ref name="anti_fee_sniping"/>; other wallets are recommended to do the same. Approximately 20% of all bitcoin transactions set a nLockTime value different from zero<ref>https://p2sh.info/dashboard/db/blocks-statistics?panelId=4&fullscreen&orgId=1</ref> as of early-2019. | ||
=== CheckLockTimeVerify === | === CheckLockTimeVerify === | ||
| Line 15: | Line 15: | ||
In late 2015, the BIP65 soft fork<ref name="bip65"/> redefined the NOP2 opcode as the [[CheckLockTimeVerify]] (CLTV) opcode, allowing 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. Since a transaction may only be included in a valid block if its nLockTime is in the past, this ensures the CLTV-based timelock has expired before the transaction may be included in a valid block. | In late 2015, the BIP65 soft fork<ref name="bip65"/> redefined the NOP2 opcode as the [[CheckLockTimeVerify]] (CLTV) opcode, allowing 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. Since a transaction may only be included in a valid block if its nLockTime is in the past, this ensures the CLTV-based timelock has expired before the transaction may be included in a valid block. | ||
CLTV is currently used in [[CLTV-style payment channels]]. | CLTV is currently used in [[Payment_channels#CLTV-style_payment_channels|CLTV-style payment channels]] and [[fidelity bonds#Time-Locked Fidelity Bond|Time-Locked fidelity bonds]]. | ||
=== Relative locktime === | === Relative locktime === | ||
In mid-2016, the | In mid-2016, the [[BIP 0068]]/[[BIP 0112|112]]/[[BIP 0113|113]] soft fork gave consensus-enforced meaning to some values in the [[nSequence]] field<ref name="bip68"/> that is a part of every transaction input, creating a "relative locktime".{{citation needed}} This allowed 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. | ||
=== CheckSequenceVerify === | === CheckSequenceVerify === | ||
| Line 29: | Line 29: | ||
== Far-future locks == | == Far-future locks == | ||
It is not advised to lock up bitcoins into the far future because it takes on risk of the bitcoin network changing. For example, if there were an ECDSA or RIPEMD160 algorithm break that made any coins spendable with a few months of | It is not advised to lock up bitcoins into the far future because it takes on risk of the bitcoin network changing. For example, if there were an ECDSA or RIPEMD160 algorithm break that made any coins spendable with a few months of CPU time, the network might need to to prohibit moving old unspent coins after some transition, but long locktimed coins could not make such a transition. | ||
OP_CheckSequenceVerify allows locking for at most 65535 blocks (about 455 days) or for at most 65535*512 seconds (about 388 days). OP_CheckLockTimeVerify could be used to lock up coins for several centuries. | OP_CheckSequenceVerify allows locking for at most 65535 blocks (about 455 days) or for at most 65535*512 seconds (about 388 days). OP_CheckLockTimeVerify could be used to lock up coins for several centuries. | ||
Occasionally coins have been accidentally locked up for a long time.<ref>https://github.com/OutCast3k/coinbin/issues/35#issuecomment-167440998</ref> | |||
== See Also == | == See Also == | ||
Latest revision as of 16:54, 8 April 2022
A Timelock is a type of smart contract primitive that restricts the spending of some bitcoins until a specified future time or block height. Timelocks feature prominently in many Bitcoin smart contracts, including payment channels and hashed timelock contracts. It can also be used to lock-up bitcoins held as an investment for a period of months or years. Time lock is also used to make fee sniping less profitable, and for trustless precomputed fee bumping.
Primitives
nLockTime
Main article: nLockTime
In the original Bitcoin release, nodes would not relay nor mine transactions with nLockTime equal to or greater than the current block height (unless all inputs' sequence numbers were 0xffffffff), however they would accept blocks containing transactions with any value of nLockTime. In Bitcoin 0.1.6, the interpretation of nLockTime was adjusted to also allow time-based locking.[1] Then, starting from block 31001 (December of 2009), the nLockTime restrictions were activated as a rule that also applied to block acceptance.[2] Later, in July of 2016, the time based locks were changed to operate on the median time past instead of the block's timestamp.[3]
Although every transaction contains the nLockTime field, every wallet up until recently set nLockTime to 0, meaning the transaction was valid in any block. Starting with Bitcoin Core 0.11.0, every normal transaction automatically generated by began including an nLockTime set to a recent block height as a way to make hypothesized fee sniping less profitable[4]; other wallets are recommended to do the same. Approximately 20% of all bitcoin transactions set a nLockTime value different from zero[5] as of early-2019.
CheckLockTimeVerify
In late 2015, the BIP65 soft fork[6] redefined the NOP2 opcode as the CheckLockTimeVerify (CLTV) opcode, allowing 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. Since a transaction may only be included in a valid block if its nLockTime is in the past, this ensures the CLTV-based timelock has expired before the transaction may be included in a valid block.
CLTV is currently used in CLTV-style payment channels and Time-Locked fidelity bonds.
Relative locktime
In mid-2016, the BIP 0068/112/113 soft fork gave consensus-enforced meaning to some values in the nSequence field[7] that is a part of every transaction input, creating a "relative locktime".[citation needed] This allowed 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.
CheckSequenceVerify
Also part of the BIP68/112/113 soft fork was the CheckSequenceVerify opcode[8], which 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. Since an input may only be included in a valid block if its relative locktime is expired, this ensures the CSV-based timelock has expired before the transaction may be included in a valid block.
CSV is used by Lightning Network transactions.
Far-future locks
It is not advised to lock up bitcoins into the far future because it takes on risk of the bitcoin network changing. For example, if there were an ECDSA or RIPEMD160 algorithm break that made any coins spendable with a few months of CPU time, the network might need to to prohibit moving old unspent coins after some transition, but long locktimed coins could not make such a transition.
OP_CheckSequenceVerify allows locking for at most 65535 blocks (about 455 days) or for at most 65535*512 seconds (about 388 days). OP_CheckLockTimeVerify could be used to lock up coins for several centuries.
Occasionally coins have been accidentally locked up for a long time.[9]
See Also
- coinb.in's time-locked page javascript page for creating time-locked bitcoin wallets.
- Reddit discussion of the possible uses OP_CHECKSEQUENCEVERIFY
References
- ↑ https://github.com/bitcoin/bitcoin/commit/dd519206a684c772a4a06ceecc87c665ad09d8be#diff-23cfe05393c8433e384d2c385f06ab93R406
- ↑ https://github.com/bitcoin/bitcoin/commit/dd519206a684c772a4a06ceecc87c665ad09d8be#diff-118fcbaaba162ba17933c7893247df3aR1222
- ↑ https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki
- ↑ Bitcoin Core 0.11.0 release notes
Bitcoin.org
Retrieved 2016-11-06 - ↑ https://p2sh.info/dashboard/db/blocks-statistics?panelId=4&fullscreen&orgId=1
- ↑ BIP65: OP_CHECKLOCKTIMEVERIFY
Peter Todd
Retrieved 2016-04-12 - ↑ BIP68: Relative lock-time using consensus-enforced sequence numbers
Mark Friedenbach, BtcDrak, Nicolas Dorier, and kinoshitajona
Retrieved 2016-04-12 - ↑ BIP112: CHECKSEQUENCEVERIFY
BtcDrak, Mark Friedenbach, Eric Lombrozo
Retrieved 2016-04-12 - ↑ https://github.com/OutCast3k/coinbin/issues/35#issuecomment-167440998