Thanks a lot for the many clarifications. Yeah, I forgot it wasn't OP_CAT alone, but in combination with other things. I guess this wouldn't be a covenants proposal then. But simplicity would enable covenants too indeed, no? Or did I get that wrong too?
On Sat, May 7, 2022 at 5:06 AM ZmnSCPxj <zmnsc...@protonmail.com> wrote: > Good morning Jorge, > > > 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. > > I think the more accurate reason for why it was removed is because the > following SCRIPT of N size would lead to 2^N memory usage: > > OP_1 OP_DUP OP_CAT OP_DUP OP_CAT OP_DUP OP_CAT OP_DUP OP_CAT OP_DUP > OP_CAT OP_DUP OP_CAT ... > > In particular it was removed at about the same time as `OP_MUL`, which has > similar behavior (consider that multiplying two 32-bit numbers results in a > 64-bit number, similar to `OP_CAT`ting a vector to itself). > > `OP_CAT` was removed long before covenants were even expressed as a > possibility. > > Covenants were first expressed as a possibility, I believe, during > discussions around P2SH. > Basically, at the time, the problem was this: > > * Some receivers wanted to use k-of-n multisignature for improved security. > * The only way to implement this, pre-P2SH, was by putting in the > `scriptPubKey` all the public keys. > * The sender is the one paying for the size of the `scriptPubKey`. > * It was considered unfair that the sender is paying for the security of > the receiver. > > Thus, `OP_EVAL` and the P2SH concept was conceived. > Instead of the `scriptPubKey` containing the k-of-n multisignature, you > create a separate script containing the public keys, then hash it, and the > `scriptPubKey` would contain the hash of the script. > By symmetry with the P2PKH template: > > OP_DUP OP_HASH160 <hash160(pubkey)> OP_EQUALVERIFY OP_CHECKSIG > > The P2SH template would be: > > OP_DUP OP_HASH160 <hash160(redeemScript)> OP_EQUALVERIFY OP_EVAL > > `OP_EVAL` would take the stack top vector and treat it as a Bitcoin SCRIPT. > > It was then pointed out that `OP_EVAL` could be used to create recursive > SCRIPTs by quining using `OP_CAT`. > `OP_CAT` was already disabled by then, but people were talking about > re-enabling it somehow by restricting the output size of `OP_CAT` to limit > the O(2^N) behavior. > > Thus, since then, `OP_CAT` has been associated with ***recursive*** > covenants (and people are now reluctant to re-enable it even with a limit > on its output size, because recursive covenants). > In particular, `OP_CAT` in combination with `OP_CHECKSIGFROMSTACK` and > `OP_CHECKSIG`, you could get a deferred `OP_EVAL` and then use `OP_CAT` too > to quine. > > Because of those concerns, the modern P2SH is now "just a template" with > an implicit `OP_EVAL` of the `redeemScript`, but without any `OP_EVAL` > being actually enabled. > > (`OP_EVAL` cannot replace an `OP_NOP` in a softfork, but it is helpful to > remember that P2SH was pretty much what codified the difference between > softfork and hardfork, and the community at the time was small enough (or > so it seemed) that a hardfork might not have been disruptive.) > > > 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. > > If you are willing to work in Taproot the same OP-code can be enabled in a > softfork by using a new Tapscript version. > > If you worry about quantum-computing-break, a new SegWit version (which is > more limited than Tapscript versions, unfortunately) can also be used, > creating a new P2WSHv2 (or whatever version) that enables these opcodes. > > > 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. > > No, it was `OP_EVAL`, not `OP_CAT`. > In particular if `OP_EVAL` was allowed in the `redeemScript` then it would > enable covenants as well. > It was just pointed out that `OP_CAT` enables recursive covenenats in > combination with `OP_EVAL`-in-`redeemScript`. > > In particular, in combination with `OP_CAT`, `OP_EVAL` not only allows > recursive covenants, but also recursion *within* a SCRIPT i.e. unbounded > SCRIPT execution. > Thus, `OP_EVAL` is simply not going to fly, at all. > > > 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. > > `OP_CAT`, by itself, does not implement any covenants --- instead, it > creates recursive covenants when combined with almost all covenant opcodes. > > Regards, > ZmnSCPxj >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
