# Covenant tools softfork **URL:** \ **Category:** Protocol Design\ **Tags:** softfork\ **Created:** [September 28, 2023, 6:33pm UTC](https://delvingbitcoin.org/t/covenant-tools-softfork/98 "2023-09-28T18:33:29Z")\ **Posts on this page:** 1\ **Showing post:** 14
**Author:** ![jamesob](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/jamesob/32/271_2.png) [@jamesob](https://delvingbitcoin.org/u/jamesob)\ **Post date:** [September 30, 2023, 1:02pm UTC](https://delvingbitcoin.org/t/covenant-tools-softfork/98/14 "2023-09-30T13:02:36Z")
> [@harding](#): > > I feel like a better approach would be to enable a really general set of features that would allow anyone to create and deploy scripts that work like CTV/APO/VAULT and more, even if not in the most efficient way, without having to wait for permission. If we see a lot of onchain use (or otherwise demonstrated offchain use) of a generalized feature for something that would be more efficient if it was specialized, we can soft fork in that specialized feature and everyone who previously used the generalized version can immediately switch to the specialized version—an instant win with hopefully no controversy. > > The stub proposal I’ve used for this in the past is `OP_CSFS` + `OP_CAT`, or some variation on it (such as the SHA-based version used in Elements). That’s a really small consensus change and yet it allows implementation of any sort of transaction introspection we might want. Of course, maybe Simplicity, BTC Lisp, TXHASH, MATT, or something else would be better. The risks of this approach are recursive covenants and the creation of MEV scenarios, but it seems to me that there’s also a risk of stifling development if we won’t build anything until a new limited opcode is added for it in an event that might only happen once every four years, plus the risk of adding specialized opcodes or sighashes to Bitcoin that we will need to support forever but which might never see any significant use. This is a nice sentiment, and the “CISC vs. RISC” debate is a great target for its own thread, but in general I think even when you set aside large script sizes and the difficulty of working with bitcoin script, CAT and CSFS are non-starters. The amount preservation and batching features of the `OP_VAULT` design would require 64 bit arithmetic in script, as well as opcodes that facilitate taptweak checks (merkle operations), and pushing various parts of the transaction to the stack. The “deferred checks” aspect of VAULT, which enables batching (and would be required for signature aggregation), requires fundamental modifications to the validation code outside of script. The “open sandbox in script” approach, again enviable for its permissionlessness, just doesn’t seem realistically workable to me given all these prerequisites. Or we’d be talking about a script overhaul that entails a much larger fork. There’s also probably a camp of people who would argue that it’d rather be worth focusing on Simplicity to get to that level of complexity in script. And once we get there, if we got there, we’d have to contend with the brittle nature of writing these scripts and the ensuing on-chain footprint. And the eventual “jetting” of opcodes that emerge from the on-chain experimentation. These criticisms apply to proposals like MATT and OP\_TX. * * * I really see where you’re coming from on this one, and at a low level I agree with you, I just don’t think it’s the most expeditious path to making bitcoin much more useful on the scale of a few years. --- _[View the full topic](https://delvingbitcoin.org/t/covenant-tools-softfork/98)._