path: root/a0/9c34d1e58f10d32731521ffa50d222a5381de1

Return-Path: <jtimon@jtimon.cc>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id C2731C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  7 May 2022 13:27:29 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id B12A560E17
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  7 May 2022 13:27:29 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=jtimon-cc.20210112.gappssmtp.com
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id OAN_OBJ3kmFD
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  7 May 2022 13:27:28 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com
 [IPv6:2607:f8b0:4864:20::b34])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 799B6605E3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  7 May 2022 13:27:28 +0000 (UTC)
Received: by mail-yb1-xb34.google.com with SMTP id e12so17317140ybc.11
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 07 May 2022 06:27:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=jtimon-cc.20210112.gappssmtp.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=XsfBkforPGmHwwO21wIgwoHFZyGPdAaH5WHYKicy2p4=;
 b=MrRXU9wL+taaaRjSnNL4RJvjCxMfwHyN5hgp1DarUOoGH6BYutByRgfwvQbvYpBnS9
 AVk5EhMCb9F48pTHLKb8Z/XVBndFgDtdE7P0kTcyiAbgqXxYPq2aBUb67csHVs8KJwtA
 3lzMc16Ba4CkqzIPlFjVupD6uQDWyQo7BI24dRUIt9pxIpa36imY79HnkV1lhiGMIrpF
 vxlGjHcn0p7SY4QP1mbgIY8J3AWH+EjFqu8xCy6p733Jh2/f76vNmtNVN5APwmKUVghX
 VLOZmUBThYp9ae0tDjE+ch1jr/OLPJkNhsa/ppJ05O2QIWkJEk27i1hnUrPaovihFS6B
 HW9A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=XsfBkforPGmHwwO21wIgwoHFZyGPdAaH5WHYKicy2p4=;
 b=7tbLoVdpCOTUPIH6kVkcx1KIzaeCbYpN9kdxwhXY18qOI6YbeRCoOMy9hBCZ32iI+F
 B70qbmFoV7vT7kpw/RRHICXOzEWeAY+Ncb8bJJp8Yyc8etugn3VCqRPm6VxCdWIpBbaI
 ZDR+OCUwZKLDSqUY2LZRJ7qFq3zGFZMdzeJnOwyJo/JCNIzGmV5lyjoEvG6De6GNK5ke
 pJm0+pOjuOl0MmCJW4DZz7PEr6kJB6paN8YOHUIEqUrtNxMkrurRSo2XgJpe3XfNI8Hq
 CLLzfPRBREg3IgNuie6DvIrh/AzWQYXztMENaVjo+OsjHKlemhNeIkh08uZtlOcmlTY7
 uj+Q==
X-Gm-Message-State: AOAM531Phhtn+MwpTojcaQD/a0OOJI2yjttXbG1oBJIxcRsPn69dhNKh
 nHUtKnTK25hC2FkVNzhpl4qg9wkt3tHmFIqxGq9XGw==
X-Google-Smtp-Source: ABdhPJzzw6B/7Tx12nfvQazsokjlEQlTTAmeqQXd1155+f73lLHuKPYj2Tdl73vLdl9sX5eFPOhqSYikvTycbd7xikY=
X-Received: by 2002:a25:77c1:0:b0:648:3fb0:d5cf with SMTP id
 s184-20020a2577c1000000b006483fb0d5cfmr6062740ybc.511.1651930047302; Sat, 07
 May 2022 06:27:27 -0700 (PDT)
MIME-Version: 1.0
References: <CABm2gDoivzQKFr6KqeqW6+Lx7xFVprRCUAn1k3X6P29NPzw+yQ@mail.gmail.com>
 <1JO1xrnJ9GwGM4TgLH_rL_LpnZgSb1SyeEOJ9Gzc1VMbKUrmxSh-zUXKwFNvp_5wyiDtRviOf-gRJbrfbhOJl-qym1eEHXpoDAgjE9juucw=@protonmail.com>
In-Reply-To: <1JO1xrnJ9GwGM4TgLH_rL_LpnZgSb1SyeEOJ9Gzc1VMbKUrmxSh-zUXKwFNvp_5wyiDtRviOf-gRJbrfbhOJl-qym1eEHXpoDAgjE9juucw=@protonmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Date: Sat, 7 May 2022 15:27:16 +0200
Message-ID: <CABm2gDrdwMjLu=i0p2m4SZ_91xpr-RvwSSWOnS9jhaQ3uaCxPA@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="000000000000a9e11b05de6bef26"
X-Mailman-Approved-At: Sat, 07 May 2022 21:22:57 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Speedy covenants (OP_CAT2)
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 07 May 2022 13:27:29 -0000

--000000000000a9e11b05de6bef26
Content-Type: text/plain; charset="UTF-8"

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 <ZmnSCPxj@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
>

