to OP_VAULT. Code example here:
allows arbitrary smart contracts thanks to fraud proofs.
if it turns simple things into complicated ones. Luckily, this is not the case.
In particular, in this email we will not merkleize anything (other than taptrees).
opcodes.
base branch.
stage.
In this section, I will discuss plausible semantics for the core opcodes for MATT.
OP_CHECKOUTPUTCONTRACTVERIFY.
not the amounts; more on that below.
the MATT framework.
optionally some data, and optionally taptree's merkle root.
hash of the merkle tree per BIP-0341 [3].
more compact scripts in some spending paths.
In words:
- OP_CHECKINPUTCONTRACTVERIFY: verify that the current input's internal key
contains some embedded data (which would typically be passed through the
witness stack)
- OP_CHECKOUTPUTCONTRACTVERIFY: verify that a given output is a certain P2TR
output script containing the desired embedded data.
TBD if the tweaking used for the embedded data tweak should use a tagged hash;
omitted for simplicity in this demo implementation.
### Amount preservation
In the code above and in the linked demo implementation, the opcodes only
operate on the scriptPubkey; a complete implementation would want to make sure
that amounts are correctly preserved.
The most direct and general way to address this would be to allow direct
introspection on the output amounts. This has the complication that output
amounts require 64-bits arithmetics, as discussed in the context of other
proposals, for example: [4].
One more limited approach that works well for many interesting contracts
is that of the deferred checks, implemented in OP_VAULT [2].
The idea is that all the amounts of the inputs that commit to the same output
script with OP_CHECKOUTPUTCONTRACTVERIFY are added together, and the script
interpreter requires that the amount of that output is not smaller than the
total amount of those inputs. This check is therefore transaction-wide rather
than being tested during the input's script evaluation.
This behaviour is adequate for vaults and likely suitable for many other
applications; however, it's not the most general approach. I didn't try to
implement it yet, and defer the decision on the best approach to a later time.
### Extensions
The opcodes above are not enough for the full generality of MATT: one would
need to add an opcode like OP_SHA256CAT to allow the data embedding to commit
to multiple pieces of data.
This is not used in today's post, therefore I left it out of these code examples.
It would be easy to extend OP_CHECKOUTPUTCONTRACTVERIFY to also apply for
an arbitrary input (typically, different from the currently executed one); there
are likely use cases for that, allowing to define contracts with more complex
cross-input semantics, but I preferred to keep things simple.
Of course, one could also entirely replace CICV/COCV with generic full
introspection on inputs/output's program, plus opcodes for elliptic curve math
and tagged hashes.
##########################
# PART 2: Vaults with MATT
##########################
In the rest of this post, I will document the first attempt at creating a vault
using the opcodes described.
While not an attempt at cloning exactly the functionality of OP_VAULT [2],
it borrows heavily from the excellent work that was done there.
In particular, it also inherits the choice of using OP_CTV as a primitive,
building on top of the bitcoin-inquisition's current branch that has already
merged OP_CTV. Reasonable vaults would be possible without CTV, but they
would be less efficient, particularly in the case of sending to many addresses
in a single unvaulting flow.
### Distilling OP_VAULT
Abstracting from the implementation details, I mentally model a vault as a
simple state machine with 2 states: [V] and [U]:
[V]: the initial vault UTXO(s);
[U]: the utxo produced by the "trigger transaction" during unvaulting.
On the typical path: one or more [V] UTXOs are sent to the [U] state, and after
a timelock set on [U] expires, [U] is spent to one or several destinations.
Crucially, the destination outputs and amounts are already decided when [V] is
spent into [U].
At any time before the funds are spent from [U], they can always be spent by
sending them to some specified recovery path.
There are two key elements that are part of OP_VAULT's semantics, and could be
generalized:
− Forcing the script/amount of the next stepon
− Storing some data for future Script's access (in the vault's case, a hash
that commits to the final withdrawal transaction).
CICV/COCV generalize both to arbitrary scripts (taptrees) and state machines,
and to dynamical and witness-dependent data embedded in the pubkey of a P2TR
output.
### Vault parameters
A contract that represents a vault has the following parameters (hardcoded in
the script when the vault is created):
- alternate_pk: a key that can be used any time.
- spend_delay: the relative timelock before the withdrawal can be finalized;
- recover_pk: a pubkey for a P2TR output where funds can be sent at any time.
The alternate_pk is a pubkey that can optionally be used as the key-path
spending condition for both states [V] and [U]. If such a spending condition is not
desired, it can be replaced with a NUMS point, making the key-path unspendable.
The spend_delay is the number of blocks that must be mined before the final
withdrawal transaction
In this example we also use an unvault_pk needed to authorize the unvaulting
process (that is, spend [V] into [U]); this could be replaced with any miniscript
or other conditions expressible in Script.
### P2TR structure for [V] (vault)
internal key: alternate_pk
Script 1: "trigger"
# witness: <out_i> <ctv-hash>
{
<alternate_pk>,
<merkle root of U's taptree>,
2, OP_ROLL,
OP_CHECKOUTPUTCONTRACTVERIFY,
<unvault_pk>
OP_CHECKSIG
}
Script 2: "recover"
# witness: <out_i>
{
recover_pk,
OP_0, # no data tweak
OP_0, # no taptweak
OP_CHECKOUTPUTCONTRACTVERIFY,
OP_TRUE
}
The "trigger" script requires in the witness an output index and the ctv-hash
that describes the withdrawal transaction.
COCV forces the output to contain the ctv-hash as embedded data.
That's followed by the unvaulting condition − in this example, a simple
signature check.
The "recover" script doesn't require any signature, and it simply forces
the output specified in the witness to be a P2TR output with recover_pk as its
pubkey.
(Omitting the "recover" script in [V] would reduce the size of the witness by
32 bytes in the expected case, and might be preferred for some users)
### P2TR structure for [U] (unvaulting state)
internal key: alternate_pk (tweaked with ctv_hash)
Script 1: "withdrawal"
# witness: <ctv_hash>
{
OP_DUP,
# check that the top of the stack is the
# embedded data in the current input
<alternate_pk>, OP_SWAP,
OP_CHECKINPUTCONTRACTVERIFY,
# Check timelock
<spend_delay>,
OP_CHECKSEQUENCEVERIFY,
OP_DROP,
# Check that the transaction output is as expected
OP_CHECKTEMPLATEVERIFY
}
Script 2: "recover"
# witness: <out_i>
{
<recover_pk>,
OP_0,
OP_0,
OP_CHECKOUTPUTCONTRACTVERIFY,
OP_TRUE
}
The "withdrawal" finalizes the transaction, by checking that the timelock expired and
the outputs satisfy the CTV hash that was committed to in the previous transaction.
The "recover" script is identical as before.
### Differences with OP_VAULT vaults
Here I refer to the latest version of OP_VAULT at the time of writing. [5]
It is not a thorough analysis.
Unlike the implementation based on OP_VAULT, the [V] utxos don't have an option
to add an additional output that is sent back to the same exact vault.
Supporting this use case seems to require a more general way of handling the
distribution of amounts than what I discussed in the section above: that would
in fact need to be generalized to the case of multiple
OP_CHECKOUTPUTCONTRACTVERIFY opcodes executed for the same input.
By separating the ctv-hash (which is considered "data") from the scripts in the
taptree, one entirely avoids the need to dynamically create taptrees and
replace leaves in the covenant-encumbered UTXOs; in fact, the taptrees of [V]
and [U] are already set in stone when [V] utxos are created, and only the
"data" portion of [U]'s scriptPubKey is dynamically computed. In my opinion,
this makes it substantially easier to program "state machines" that control the
behavior of coins, of which vaults are a special case.
I hope you'll find this interesting, and look forward to your comments.