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
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
|
Return-Path: <vjudeu@gazeta.pl>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 2C923C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 11 May 2022 16:03:36 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 23AF183E56
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 11 May 2022 16:03:36 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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,
SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
dkim=pass (1024-bit key) header.d=gazeta.pl
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id BN0v7Top50mw
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 11 May 2022 16:03:34 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from smtpo104.poczta.onet.pl (smtpo104.poczta.onet.pl
[213.180.149.157])
by smtp1.osuosl.org (Postfix) with ESMTPS id 5A4B483E55
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 11 May 2022 16:03:34 +0000 (UTC)
Received: from pmq5v.m5r2.onet (pmq5v.m5r2.onet [10.174.35.25])
by smtp.poczta.onet.pl (Onet) with ESMTP id 4Kz07d5682zmK9;
Wed, 11 May 2022 18:03:25 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013;
t=1652285005; bh=fZwePO9Z5CYuJ+0HswIwuMmdkK1BnPWuFywPJh1RG8o=;
h=From:Cc:To:In-Reply-To:Date:Subject:From;
b=vhmnMUrI1TDLY5b+8g0/amUzIu6r1m7HXZwgk0Goh8GofvxwOKxz+HzSVHTejjEF8
TgOEbJk4HLCWgacZ1214fPIzmCdgRf1PFsT9PfPsEvUUdGkv57h53jnTefKlXebiJW
Lu82DVuZgykPr4dqFbwRLUqTMFwJFwsUJaiFBhqE=
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Received: from [5.173.224.255] by pmq5v.m5r2.onet via HTTP id ;
Wed, 11 May 2022 18:03:25 +0200
From: vjudeu@gazeta.pl
X-Priority: 3
To: alicexbt <alicexbt@protonmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <b4X11F5edHpTf3LtKIQ53TOvUYP7l4AS689gAveWrDpfoeCC_5X8GzxoN8esnd0InoC4gAP46OX-YhxQoBp6nVfolMpNRkkk4DGqoLH2VDg=@protonmail.com>
Date: Wed, 11 May 2022 18:03:25 +0200
Message-Id: <161249063-43e0faa99d531e0f159a89feef8a592b@pmq5v.m5r2.onet>
X-Mailer: onet.poczta
X-Onet-PMQ: <vjudeu@gazeta.pl>;5.173.224.255;PL;4
X-Mailman-Approved-At: Wed, 11 May 2022 16:37:05 +0000
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: Wed, 11 May 2022 16:03:36 -0000
> This transaction has 2 inputs: 0.00074 tBTC and 0.00073 tBTC (0.00074 + 0=
.00073 =3D 0.00147) which is more than output amount 0.001 tBTC
It was created without the second input, see: https://bitcointalk.org/index=
.php?topic=3D5390103.msg59616324#msg59616324
I didn't touch that later, the signatures are the same. Some user named coi=
nlatte just completed it: https://bitcointalk.org/index.php?topic=3D5390103=
.msg60029953#msg60029953
On 2022-05-11 17:25:41 user alicexbt <alicexbt@protonmail.com> wrote:
Hi vjudeu,
It can be changed by using different sighashes, for example, it is possible=
to create a "negative fee transaction", where all transaction costs are pa=
id by receiver. Using SIGHASH_SINGLE | SIGHASH_ANYONECANPAY with a higher a=
mount in outputs than inputs is enough to do that, see testnet3 transaction=
495d2007ae8b741c70c3d278c02ce03702223b9675e954ecabbb634c6cd5bf40.
This transaction has 2 inputs: 0.00074 tBTC and 0.00073 tBTC (0.00074 +=C2=
=A00.00073 =3D 0.00147)=C2=A0which is more than output amount 0.001 tBTC
/dev/fd0
Sent with ProtonMail secure email.
------- Original Message -------
On Saturday, May 7th, 2022 at 9:22 AM, vjudeu via bitcoin-dev bitcoin-dev@l=
ists.linuxfoundation.org wrote:
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.
We have TapScript for that. OP_CAT is defined as OP_SUCCESS, it can be re-e=
nabled in a soft-fork way. For now, OP_CAT in TapScript simply means "anyon=
e can move those coins", so adding some restrictions is all we need to re-e=
nable this opcode. Introducing OP_CAT2 is not needed at all, unless it will=
be totally different, but then it should not be named as OP_CAT2, but rath=
er as OP_SOMETHING_ELSE, it depends how different it will be from OP_CAT.
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 ...
So we can use OP_SUBSTR instead. Maybe even OP_SPLIT will be enough, if dat=
a expansion is the only problem, then we can focus on getting it smaller. O=
r better, we could use OP_FIND that would return true/false answer if eleme=
nt A is a part of element B, when we do byte-to-byte comparison. In general=
, we can use many different string-based functions to do the same things, w=
e can choose something that will not exponentially explode as OP_CAT.
It was considered unfair that the sender is paying for the security of the =
receiver.
It can be changed by using different sighashes, for example, it is possible=
to create a "negative fee transaction", where all transaction costs are pa=
id by receiver. Using SIGHASH_SINGLE | SIGHASH_ANYONECANPAY with a higher a=
mount in outputs than inputs is enough to do that, see testnet3 transaction=
495d2007ae8b741c70c3d278c02ce03702223b9675e954ecabbb634c6cd5bf40.
On 2022-05-07 05:06:46 user ZmnSCPxj via bitcoin-dev bitcoin-dev@lists.linu=
xfoundation.org wrote:
Good morning Jorge,
OP_CAT was removed. If I remember correctly, some speculated that perhaps i=
t was removed because it could allow covenants.I don't remember any technic=
al concern about the OP besides enabling covenants.Before it was a common o=
pinion that covenants shouldn't be enabled in bitcoin because, despite havi=
ng good use case, there are some nasty attacks that are enabled with them t=
oo. These days it seems the opinion of the benefits being worth the dangers=
is quite generalized. Which is quite understandable given that more use ca=
ses 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 si=
milar behavior (consider that multiplying two 32-bit numbers results in a 6=
4-bit number, similar to OP_CATting a vector to itself).
OP_CAT was removed long before covenants were even expressed as a possibili=
ty.
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 scriptPub=
Key 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 creat=
e a separate script containing the public keys, then hash it, and the scrip=
tPubKey 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 SCRI=
PTs by quining using OP_CAT.
OP_CAT was already disabled by then, but people were talking about re-enabl=
ing 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 si=
ze, because recursive covenants).
In particular, OP_CAT in combination with OP_CHECKSIGFROMSTACK and OP_CHECK=
SIG, 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 actual=
ly enabled.
(OP_EVAL cannot replace an OP_NOP in a softfork, but it is helpful to remem=
ber 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 see=
med) 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, 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 f=
or the longest time, if that's to be used as a selection criteria.And as al=
ways, this is not incompatible with deploying other convenant proposals lat=
er.
No, it was OP_EVAL, not OP_CAT.
In particular if OP_EVAL was allowed in the redeemScript then it would enab=
le covenants as well.
It was just pointed out that OP_CAT enables recursive covenenats in combina=
tion with OP_EVAL-in-redeemScript.
In particular, in combination with OP_CAT, OP_EVAL not only allows recursiv=
e covenants, but also recursion within a SCRIPT i.e. unbounded SCRIPT execu=
tion.
Thus, OP_EVAL is simply not going to fly, at all.
Personally I find the simplicity proposal the best one among all the covena=
nt proposals by far, including this one.But I understand that despite the n=
ame, 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 simpl=
er and has been implemented for longer, so in principle, it should be easie=
r to deploy in a speedy manner.
What are the main arguments against speedy covenants (aka op_cat2) and agai=
nst 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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|