Author: ZmnSCPxj 2022-05-08 02:19:57
Published on: 2022-05-08T02:19:57+00:00
In a recent discussion on the Bitcoin-dev mailing list, ZmnSCPxj raised a question regarding the use of `OP_CAT` in enabling recursive covenants. In response to this, it was noted that even with `OP_CAT`, non-recursive covenants can be enabled without recursive covenants being enabled. However, when `OP_CAT` is used in conjunction with `OP_CHECKSIGFROMSTACK`, recursive covenants can be enabled. The question was then asked as to why `CTV+CAT` does not enable recursive covenants while `CSFS+CAT` does. It was suggested that this may be due to the fact that CTV does not allow for a verified copy of the input's prevout scriptPubKey on the stack, whereas with `OP_CSFS` this is possible because the signature hash covers it. However, it was noted that having a verified copy of the scriptPubKey on the stack is not actually necessary for recursion. Instead, it was suggested that the script could simply contain a copy of itself as an initial push (minus this push), allowing for the reconstruction of the full script quine using `OP_CAT`. It was then concluded that while `OP_CAT` does not by itself make recursive covenants possible, it makes all covenant opcodes recursive since it allows for quining. It was further noted that `OP_CAT` is not enabled until after it has been determined that recursive covenants are not unsafe.
Updated on: 2023-06-15T20:32:37.288586+00:00