Here is rijndaels answer in a comment on the post:
“ The hex value that used to be OP_CAT is defined to be an OP_SUCCESS in taproot, meaning that if its in a script, the script is valid. But, since it used to be OP_CAT, software like the mempool-space parser parses it as OP_CAT. BIP-420 picks that value to be OP_CAT, so if CAT were active today, this would be a valid tramsaction. To un-upgraded nodes (like… almost all of them), it is still a valid transaction because it doesnt see CAT, it sees SUCCESS. This is how we can add CAT as a softfork. Upgraded nodes will see 0x7e and interpret it as CAT. Unupgraded nodes will see it as SUCCESS. ”
How did they use op_cat when bitcoin core nodes don’t know how to deal with that op code on the stack?
Here is rijndaels answer in a comment on the post:
“ The hex value that used to be OP_CAT is defined to be an OP_SUCCESS in taproot, meaning that if its in a script, the script is valid. But, since it used to be OP_CAT, software like the mempool-space parser parses it as OP_CAT. BIP-420 picks that value to be OP_CAT, so if CAT were active today, this would be a valid tramsaction. To un-upgraded nodes (like… almost all of them), it is still a valid transaction because it doesnt see CAT, it sees SUCCESS. This is how we can add CAT as a softfork. Upgraded nodes will see 0x7e and interpret it as CAT. Unupgraded nodes will see it as SUCCESS. ”
Yay!
Likely a backend deal with mara
This isn’t “OP_CAT” at all, they just put the OP_SUCCESS value in a script. This is kinda misleading BS
Yep.
its so hard isnt it
interesting