Timelock - Revision history

Tris T7: /* Relative locktime */ edited ref

2022-04-08T16:54:01Z

Relative locktime: edited ref

← Older revision		Revision as of 16:54, 8 April 2022
Line 19:		Line 19:
	=== Relative locktime ===		=== Relative locktime ===

	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.		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 ===

Kristapsk: Add info about current use of CLTV in time-locked fidelity bonds (JoinMarket)

2022-02-18T09:29:11Z

Add info about current use of CLTV in time-locked fidelity bonds (JoinMarket)

← Older revision		Revision as of 09:29, 18 February 2022
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 [[Payment_channels#CLTV-style_payment_channels\|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 ===

934: /* Relative locktime */ bip links

2022-01-10T14:03:10Z

Relative locktime: bip links

← Older revision		Revision as of 14:03, 10 January 2022
Line 19:		Line 19:
	=== Relative locktime ===		=== Relative locktime ===

	In mid-2016, the ~~BIP68~~/112/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.		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 ===

Belcher: /* CheckLockTimeVerify */ Fix link

2021-06-10T12:32:26Z

CheckLockTimeVerify: Fix link

← Older revision		Revision as of 12:32, 10 June 2021
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]].

	=== Relative locktime ===		=== Relative locktime ===

Belcher: /* Far-future locks */ Add link to that guy who locked up 0.0003 btc until the year 2042

2021-04-01T00:21:54Z

Far-future locks: Add link to that guy who locked up 0.0003 btc until the year 2042

← Older revision		Revision as of 00:21, 1 April 2021
Line 32:		Line 32:

	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 ==

MarkBLundeberg: expand history of nLockTime, also note that block N can only contain transactions with nlocktime strictly less than N.

2019-11-06T16:02:34Z

expand history of nLockTime, also note that block N can only contain transactions with nlocktime *strictly less* than N.

← Older revision		Revision as of 16:02, 6 November 2019
Line 7:		Line 7:
	''Main article: [[nLockTime]]''		''Main article: [[nLockTime]]''

	~~A part of~~ the original Bitcoin ~~implementation~~<ref>https://github.com/bitcoin/bitcoin/~~blob~~/~~8dca7864f793072701f810e4c5ea12a6e1087085/main.h~~#~~L399~~</ref>, nLockTime is a ~~field~~ that ~~specifies the earliest block height a transaction may be added~~ to ~~a valid~~ block. ~~A later change~~<ref>https://github.com/bitcoin/bitcoin/~~blob/956468c29adcbff83ab7c2e52d91f8e87b704853~~/~~main.h~~#~~L401~~</ref> ~~allowed nLockTime~~ to ~~alternatively specify~~ the ~~earliest~~ time ~~a transaction may be added to a valid~~ block.		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. 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.		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.

Harrigan: /* nLockTime */ Fix citations

2019-09-12T15:16:23Z

nLockTime: Fix citations

← Older revision		Revision as of 15:16, 12 September 2019
Line 7:		Line 7:
	''Main article: [[nLockTime]]''		''Main article: [[nLockTime]]''

	A part of the original Bitcoin implementation{{https://github.com/bitcoin/bitcoin/blob/8dca7864f793072701f810e4c5ea12a6e1087085/main.h#L399}}, nLockTime is a field that specifies the earliest block height a transaction may be added to a valid block. A later change{{https://github.com/bitcoin/bitcoin/blob/956468c29adcbff83ab7c2e52d91f8e87b704853/main.h#L401}} allowed nLockTime to alternatively specify the earliest time a transaction may be added to a valid block.		A part of the original Bitcoin implementation<ref>https://github.com/bitcoin/bitcoin/blob/8dca7864f793072701f810e4c5ea12a6e1087085/main.h#L399</ref>, nLockTime is a field that specifies the earliest block height a transaction may be added to a valid block. A later change<ref>https://github.com/bitcoin/bitcoin/blob/956468c29adcbff83ab7c2e52d91f8e87b704853/main.h#L401</ref> allowed nLockTime to alternatively specify the earliest time a transaction may be added to a valid block.

	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.		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.

Harrigan: /* nLockTime */ Correct the ordering; see https://bitcoin.stackexchange.com/questions/90229/nlocktime-in-bitcoin-core

2019-09-12T15:12:56Z

nLockTime: Correct the ordering; see https://bitcoin.stackexchange.com/questions/90229/nlocktime-in-bitcoin-core

← Older revision		Revision as of 15:12, 12 September 2019
Line 7:		Line 7:
	''Main article: [[nLockTime]]''		''Main article: [[nLockTime]]''

	A part of the original Bitcoin implementation{{~~citation needed~~}}, nLockTime is a field that specifies the earliest ~~time~~ a transaction may be added to a valid block. A later ~~Bitcoin soft fork~~{{~~citation needed~~}} allowed nLockTime to alternatively specify the ~~lowest block height~~ a transaction may be added to a valid block.		A part of the original Bitcoin implementation{{https://github.com/bitcoin/bitcoin/blob/8dca7864f793072701f810e4c5ea12a6e1087085/main.h#L399}}, nLockTime is a field that specifies the earliest block height a transaction may be added to a valid block. A later change{{https://github.com/bitcoin/bitcoin/blob/956468c29adcbff83ab7c2e52d91f8e87b704853/main.h#L401}} allowed nLockTime to alternatively specify the earliest time a transaction may be added to a valid block.

	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.		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.

Belcher: Add note about using locktime for trustless precomputed fee bumping

2019-02-17T16:49:12Z

Add note about using locktime for trustless precomputed fee bumping

← Older revision		Revision as of 16:49, 17 February 2019
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 ==

Belcher: /* nLockTime */ Talk about how many txes today use the nlocktime field

2019-01-29T16:15:49Z

nLockTime: Talk about how many txes today use the nlocktime field

← Older revision		Revision as of 16:15, 29 January 2019
Line 9:		Line 9:
	A part of the original Bitcoin implementation{{citation needed}}, nLockTime is a field that specifies the earliest time a transaction may be added to a valid block. A later Bitcoin soft fork{{citation needed}} allowed nLockTime to alternatively specify the lowest block height a transaction may be added to a valid block.		A part of the original Bitcoin implementation{{citation needed}}, nLockTime is a field that specifies the earliest time a transaction may be added to a valid block. A later Bitcoin soft fork{{citation needed}} allowed nLockTime to alternatively specify the lowest block height a transaction may be added to a valid block.

	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 ===