Published on: 2023-01-19T22:42:43+00:00
A proposal has been put forward to use the OP_UNVAULT opcode as a means of creating more complex covenants. The idea is to restrict the script to only contain the OP_UNVAULT call, allowing it to be used for Jeremy Rubin's congestion control transactions. However, by adding a scriptPubKey for authorization recovery, it becomes possible to create more general covenants by setting the unvault-target-hash to an unsatisfiable number and placing arbitrary conditions on spending the UTXO to the recovery address. This concept, proposed by Ben Carman after reading James O'Beirne's OP_VAULT proposal, can be seen as a general CTV-like covenant.While this approach would require more blockchain space, it should offer the same computational savings as the original CTV proposal. The main drawback is that the final spending script will be slightly larger. Another proposal suggests using the OP_UNVAULT output to create a not-so-simple covenant by setting the unvault-target-hash to desired output restrictions. This construction can recreate many aspects of CTV, including Lloyd's improvement to DLCs. A taproot tree similar to Lloyd's construction could also be created, with each leaf appearing as `0 OP_UNVAULT CHECKSIG`. This variation should provide the same computational benefits as the original CTV proposal but would consume more blockchain space. The downside is that the final spending script would be slightly larger, with `OP_CTV` being replaced by `0 OP_UNVAULT` (adding 34 bytes, excluding the witness discount). However, in the case of a DLC with multiple outcomes, the impact may be negligible as the input size will primarily come from the control block.This idea was inspired by James O'Beirne's OP_VAULT proposal, and credit is given to Lloyd Fournier for the original proposal.
Updated on: 2023-08-02T08:47:59.670284+00:00