Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

Summary:

The email exchange on the bitcoin-dev mailing list discusses concerns about recursive covenants and their potential impact on fungibility. Shinobi voices their concerns, stating that unbounded recursion combined with too much flexibility in future UTXO encumbrances could create dangerous implications for fungibility by introducing a different risk model for coins encumbered by such conditions. They give a hypothetical example of a flexible covenant design that perpetually requires a specific key controlled by an authority figure to be involved in any spend from the covenant, effectively preventing removal of that central authority's involvement in control over the UTXO. Such a construct would be damaging to fungibility, as it introduces a different risk model for coins encumbered by such a condition compared to those not encumbered by it. Shinobi notes that while such a walled garden could be constructed now using multisig and restrictions on where coins can be withdrawn to, the important distinction between such a non-consensus system designed to enforce such restrictions and a recursive covenant is that in the case of a multisig/non-consensus-based system, exit from that restriction is still possible under the consensus rules of the protocol. However, if such a construct were possible to build with a recursive covenant enforced by consensus, coins encumbered by such a covenant would literally be incapable of escaping those restrictions without hardforking the protocol, leaving any such UTXOs permanently non-fungible with ones not encumbered by such conditions.James O'Beirne responds, stating that he is not opposed to recursive covenants per se, but expresses uncertainty about proposals that enable more "featureful" covenants by adding more kinds of computation into Bitcoin script. He emphasizes limiting operations in Bitcoin script to "verification" (vs. "computation") to the extent practical and encourages general computation to be done off-chain. He notes his worry about opcodes like OP_CAT and OP_TX, stating that more logic living in script than necessary could make it harder to reason about and verify the chain. He likes CTV because it buys a lot of functionality without increasing the "surface area" of script's design, but acknowledges that this comes at the cost of precluding experimentation and requiring more soft-forking.David A. Harding responds, referencing a previous discussion on the merits of allowing recursive covenants and noting that not a single person replied to say they were opposed to the idea. He suggests that anyone opposed to recursive covenants should speak for themselves and cites the risk of recursive covenants without presenting a credible argument for the source of that risk as stop energy or FUD.

Updated on: 2023-06-15T16:41:06.961513+00:00