How much resources can a (mempool) transaction waste by violating this rule in the last input / output after making the interpreter do a bunch of hashing work?

And is that worse than existing taproot script allows? And would it be better with a restriction on the number of combinations, e.g. if inputs can't refer to other inputs? Or should these bounds checks be done earlier for the whole transaction? (that seems impossible because the index comes from the stack, which you can't predict through static analysis of the script and witness)

In terms of hashing, it is no different than opcodes like OP_SHA256, as it hashes a stack element (prefixed with an x-only key, so up to 552 bytes in total).
So restricting the opcode to just the current input shouldn't make any difference.

That should be significantly smaller than the the cost of the double tweak, which should instead be comparable (and priced appropriately in sigops) to signatures – hopefully a bit less than that, but this needs a proper benchmark.

Note that no non-witness parts of the transaction is involved in the hashing (except the current input's internal key/taptree when the corresponding parameter is -1), so caching issues like the ones one might have for opcodes like OP_CHECKSIG or OP_CHECKTEMPLATEVERIFY/TXHASH shouldn't be a concern.

In 0a1d149 "test: Add functional tests for a vault construction based on CHECKCONTRACTVERIFY"

Can alternate_pk and recover_pk just be the same? That way there's only two key sets needed for a vault: one hot, one cold. And you're avoiding the use of a NUMS point.

BIP 345 (OP_VAULT) says:

the recovery key can include a number of spending conditions, e.g. a time-delayed fallback to an "easier" recovery method, in case the highly secure key winds up being too highly secure.

In your scheme you can have those recovery options in the main taptree. That allows for recovery without an initial trigger transaction / unvaulting, i.e. even if you lost the hot key (I think BIP 345 allows that too?).

Here's a branch with the above patch f87381a, but also renaming:

• unvault_{privkey, pubkey_xonly} to hot_{privkey,pk,pubkey_xonly}
• recover_{privkey, pubkey_xonly} to cold_{privkey,pk,pubkey_xonly}

With that terminology I find it easier to follow: using their hot key the user unvaults into some arbitrary withdrawal address, which can be recovered to their cold key (with no signature, just knowledge of the recover leaf).

I missed a spot where the alternate key was used:
master...Sjors:bitcoin:2025/03/op_cvv_vault_test

So now the withdraw leaf is shorter.

Though maybe I'm misunderstanding what the alternate_pk was good for. Maybe to provide an example of having two OP_CHECKCONTRACTVERIFY codes in a single leaf? The trigger_and_revault leaf already does that.

It could still make sense to have an example of a more advanced vault, but it should be seperate. The simplest possible vault is a good way to learn how this opcode works.

I tried to be smart and also use -1 instead of cold_pk in recover_leaf, but that doesn't work. Not sure why.

IIUC there's two recovery methods. If so it would be good to demonstrate both:

1. Using the cold keys directly, using the key path of the trigger output
2. Using the recovery condition

(2) can be done without using the cold keys, which is nice if you're not sure yet how your hot key was compromised.

Mmm, I think I'm still missing something. Pushed a commit 43e2d97 that robs the vault by simply changing the destination address and witness at withdrawal time.

Fixed in 4379b25, by more or less restoring the code I deleted in e937281.

Thanks for checking out the demo!
For the naming, I tried to use names similar to BIP-345, except that I name the "Vault" and "Unvaulting" state of the FSM which seems more natural in CCV-lingo (where you define the multi-utxo contract as a finite-state-machine).

Can alternate_pk and recover_pk just be the same? That way there's only two key sets needed for a vault: one hot, one cold. And you're avoiding the use of a NUMS point.

You could, but I don't think that makes a lot of sense in practice, as the alternate_pk has no covenant restriction. I think in simple vaults it doesn't make sense to use the alternate_pk; you could only make sense to use it for deep cold storage (e.g. a musig of cold keys, that is: "you can override the 2-step withdrawal process, but you have to go through the hassle of using multiple cold keys").
Note that using the alternate pubkey makes the default spending paths more expensive, since NUMS has the special encoding 0 in CCV - so one might still prefer to use a NUMS in the keypath and put a pk(alternate_pk) in a tapleaf.

In general, I don't think the alternate_pk is very interesting for a vault, but it comes natural to define it because of how taproot works.

The keypath is certainly more interesting in multi-party contracts, where the parties can cooperatively agree to sign the transaction with a musig taproot keypath, instead of putting the covenant on-chain.

In your scheme you can have those recovery options in the main taptree. That allows for recovery without an initial trigger transaction / unvaulting, i.e. even if you lost the hot key (I think BIP 345 allows that too?).

Yes, in the demo I made a simple recovery mechanism that sends to a predetermined address, but you can of course get arbitrarily more creative if you wish!

I tried to be smart and also use -1 instead of cold_pk in recover_leaf, but that doesn't work. Not sure why.

Putting -1 means in the pk argument means that you reuse the taproot internal key for your output, which you probably only want to do in a recursive contract (but then like you probably also want to put -1 for the taptree, like the first CCV in the trigger_and_revault leaf, that recycles both the internal key and the taptree in order to 'send back to yourself').

I tried to use names similar to BIP-345

The terms {vault,trigger,withdrawal,recovery} transaction from that BIP are indeed useful. But I found it a bit easier to follow when calling the relevant keys "hot" and "cold" and not having a third one.

You could, but I don't think that makes a lot of sense in practice, as the alternate_pk has no covenant restriction.

Maybe I'm still confused then. In my branch I renamed recover_pk to cold_pk. So the cold key can be used for keypath spending, ignoring the covenant. And it's where the coins are sent to in a recovery scenario.

In general, I don't think the alternate_pk is very interesting for a vault, but it comes natural to define it because of how taproot works.

So then it's better to leave it out of the example for improved readability?

I tried to be smart and also use -1 instead of cold_pk in recover_leaf, but that doesn't work. Not sure why.

Putting -1 means in the pk argument means that you reuse the taproot internal key for your output

I'm still not sure if I understand this. I assumed that the taproot internal key is unchanged by the trigger transaction, i.e. it's still the cold key (in my branch).

The 'trigger' transaction moves from the Vault state to the Unvaulting state.

• a Vault UTXO has no embedded data, so the internal key equals what I called the naked key (which is the alternate_pk in this case).
• an Unvaulting UTXO has some data embedded (the withdrawal_pk), so the internal key is something like tweak(alternate_pk, SHA256(alternate_pk || data)). So if you put -1 to send to an output with the "same public key as the input's internal key", you'd have the tweaked key as the output. Which is still spendable if you control alternate_pk, but probably not what you wanted.

If you really wanted to "send to an output with the same naked key as the input you're spending, you could pass naked key, data and taptree, then do a CCV check on the input (with CCV_FLAG_CHECK_INPUT) to check it matches what's on the stack, then do a CCV on the output (now that you have the naked key on the stack). But I think you don't want to do this.

In most cases, working with directed acyclic graphs (meaning, the construction always moves forward, and introspection on the input is only used to get the input's data on the stack), so far, seems to be enough to do anything interesting.

Recursive contracts are the exception, where you send to exactly the same (naked_key, taptree) pair as the input, either with no data (like in vaults), or after updating the data with some new data (this will be useful in shared UTXOs, sidechains, etc.).

Thanks, that makes sense. There's no concept of a global naked key that is preserved between steps of the program (except through the workaround you mention).

@bigspider In commit 2c1deef, naively it looks like this diff would resolve the rebase for you.

             bool tx_ok;
             TxValidationState tx_state;
             // If CheckInputScripts is called with a pointer to a checks vector, the resulting checks are appended to it. In that case
             // they need to be added to control which runs them asynchronously. Otherwise, CheckInputScripts runs the checks before returning.
-            if (fScriptChecks && !CheckInputScripts(tx, tx_state, view, flags, fCacheResults, fCacheResults, txsdata[i], m_chainman.m_validation_cache, tx_exec_store, parallel_script_checks ? &vChecks : nullptr)) {
             if (control) {
                 std::vector<CScriptCheck> vChecks;
-                tx_ok = CheckInputScripts(tx, tx_state, view, flags, fCacheResults, fCacheResults, txsdata[i], m_chainman.m_validation_cache, &vChecks);
+                tx_ok = CheckInputScripts(tx, tx_state, view, flags, fCacheResults, fCacheResults, txsdata[i], m_chainman.m_validation_cache, tx_exec_store, &vChecks);
                 if (tx_ok) control->Add(std::move(vChecks));
             } else {
-                tx_ok = CheckInputScripts(tx, tx_state, view, flags, fCacheResults, fCacheResults, txsdata[i], m_chainman.m_validation_cache);
+                tx_ok = CheckInputScripts(tx, tx_state, view, flags, fCacheResults, fCacheResults, txsdata[i], m_chainman.m_validation_cache, tx_exec_store);
             }
             if (!tx_ok) {