summaryrefslogtreecommitdiff
path: root/88/af466feea847fc8d94c6298f9ca52beaab2fa7
blob: 8e69d04775ad2ce110d9e655a21a729cc2921e4c (plain)
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
Return-Path: <jtimon@jtimon.cc>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 65AAFC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  6 May 2022 22:30:15 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 4081460C0E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  6 May 2022 22:30:15 +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 lzw0KXkQvt4C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  6 May 2022 22:30:14 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-yb1-xb33.google.com (mail-yb1-xb33.google.com
 [IPv6:2607:f8b0:4864:20::b33])
 by smtp3.osuosl.org (Postfix) with ESMTPS id EA8AF60C0B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  6 May 2022 22:30:13 +0000 (UTC)
Received: by mail-yb1-xb33.google.com with SMTP id m128so15192635ybm.5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 06 May 2022 15:30:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=jtimon-cc.20210112.gappssmtp.com; s=20210112;
 h=mime-version:from:date:message-id:subject:to;
 bh=SAeDdBwpQppOYcfXpN0co+i4Y09m9oIEoCruidaCXaM=;
 b=nU9sSo50MqQ1vpn3lFPc6lmw6bKcoz1O6dy9cbrsbPT2aIGAu6lR5TGkOwYY9pW+Oo
 HPJL5TpKFHVB6KRieHkRInIzIkLGZZ8yNbgEYcmXijXLyZjOUsIWDcT/FzP2EOVVtq8r
 Vdqdx8JVIL+i/dighJru5zhnJWd0hbrO7zljVf+xNK2Z3a2BY+0hLR200RD0VDR4wcYF
 VXcDWQBifIW16lvy12fvHgPuuHFz/1hSCt9KNj/sMPWrSAjgYlRaPxVDirozGHj8Gnb5
 JFC+qlwfWmOmayiVhdrPdaiXizwXaVBKfr8sWG4BfFmWf6Pl7qS4a6VjV8YOzmxlsMtv
 TrqQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
 bh=SAeDdBwpQppOYcfXpN0co+i4Y09m9oIEoCruidaCXaM=;
 b=bjEFTbmlLdHRpzLI6YTc0zLnOmH6z7aSAtoJCRGmJLTa52eXvNQ9M5nseeOYU+/8O5
 8H6cRbqz0nIyJmzSLMUDaI9GuKE1wx8kChNyqEATIx32Df6Tb0PG+ccaPMqVS2eKUAmE
 Dif6LMtListTtwxmNbtKJrCPLgcIrFwC1sEDOrMF+ifqVRHLtxBeRwxfPpXQ/MTH5oGE
 Qu6weLr3FeJZIn+Vs5pnb/Gou2P5Q/+9BhRLlt9mVKQIRtJ9VLRRtai8V8tXwylX29YW
 wc4Dvcypb2NzqT0B5qnUuhYY4sfDEkdUS+m9Hk+3jB502kQjb/UGUbX4NnTolL27Ibzm
 vUrw==
X-Gm-Message-State: AOAM531DiVretpUl2SfD0y3GsE4DP1ImAvJV9nfN3AiaRj3nK+apTBKl
 se6iOTBsV+R6vptVhlWO0nrYUxA1g6PjmgpUtWmZkSbLarrkRg7h
X-Google-Smtp-Source: ABdhPJwnH7Ls5tLjUGWuW7+SLQDUh/v8qsN+PCJ0HQujWdPc/o1gP86wy24Dzo7Vzr1xIHw2FfLHQrkNRsZkrMzQi18=
X-Received: by 2002:a25:d1c8:0:b0:648:a463:f2ca with SMTP id
 i191-20020a25d1c8000000b00648a463f2camr4298326ybg.620.1651876212491; Fri, 06
 May 2022 15:30:12 -0700 (PDT)
MIME-Version: 1.0
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Date: Sat, 7 May 2022 00:30:01 +0200
Message-ID: <CABm2gDoivzQKFr6KqeqW6+Lx7xFVprRCUAn1k3X6P29NPzw+yQ@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000dbdad405de5f66d8"
X-Mailman-Approved-At: Fri, 06 May 2022 23:42:26 +0000
Subject: [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: Fri, 06 May 2022 22:30:15 -0000

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

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.

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.
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.
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.

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

<div dir=3D"ltr"><div>OP_CAT was removed. If I remember correctly, some spe=
culated that perhaps it was removed because it could allow covenants.</div>=
<div>I don&#39;t remember any technical concern about the OP besides enabli=
ng covenants.</div><div>Before it was a common opinion that covenants shoul=
dn&#39;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 s=
ince then.<br></div><div><br></div><div>Re-enabling OP_CAT with the exact s=
ame OP would be a hardfork, but creating a new OP_CAT2 that does the same w=
ould be a softfork.</div><div>As far a I know, this is the covenants propos=
al that has been implemented for the longest time, if that&#39;s to be used=
 as a selection criteria.</div><div>And as always, this is not incompatible=
 with deploying other convenant proposals later.<br></div><div>Personally I=
 find the simplicity proposal the best one among all the covenant proposals=
 by far, including this one.</div><div>But I understand that despite the na=
me, the proposal is harder to review and test than other proposals, for it =
wouldn&#39;t simply add covenants, but a complete new scripting language th=
at is better in many senses.</div><div>Speedy covenants, on the other hand,=
 is much simpler and has been implemented for longer, so in principle, it s=
hould be easier to deploy in a speedy manner.<br></div><div><br></div><div>=
What are the main arguments against speedy covenants (aka op_cat2) and agai=
nst deploying simplicity in bitcoin respectively?</div><div><br></div><div>=
Sorry if this was discussed before.</div><div><br></div><div><br></div><div=
><br></div></div>

--000000000000dbdad405de5f66d8--