1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 51C6FC002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 7 May 2022 03:06:31 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 27F6E60A77
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 7 May 2022 03:06:31 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level:
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
FROM_LOCAL_NOVOWEL=0.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=protonmail.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 ahO4EbFXtUMB
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 7 May 2022 03:06:30 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-4318.protonmail.ch (mail-4318.protonmail.ch [185.70.43.18])
by smtp3.osuosl.org (Postfix) with ESMTPS id A2E25607FF
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 7 May 2022 03:06:29 +0000 (UTC)
Date: Sat, 07 May 2022 03:06:23 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail2; t=1651892786;
bh=jcCGuC7i7+wsDLxSiEzT4Mjy2ZQE5b8YD89HeNMs2/M=;
h=Date:To:From:Reply-To:Subject:Message-ID:In-Reply-To:References:
Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
Message-ID;
b=cuowt9gDZ3oNcObTAfpG8klxQduYEbnSGOEBFtpWN2w3RxJyXVGdj5owGcRZqgT23
bWcJPC9VJ1CFB7vP6/19aHJek7N9UXFTaqfeBt5kmG0/zNXr+AAsW1sTR+AUrc9vrl
poqZymUpwVVGttOKQT72yzjGRb8VXjLro4X/pW1sVw7fiAKXOFoEDyfTMTfXeeDgF0
+Mq6K5PXJd1A26b2LG2KpLNjGHF6p+jsKHjbF52lVLybCKD8sV5De+XGYpktQ6PBrX
tX3PutHOM4XhCzJXzO57ecFdtfHgkSotTuD1hF5lC7Y4viV+Bi2RpP0f7hYDgajR4Q
VV2A5xwYHO4Tg==
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)
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 03:06:31 -0000
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
|
