Vaults in the MATT framework

Summary:

Salvatore Ingala has proposed a new smart contract framework called MATT for Bitcoin. The proposal enhances Script with capabilities such as deciding the taptree of the output, embedding dynamically computed data in the output, and accessing the embedded data in the current UTXO. Fraud proofs are an advanced application of the new opcodes and are not needed for most/all of the things that people are trying to build today with other covenant proposals. Salvatore also discusses Simplicity and its endeavor of replacing Script with a better language, which is orthogonal to the discussion about what features (e.g. : introspection, covenants) should be in the language.Another post describes a proposal for new Bitcoin opcodes called OP_CHECKINPUTCONTRACTVERIFY and OP_CHECKOUTPUTCONTRACTVERIFY that allow for the creation and verification of covenant-style contracts. These opcodes can be used to embed data into P2TR output scripts and verify that the correct data is present in subsequent transactions. The author notes that the proposed opcodes are not enough for the full generality of covenant-style contracts and suggests adding an opcode like OP_SHA256CAT to allow the data embedding to commit to multiple pieces of data. The author also considers extending OP_CHECKOUTPUTCONTRACTVERIFY to apply for arbitrary inputs, which would allow for more complex cross-input semantics.The post presents a specific example of a vault using the proposed opcodes. A vault is modeled as a simple state machine with two states: the initial vault UTXOs and the utxo produced by the trigger transaction during unvaulting. The trigger transaction sends one or more vault UTXOs to the unvaulting state, and after a timelock expires, the unvaulting state is spent to one or several destinations. The destination outputs and amounts are already decided when the vault UTXOs are spent into the unvaulting state. The post explains how these opcodes could be used in the context of a vault, which is a special type of state machine that controls the behavior of coins. The post also discusses how to ensure amount preservation in covenant-style contracts. One approach is to allow direct introspection on output amounts, but this requires 64-bit arithmetic. Another approach is to use deferred checks, as implemented in OP_VAULT. This approach adds together the amounts of inputs that commit to the same output script and requires that the output amount is not smaller than the total input amount.The structure of the P2TR output scripts for both the vault and unvaulting state are described. The author notes that the proposed vault implementation differs from OP_VAULT in that it does not support adding an additional output that is sent back to the same exact vault. However, the author argues that separating the ctv-hash from the scripts in the taptree makes it substantially easier to program state machines that control the behavior of coins. Overall, the post presents a detailed proposal for new opcodes that could enable more complex covenant-style contracts on Bitcoin and demonstrates a specific example using these opcodes to implement a vault. The required engineering for a soft-fork is relatively straightforward if we want the features that they enable. If we do not want those features, then the decision would rather be guided by other considerations, like potential risks to bitcoin caused by the effect of those features on miners' incentives.

Updated on: 2023-06-16T17:50:41.797309+00:00