Date: Sat, 07 May 2022 03:06:23 +0000
To: =?utf-8?Q?Jorge_Tim=C3=B3n?= <jtimon@jtimon.cc>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <1JO1xrnJ9GwGM4TgLH_rL_LpnZgSb1SyeEOJ9Gzc1VMbKUrmxSh-zUXKwFNvp_5wyiDtRviOf-gRJbrfbhOJl-qym1eEHXpoDAgjE9juucw=@protonmail.com>
In-Reply-To: <CABm2gDoivzQKFr6KqeqW6+Lx7xFVprRCUAn1k3X6P29NPzw+yQ@mail.gmail.com>
References: <CABm2gDoivzQKFr6KqeqW6+Lx7xFVprRCUAn1k3X6P29NPzw+yQ@mail.gmail.com>
Feedback-ID: 2872618:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Speedy covenants (OP_CAT2)
Precedence: list

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 techn=
ical concern about the OP besides enabling covenants.Before it was a common=
 opinion that covenants shouldn't be enabled in bitcoin because, despite ha=
ving 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 dange=
rs 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 foll=
owing 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 possibi=
lity.

Covenants were first expressed as a possibility, I believe, during discussi=
ons 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 `scriptPu=
bKey` 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 th=
e receiver.

Thus, `OP_EVAL` and the P2SH concept was conceived.
Instead of the `scriptPubKey` containing the k-of-n multisignature, you cre=
ate a separate script containing the public keys, then hash it, and the `sc=
riptPubKey` 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 SC=
RIPTs by quining using `OP_CAT`.
`OP_CAT` was already disabled by then, but people were talking about re-ena=
bling 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*** covenan=
ts (and people are now reluctant to re-enable it even with a limit on its o=
utput 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 r=
emember that P2SH was pretty much what codified the difference between soft=
fork 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 creati=
ng 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, crea=
ting 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 l=
ater.

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 combi=
nation with `OP_EVAL`-in-`redeemScript`.

In particular, in combination with `OP_CAT`, `OP_EVAL` not only allows recu=
rsive 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 cove=
nant 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 tha=
t is better in many senses.Speedy covenants, on the other hand, is much sim=
pler and has been implemented for longer, so in principle, it should be eas=
ier to deploy in a speedy manner.
>
> What are the main arguments against speedy covenants (aka op_cat2) and ag=
ainst deploying simplicity in bitcoin respectively?
> Sorry if this was discussed before.

`OP_CAT`, by itself, does not implement any covenants --- instead, it creat=
es recursive covenants when combined with almost all covenant opcodes.

Regards,
ZmnSCPxj