Author: Michael Folkson 2023-05-01 14:18:29
Published on: 2023-05-01T14:18:29+00:00
Bitcoin developer Salvatore Ingala recently sent a proposal to the bitcoin-dev mailing list regarding the creation of Bitcoin vaults using the upcoming P2TR output type. Vaults are a way to store Bitcoin securely with an added layer of protection, such as a time delay before funds can be withdrawn. The proposed P2TR-based vaults allow users to specify spending conditions that must be met before funds can be withdrawn. These include alternate_pk, spend_delay, and recover_pk keys. The alternate_pk key is optional and can be replaced with a NUMS point, making the key-path unspendable. The spend_delay requires the number of blocks that must be mined before the final withdrawal transaction, while the recover_pk key is used to send funds to a P2TR output at any time. The proposal provides P2TR structures for both the vault state [V] and the unvaulting state [U]. Salvatore discussed plausible semantics for the core opcodes for MATT in which they can decide the taptree of the output, embed some dynamically computed data in the output, and access the embedded data in the current UTXO. He also mentioned that the opcodes are incomplete as they only control the output's Script and not the amounts. Salvatore talked about two approaches to preserving the amount; direct introspection on the output amounts and deferred checks approach. Salvatore documented the first attempt at creating a vault using the opcodes described. Salvatore borrowed heavily from the excellent work done on OP_VAULT and inherited the choice of using OP_CTV as a primitive. Salvatore mentally modeled a vault as a simple state machine with 2 states: [V] and [U]. There are two key elements that are part of OP_VAULT's semantics, and could be generalized which are forcing the script/amount of the next step and storing some data for future Script's access. 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. A contract that represents a vault has the following parameters (hardcoded in the script). The opcodes above are not enough for the full generality of MATT, and one would need to add an opcode like OP_SHA256CAT to allow the data embedding to commit to multiple pieces of data. Salvatore discussed extensions to the opcodes and how they could be extended to apply for an arbitrary input. In [V], the trigger script requires a ctv-hash and output index in the witness, followed by an unvaulting condition, while the recover script does not require any signature. In [U], the internal key is tweaked with ctv_hash, and the withdrawal script finalizes the transaction by checking that the timelock expired and the outputs satisfy the CTV hash committed to in the previous transaction. 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. By separating the ctv-hash from the scripts in the taptree, one avoids the need to dynamically create taptrees and replace leaves in the covenant-encumbered UTXOs. Overall, this proposed method aims to make it easier to program "state machines" that control the behavior of coins, of which vaults are a special case. Salvatore welcomes comments from the community on the proposal, which can be found on the Bitcoin-dev mailing list.
Updated on: 2023-06-16T17:48:18.652731+00:00