1
0
mirror of https://github.com/bitcoinbook/bitcoinbook synced 2024-11-23 00:28:14 +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:
David A. Harding 2023-03-16 09:13:38 -10:00
parent 7b6bc29171
commit 61b18af41b

View File

@ -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 +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
a block height or the time elapsed in seconds since Unix epoch.
Critically, when used together, the format of +nLockTime+ must match
that of +OP_CLTV+ in the outputs--they must both reference either
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
@ -981,6 +994,15 @@ blocks, then so must +nSequence+. If +OP_CSV+ is specified in terms of
seconds, then so must +nSequence+.
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
they're kept "off-chain." A child transaction cannot be used until the
parent transaction has been propagated, mined, and aged by the time