{"type":"rich","version":"1.0","author_name":"npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8","author_url":"https://nostr.ae/npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2022-05-07\n📝 Original message:On Sat, May 7, 2022 at 5:52 AM \u003cvjudeu at gazeta.pl\u003e wrote:\n\n\u003e \u003e Re-enabling OP_CAT with the exact same OP would be a hardfork, but\n\u003e creating a new OP_CAT2 that does the same would be a softfork.\n\u003e\n\u003e We have TapScript for that. OP_CAT is defined as OP_SUCCESS, it can be\n\u003e re-enabled in a soft-fork way. For now, OP_CAT in TapScript simply means\n\u003e \"anyone can move those coins\", so adding some restrictions is all we need\n\u003e to re-enable this opcode. Introducing OP_CAT2 is not needed at all, unless\n\u003e it will be totally different, but then it should not be named as OP_CAT2,\n\u003e but rather as OP_SOMETHING_ELSE, it depends how different it will be from\n\u003e OP_CAT.\n\u003e\n\nOh, well, I didn't know any of that. I guess it could be a modification of\nOP_SUCCESS if it makes sense instead of a new opcode.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220507/6b3c1b24/attachment.html\u003e"}