mirror of
https://github.com/bitcoinbook/bitcoinbook
synced 2025-02-17 01:52:09 +00:00
CH07: Update warning about mixing locktimes
We go into more detail about the problems of mixining locktimes, both CLTV and CSV.
This commit is contained in:
parent
7b6bc29171
commit
61b18af41b
@ -896,13 +896,26 @@ the transaction invalid if (source: BIP65):
|
|||||||
1. the top stack item is greater than the transaction's +nLockTime+ field; or
|
1. the top stack item is greater than the transaction's +nLockTime+ field; or
|
||||||
1. the +nSequence+ field of the input is 0xffffffff.
|
1. the +nSequence+ field of the input is 0xffffffff.
|
||||||
|
|
||||||
[NOTE]
|
[[timelock_conflicts]]
|
||||||
|
.Timelock conflicts
|
||||||
|
[WARNING]
|
||||||
====
|
====
|
||||||
+OP_CLTV+ and +nLockTime+ use the same format to describe timelocks, either
|
+OP_CLTV+ and +nLockTime+ use the same format to describe timelocks, either
|
||||||
a block height or the time elapsed in seconds since Unix epoch.
|
a block height or the time elapsed in seconds since Unix epoch.
|
||||||
Critically, when used together, the format of +nLockTime+ must match
|
Critically, when used together, the format of +nLockTime+ must match
|
||||||
that of +OP_CLTV+ in the outputs--they must both reference either
|
that of +OP_CLTV+ in the outputs--they must both reference either
|
||||||
block height or time in seconds.
|
block height or time in seconds.
|
||||||
|
|
||||||
|
The above implies that a script can never be valid if it must execute
|
||||||
|
two different calls to +OP_CLTV+, one which uses a height and one which
|
||||||
|
uses a time. It can be easy to make this mistake when writing advanced
|
||||||
|
scripts, so be sure to thoroughly test your scripts on a test network or
|
||||||
|
use a tool designed to prevent this issue, like a Miniscript compiler.
|
||||||
|
|
||||||
|
An additional implication is that only one variety of +OP_CLTV+ can be
|
||||||
|
used in any of the scripts of a transaction. If the script for one
|
||||||
|
input uses the height variety and a different script for a different
|
||||||
|
input uses the time variety, there is no way to construct a valid transaction.
|
||||||
====
|
====
|
||||||
|
|
||||||
After execution, if +OP_CLTV+ is satisfied, the parameter that
|
After execution, if +OP_CLTV+ is satisfied, the parameter that
|
||||||
@ -981,6 +994,15 @@ blocks, then so must +nSequence+. If +OP_CSV+ is specified in terms of
|
|||||||
seconds, then so must +nSequence+.
|
seconds, then so must +nSequence+.
|
||||||
|
|
||||||
Relative timelocks with +CSV+ are especially useful when several
|
Relative timelocks with +CSV+ are especially useful when several
|
||||||
|
[[WARNING]]
|
||||||
|
====
|
||||||
|
A script executing multiple +OP_CSV+ opcodes must only use the same
|
||||||
|
variety, either time-based or height-based. Mixing varieties will
|
||||||
|
produce an invalid script that can never be spent, the same problem we
|
||||||
|
saw with +OP_CLTV+ in <<timelock_conflicts>>. However, +OP_CSV+ allows
|
||||||
|
any two valid inputs to be included in the same transaction, so the problem
|
||||||
|
of interaction across inputs that occurs with +OP_CLTV+ doesn't affect +OP_CSV+.
|
||||||
|
====
|
||||||
(chained) transactions are created and signed, but not propagated, when
|
(chained) transactions are created and signed, but not propagated, when
|
||||||
they're kept "off-chain." A child transaction cannot be used until the
|
they're kept "off-chain." A child transaction cannot be used until the
|
||||||
parent transaction has been propagated, mined, and aged by the time
|
parent transaction has been propagated, mined, and aged by the time
|
||||||
|
Loading…
Reference in New Issue
Block a user