To compare different proposals to enable covenants on Bitcoin, it would be useful to have a list of everything we would currently like to do with any sort of covenant. My interest is in anything where a plausible case can be made that a significant number of mostly-rational people would pay transaction fees to use the covenant-based application.
For the purpose of this list, I use Anthony Towns's definition of a covenant: "when the scriptPubKey of a UTXO restricts the scriptPubKey in the output(s) of a tx spending that UTXO". This includes (but is not restricted) to the following proposals: BIP118 SIGHASH_ANYPREVOUT (APO), BIP119 OP_CHECKTEMPLATEVERIFY (CTV), OP_CAT in combination with BIP340 schnorr signatures, OP_CHECKSIGFROMSTACK (CSFS), OP_TAPROOT_LEAF_VERIFY (TLUV), and OP_TXHASH/OP_TX.
The covenant-based application doesn't need to be good for Bitcoin as long as there's a reasonable chance people would use it. For example, Bitcoin's main chain may be destablized if one or more drivechains becomes widely used, but we can credibly believe that people might try using a version of drivechains based on a covenant opcode.
When suggesting covenant-based applications below, please either link to a public description of the idea or briefly explain how it would work.
The list of below of plausible ideas will be periodically updated with suggestions from the comments or ideas I find elsewhere. If you need to contact me directly, please use dave@dtrt.org.
Abbreviations:
-
Channel factories, e.g. based on Eltoo/APO, OP_EVICT, or transaction heritage identifiers
-
Joinpools (also called payment pools and coin pools)
-
Non-interactive bi-directional payment channel opening (without requiring the initiator push all funds to the accepter)
-
Spacechains (Original description and using APO)
-
Vaults (many kinds)
-
MES vaults (original description, using CAT+CSFS)