I have to admit - I'm somewhat baffled at the enthusiasm for a "just CAT" softfork, since I can't see that it would achieve much. It's indicative to me that there isn't a compelling example to date that (i) actually has working code and (ii) only relies upon CAT. I'm not averse to CAT, just confused that there's a lot of enthusiasm for a CAT-only fork.
To do actually-interesting covenants, afacit you'd need "introspection" opcodes and/or CHECKSIGFROMSTACK - and even then, for almost all applications I'm familiar with, that kind of CAT-based approach would be much more circuitous than the alternatives that have been discussed for years on this list. > Vaults I don't think this is actually a use-case that CAT materially helps with. Andrew's posts, while well written and certainly foundational, do not sketch a design for vaults that someone would actually use. I don't see how CAT alone (without many auxiliary introspection opcodes) facilitates vaults that clear the usability hurdles I describe in this paper: https://jameso.be/vaults.pdf. For example, batched withdrawals and partial unvaultings don't seem possible. Even with introspection opcodes, Burak's ( https://brqgoo.medium.com/emulating-op-vault-with-elements-opcodes-bdc7d8b0fe71) prototype wasn't able to handle revaulting - an important feature for usability (https://twitter.com/jamesob/status/1636546085186412544). > Tree signatures To what extent does Taproot obviate this use?
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
