rich1.0npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8https://nostr.ae/npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8njumphttps://nostr.ae📅 Original date posted:2022-05-06 📝 Original message:OP_CAT was removed. If I remember correctly, some speculated that perhaps it was removed because it could allow covenants. I don't remember any technical concern about the OP besides enabling covenants. Before it was a common opinion that covenants shouldn't be enabled in bitcoin because, despite having good use case, there are some nasty attacks that are enabled with them too. These days it seems the opinion of the benefits being worth the dangers is quite generalized. Which is quite understandable given that more use cases have been thought since then. Re-enabling OP_CAT with the exact same OP would be a hardfork, but creating a new OP_CAT2 that does the same would be a softfork. As far a I know, this is the covenants proposal that has been implemented for the longest time, if that's to be used as a selection criteria. And as always, this is not incompatible with deploying other convenant proposals later. Personally I find the simplicity proposal the best one among all the covenant proposals by far, including this one. But I understand that despite the name, the proposal is harder to review and test than other proposals, for it wouldn't simply add covenants, but a complete new scripting language that is better in many senses. Speedy covenants, on the other hand, is much simpler and has been implemented for longer, so in principle, it should be easier to deploy in a speedy manner. What are the main arguments against speedy covenants (aka op_cat2) and against deploying simplicity in bitcoin respectively? Sorry if this was discussed before. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220507/2bd47223/attachment-0001.html>