- Describe OP_CMS pubkey limits for consensus, relay policy, and P2SH.
- Mention that OP_CLTV and OP_CSV leave elements on the stack, unlike
other VERIFY opcodes.
(P2SH)", "import/export example")))In <<ch01_intro_what_is_bitcoin>> we
introduced Mohammed, an electronics importer based in Dubai. Mohammed's
(P2SH)", "import/export example")))
Mohammed is an electronics importer based in Dubai. Mohammed's
company uses bitcoin's multisignature feature extensively for its
corporate accounts. Multisignature scripts are one of the most common
uses of bitcoin's advanced scripting capabilities and are a very
@ -502,6 +506,7 @@ controls and protects against theft, embezzlement, or loss.
The resulting script is quite long and looks like this:
//FIXME:script match text with nesting
----
2 <Mohammed's Public Key> <Partner1 Public Key> <Partner2 Public Key> <Partner3 Public Key> <Attorney Public Key> 5 OP_CHECKMULTISIG
----
@ -665,7 +670,7 @@ echo \
----
Now, Mohammed can give this "address" to his customers and they can use
almost any bitcoin wallet to make a simple payment, as if it were a
almost any Bitcoin wallet to make a simple payment, like any other
Bitcoin address. The 3 prefix gives them a hint that this is a special
type of address, one corresponding to a script instead of a public key,
but otherwise it works in exactly the same way as a payment to any other Bitcoin
@ -684,7 +689,7 @@ scripts in outputs:
- Complex scripts are replaced by shorter commitments in the
transaction output, making the transaction smaller.
- Scripts can be coded as an address, so the sender and the sender's
- The similarity to original legacy addresses means the sender and the sender's
wallet don't need complex engineering to implement P2SH.
- P2SH shifts the burden of constructing the script to the recipient,
@ -754,7 +759,7 @@ technology and want to encourage such experimentation. Those who object
to the inclusion of nonpayment data argue that it causes "blockchain
bloat," burdening those running full Bitcoin nodes with carrying the
cost of disk storage for data that the blockchain was not intended to
carry. Moreover, such transactions create UTXO that cannot be spent,
carry. Moreover, such transactions create UTXOs that cannot be spent,
using the destination legacy Bitcoin address as a freeform 20-byte field.
Because the address is used for data, it doesn't correspond to a private
key and the resulting UTXO can _never_ be spent; it's a fake payment.
@ -770,7 +775,7 @@ _provably unspendable_ output, which does not need to be stored in the
UTXO set. +OP_RETURN+ outputs are recorded on the blockchain, so they
consume disk space and contribute to the increase in the blockchain's
size, but they are not stored in the UTXO set and therefore do not bloat
the UTXO memory pool and burden full nodes with the cost of more
full nodes with the cost of more
expensive database operations.
+OP_RETURN+ scripts look like this:
@ -791,9 +796,9 @@ Keep in mind that there is no input script that corresponds to
+OP_RETURN+ that could possibly be used to "spend" an +OP_RETURN+ output. The
whole point of an +OP_RETURN+ output is that you can't spend the money locked in that
output, and therefore it does not need to be held in the UTXO set as
potentially spendable: +OP_RETURN+ is _provably unspendable_. +OP_RETURN+ is
usually an output with a zero amount, because any bitcoins
assigned to such an output is effectively lost forever. If an +OP_RETURN+ is
potentially spendable: +OP_RETURN+ outputs are _provably unspendable_. +OP_RETURN+ outputs
usually have a zero amount, because any bitcoins
assigned to such an output is effectively lost forever. If an +OP_RETURN+ output is
referenced as an input in a transaction, the script validation engine
will halt the execution of the validation script and mark the
transaction as invalid. The execution of +OP_RETURN+ essentially causes the
@ -804,7 +809,10 @@ transaction is invalid.
[[lock_time_limitations]]
==== Transaction lock time limitations
Lock time has the limitation that while it makes it possible to spend some outputs in the future, it does not make it impossible to spend them until that time. Let's explain that with the following example.
Use of the lock time allows a spender to restrict a transaction from
being included in a block until a specific block height, but it does not
prevent spending the funds in another transaction earlier than that.
Let's explain that with the following example.
((("use cases", "buying coffee", id="alicesseven")))Alice signs a transaction spending one of her outputs to Bob's address, and sets the transaction lock time to 3 months in the future. Alice sends that transaction to Bob to hold. With this transaction Alice and Bob know that:
@ -816,7 +824,7 @@ However:
* Alice can create another transaction, double-spending the same inputs without a lock time. Thus, Alice can spend the same UTXO before the 3 months have elapsed.
* Bob has no guarantee that Alice won't do that.
It is important to understand the limitations of transaction lock time. The only guarantee is that Bob will not be able to redeem it before 3 months have elapsed. There is no guarantee that Bob will get the funds. To achieve such a guarantee, the timelock restriction must be placed on the UTXO itself and be part of the script, rather than on the transaction. This is achieved by the next form of timelock, called Check Lock Time Verify.
It is important to understand the limitations of transaction lock time. The only guarantee is that Bob will not be able to redeem the presigned transaction before 3 months have elapsed. There is no guarantee that Bob will get the funds. To guarantee that Bob will receive the funds but cannot spend them until 3 months have elapsed, the timelock restriction must be placed on the UTXO itself and be part of the script, rather than on the transaction. This is achieved by the next form of timelock, called Check Lock Time Verify.
==== Check Lock Time Verify (OP_CLTV)
@ -835,13 +843,7 @@ In simple terms, by committing to the +OP_CLTV+ opcode in an
output, that output is restricted so that it can only be spent after the
specified time has elapsed.
[TIP]
====
While lock time is a transaction-level timelock, +OP_CLTV+ is an
output-based timelock.
====
+OP_CLTV+ doesn't replace lock time, but rather restricts specific UTXO
+OP_CLTV+ doesn't replace lock time, but rather restricts specific UTXOs
such that they can only be spent in a future transaction with
lock time set to a greater or equal value.
@ -913,19 +915,25 @@ 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.
input uses the time variety, there is no way to construct a valid transaction
that spends both inputs.
====
After execution, if +OP_CLTV+ is satisfied, the parameter that
preceded it remains as the top item on the stack and may need to be
dropped, with +OP_DROP+, for correct execution of subsequent script
opcodes. You will often see +OP_CHECKLOCKTIMEVERIFY+ followed by +OP_DROP+ in
scripts for this reason.
scripts for this reason. +OP_CLTV+, like +OP_CSV+ (see <<op_csv>>)
are unlike other +CHECKVERIFY+ opcodes in leaving items on the stack
because the soft forks that added them redefined existing opcodes that
did not drop stack items, and the behavior of those previous
no-operation (NOP) opcodes must be preserved.
By using lock time in conjunction with +OP_CLTV+, the scenario described in
<<lock_time_limitations>> changes. Alice can no longer spend the money
(because it's locked with Bob's key) and Bob cannot spend it before the
3-month lock time has expired.((("", startref="alicesseven")))
<<lock_time_limitations>> changes. Alice sends her transaction
immediately, assigning the funds to Bob’s key. Alice can no longer spend
the money, but Bob cannot spend it before the 3-month lock time has
expired.
By introducing timelock functionality directly into the scripting
language, +OP_CLTV+ allows us to develop some very interesting complex
@ -1240,7 +1248,8 @@ must agree. However, in the case of a problem with their keys, they want
their lawyer to be able to recover the funds with one of the three
partner signatures. Finally, if all partners are unavailable or
incapacitated for a while, they want the lawyer to be able to manage the
account directly.
account directly after he gains access to the capital account's
transaction records.
Here's the redeem script that Mohammed designs to achieve this (line
David A. Harding
10 months ago