Vaults in the MATT framework

Summary:

In a recent email exchange on the bitcoin-dev mailing list, Salvatore Ingala discussed his MATT proposal for smart contracts in Bitcoin. The core functionality of MATT involves two new opcodes (OP_CHECKINPUTCONTRACTVERIFY and OP_CHECKOUTPUTCONTRACTVERIFY) that enhance Script with capabilities such as deciding the taptree of the output and embedding dynamically computed data within it. These opcodes are seen as an additional form of introspection and allow for general smart contracts thanks to fraud proofs.MATT is not yet fully formalized but is believed to be smaller and easier to audit than both the SegWit and Taproot soft forks. Ingala's opcodes are comparable to those proposed in APO/OP_CTV/OP_VAULT, which would add additional functionality to SegWit version 1 and Tapleaf version 0 scripts. Simplicity is another proposal that seeks to replace Script with a better language, but it is orthogonal to the discussion about what features should be in the language.If we want the features enabled by covenant proposals like MATT, engineering for a soft-fork is relatively straightforward, and there is no need to wait for Simplicity. If we do not want these features, then the decision would be guided by other considerations, like potential risks to Bitcoin caused by the effect of those features on miners' incentives.Ingala demonstrated how MATT's core opcodes could be used to create vaults that seem comparable to those built with OP_VAULT, despite using general-purpose opcodes. However, the linked code is not well-tested and is only intended for exploratory and demonstrative purposes. The opcodes only operate on scriptPubkey, so a complete implementation would require making sure that amounts are correctly preserved. One way to address this would be to allow direct introspection on output amounts, although this has complications requiring 64-bit arithmetic. Another approach is through deferred checks, as implemented in OP_VAULT.Salvatore Ingala, a Bitcoin developer, has proposed a new opcode named "OP_CHECKOUTPUTCONTRACTVERIFY" as part of the ongoing development of the Mimblewimble protocol. The proposed opcode allows for more complex cross-input semantics and data embedding in scripts. In addition, Ingala documents the first attempt at creating a vault using these opcodes and describes the parameters required to represent a vault.The vault is modeled as a simple state machine with two states: [V] and [U]. The proposal also includes P2TR structures for both [V] (vault) and [U] (unvaulting state). Ingala's proposal differs from the implementation based on OP_VAULT, as the [V] utxos do not have an option to add an additional output that is sent back to the same exact vault. Instead, by separating the ctv-hash from the scripts in the taptree, one entirely avoids the need to dynamically create taptrees and replace leaves in the covenant-encumbered UTXOs. Ultimately, this makes it substantially easier to program "state machines" that control the behavior of coins.While the proposed opcode is adequate for vaults and likely suitable for many other applications, it's not the most general approach. Ingala suggests that it would be easy to extend OP_CHECKOUTPUTCONTRACTVERIFY to also apply for an arbitrary input and there are likely use cases for that, allowing to define contracts with more complex cross-input semantics.

Updated on: 2023-06-16T17:49:32.779939+00:00