--000000000000a9e11b05de6bef26
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Thanks a lot for the many clarifications.<br></div><d=
iv>Yeah, I forgot it wasn&#39;t OP_CAT alone, but in combination with other=
 things.</div><div>I guess this wouldn&#39;t be a covenants proposal then.<=
br></div><div>But simplicity would enable covenants too indeed, no?</div><d=
iv>Or did I get that wrong too?<br></div><div><br></div><div class=3D"gmail=
_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, May 7, 2022 at 5:06 A=
M ZmnSCPxj &lt;<a href=3D"mailto:ZmnSCPxj@protonmail.com">ZmnSCPxj@protonma=
il.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex">Good morning Jorge,<br>
<br>
&gt; OP_CAT was removed. If I remember correctly, some speculated that perh=
aps it was removed because it could allow covenants.I don&#39;t remember an=
y technical concern about the OP besides enabling covenants.Before it was a=
 common opinion that covenants shouldn&#39;t be enabled in bitcoin because,=
 despite having good use case, there are some nasty attacks that are enable=
d with them too. These days it seems the opinion of the benefits being wort=
h the dangers is quite generalized. Which is quite understandable given tha=
t more use cases have been thought since then.<br>
<br>
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:<br>
<br>
=C2=A0 =C2=A0 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 ...<br>
<br>
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).<br>
<br>
`OP_CAT` was removed long before covenants were even expressed as a possibi=
lity.<br>
<br>
Covenants were first expressed as a possibility, I believe, during discussi=
ons around P2SH.<br>
Basically, at the time, the problem was this:<br>
<br>
* Some receivers wanted to use k-of-n multisignature for improved security.=
<br>
* The only way to implement this, pre-P2SH, was by putting in the `scriptPu=
bKey` all the public keys.<br>
* The sender is the one paying for the size of the `scriptPubKey`.<br>
* It was considered unfair that the sender is paying for the security of th=
e receiver.<br>
<br>
Thus, `OP_EVAL` and the P2SH concept was conceived.<br>
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.<br>
By symmetry with the P2PKH template:<br>
<br>
=C2=A0 =C2=A0 OP_DUP OP_HASH160 &lt;hash160(pubkey)&gt; OP_EQUALVERIFY OP_C=
HECKSIG<br>
<br>
The P2SH template would be:<br>
<br>
=C2=A0 =C2=A0 OP_DUP OP_HASH160 &lt;hash160(redeemScript)&gt; OP_EQUALVERIF=
Y OP_EVAL<br>
<br>
`OP_EVAL` would take the stack top vector and treat it as a Bitcoin SCRIPT.=
<br>
<br>
It was then pointed out that `OP_EVAL` could be used to create recursive SC=
RIPTs by quining using `OP_CAT`.<br>
`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.<br>
<br>
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).<br>
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.<br>
<br>
Because of those concerns, the modern P2SH is now &quot;just a template&quo=
t; with an implicit `OP_EVAL` of the `redeemScript`, but without any `OP_EV=
AL` being actually enabled.<br>
<br>
(`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.)<br>
<br>
&gt; Re-enabling OP_CAT with the exact same OP would be a hardfork, but cre=
ating a new OP_CAT2 that does the same would be a softfork.<br>
<br>
If you are willing to work in Taproot the same OP-code can be enabled in a =
softfork by using a new Tapscript version.<br>
<br>
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.<br>
<br>
&gt; As far a I know, this is the covenants proposal that has been implemen=
ted for the longest time, if that&#39;s to be used as a selection criteria.=
And as always, this is not incompatible with deploying other convenant prop=
osals later.<br>
<br>
No, it was `OP_EVAL`, not `OP_CAT`.<br>
In particular if `OP_EVAL` was allowed in the `redeemScript` then it would =
enable covenants as well.<br>
It was just pointed out that `OP_CAT` enables recursive covenenats in combi=
nation with `OP_EVAL`-in-`redeemScript`.<br>
<br>
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.<br>
Thus, `OP_EVAL` is simply not going to fly, at all.<br>
<br>
&gt; Personally I find the simplicity proposal the best one among all the c=
ovenant proposals by far, including this one.But I understand that despite =
the name, the proposal is harder to review and test than other proposals, f=
or it wouldn&#39;t simply add covenants, but a complete new scripting langu=
age that is better in many senses.Speedy covenants, on the other hand, is m=
uch simpler and has been implemented for longer, so in principle, it should=
 be easier to deploy in a speedy manner.<br>
&gt;<br>
&gt; What are the main arguments against speedy covenants (aka op_cat2) and=
 against deploying simplicity in bitcoin respectively?<br>
&gt; Sorry if this was discussed before.<br>
<br>
`OP_CAT`, by itself, does not implement any covenants --- instead, it creat=
es recursive covenants when combined with almost all covenant opcodes.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</blockquote></div></div>

--000000000000a9e11b05de6bef26--