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
|
Return-Path: <james.obeirne@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id CE892C0032
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 26 Oct 2023 16:05:06 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id A6B4E8193E
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 26 Oct 2023 16:05:06 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org A6B4E8193E
Authentication-Results: smtp1.osuosl.org;
dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
header.a=rsa-sha256 header.s=20230601 header.b=Rk8ggdkn
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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,
HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 E9B1TxD2_YSi
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 26 Oct 2023 16:05:05 +0000 (UTC)
Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com
[IPv6:2607:f8b0:4864:20::334])
by smtp1.osuosl.org (Postfix) with ESMTPS id 8AB4B819BC
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 26 Oct 2023 16:05:05 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 8AB4B819BC
Received: by mail-ot1-x334.google.com with SMTP id
46e09a7af769-6cd0963c61cso689649a34.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 26 Oct 2023 09:05:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1698336304; x=1698941104;
darn=lists.linuxfoundation.org;
h=to:subject:message-id:date:from:in-reply-to:references:mime-version
:from:to:cc:subject:date:message-id:reply-to;
bh=U+2WNMAz5wQYdhpfjyIbHCH7DULrhFPswtHGap4pE1Q=;
b=Rk8ggdknpi2xdcXwzmJxcryJjk409ajI3XHMgYkL2JsUSWegsNkF3pImonbDn/Sb/F
0KySoy6gqnaYwqHJbJMpXLL11TSlhilwYsyqe++KAnmsL6hRhcbNWme0gQ2NoE7x3tNS
XNMWqTdhsVyUk3TTHg2+noFLkWYMZgljej2uKaWQt99PozzGVsGXibVB8VhOp5nLGzca
YTjPa6pkYUQi5mMAeGNRxjry3Y+ot1v7e+ScjQ+0PAZnkXVAi2fw1zAV9WRQIPGw1ZY5
HGZFuyzKLayjY21tSIpJmfXg3JKg6X5nva+qR3eaT0UcMVf1yLkahyxCso9JAUZfErlK
Qw4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1698336304; x=1698941104;
h=to:subject:message-id:date:from:in-reply-to:references:mime-version
:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
bh=U+2WNMAz5wQYdhpfjyIbHCH7DULrhFPswtHGap4pE1Q=;
b=h6ZY/29QRzAEGhu/Y9oKUF8vSuHku7qzHxxEjXgrIzE4NDsxujCsfdj2dGz736b7oG
Hu79TpgH4ff9+pfVHzBG0IuWxLFv3GNreg28LZlduJF9e+Bv82HVfpj/jO6d/GtTqz+B
2xqYJtoPnPT95ZTtCTBJfzlMD467WZZ+snk+tS2Yo3UtG5ZHM82YP48i15vZ3Ssht4Pz
0qrxaGShmfExJKvVYjxq1Ojf9gqrNkAT2ZsJV/S6dzjq72BPubtMB1itGFxsDO8EOtor
WjSEJoPn4yDkr1Uh/sXPQMoyDcPRUjb2Q53EwbISxt7KfE+8UkJdi2vtHkQ3iVE348v6
SNqQ==
X-Gm-Message-State: AOJu0YyAEAlUvhMbh+YLfSZsrxuWjr6TNxoKDIhdKH2ZpUFCtAt88SYE
r6vjZDp3WrJYOQD8mSkyZECqCojZRUMuvUYhQtopdzagMZ/xPg==
X-Google-Smtp-Source: AGHT+IH9Jr1OcOjHm0b1cS9N9Z92glXUy/j0EYYvKTFXTZJK9rwMY1LFzF9pUIjHaolC1+80H5QfDoM38FjAVYAVfs0=
X-Received: by 2002:a05:6870:9689:b0:1ea:323e:4f13 with SMTP id
o9-20020a056870968900b001ea323e4f13mr18474490oaq.20.1698336304304; Thu, 26
Oct 2023 09:05:04 -0700 (PDT)
MIME-Version: 1.0
References: <CAEM=y+XDB7GGa5BTAWrQHqTqQHBE2VRyd7VWjEb+zCOMzRP+Lg@mail.gmail.com>
<ZTPoK3aD8kFyhy3T@camus>
In-Reply-To: <ZTPoK3aD8kFyhy3T@camus>
From: "James O'Beirne" <james.obeirne@gmail.com>
Date: Thu, 26 Oct 2023 12:04:52 -0400
Message-ID: <CAPfvXfK667yenYeZi_4iUWskdVaJgS37PC3X0dqYNaehPErDcQ@mail.gmail.com>
To: Andrew Poelstra <apoelstra@wpsoftware.net>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000002096c30608a0bc44"
X-Mailman-Approved-At: Thu, 26 Oct 2023 19:27:57 +0000
Subject: Re: [bitcoin-dev] Proposed BIP for OP_CAT
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: Thu, 26 Oct 2023 16:05:06 -0000
--0000000000002096c30608a0bc44
Content-Type: text/plain; charset="UTF-8"
I have to admit - I'm somewhat baffled at the enthusiasm for a "just CAT"
softfork, since I can't see that it would achieve much. It's indicative to
me that there isn't a compelling example to date that (i) actually has
working code and (ii) only relies upon CAT. I'm not averse to CAT, just
confused that there's a lot of enthusiasm for a CAT-only fork.
To do actually-interesting covenants, afacit you'd need "introspection"
opcodes and/or CHECKSIGFROMSTACK - and even then, for almost all
applications I'm familiar with, that kind of CAT-based approach would be
much more circuitous than the alternatives that have been discussed for
years on this list.
> Vaults
I don't think this is actually a use-case that CAT materially helps with.
Andrew's posts, while well written and certainly foundational, do not
sketch a design for vaults that someone would actually use. I don't see how
CAT alone (without many auxiliary introspection opcodes) facilitates vaults
that clear the usability hurdles I describe in this paper:
https://jameso.be/vaults.pdf. For example, batched withdrawals and partial
unvaultings don't seem possible.
Even with introspection opcodes, Burak's (
https://brqgoo.medium.com/emulating-op-vault-with-elements-opcodes-bdc7d8b0fe71)
prototype wasn't able to handle revaulting - an important feature for
usability (https://twitter.com/jamesob/status/1636546085186412544).
> Tree signatures
To what extent does Taproot obviate this use?
--0000000000002096c30608a0bc44
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I have to admit - I'm somewhat baffled at the ent=
husiasm for a "just CAT" softfork, since I can't see that it =
would achieve much. It's indicative to me that there isn't a compel=
ling example to date that (i) actually has working code and (ii) only relie=
s upon CAT. I'm not averse to CAT, just confused that there's a lot=
of enthusiasm for a CAT-only fork.<br></div><div><br></div><div>To do actu=
ally-interesting covenants, afacit you'd need "introspection"=
opcodes and/or CHECKSIGFROMSTACK - and even then, for almost all applicati=
ons I'm familiar with, that kind of CAT-based approach would be much mo=
re circuitous than the alternatives that have been discussed for years on t=
his list.</div><div><br></div><div>> Vaults</div><div><br></div><div>I d=
on't think this is actually a use-case that CAT materially helps with. =
Andrew's posts, while well written and certainly foundational, do not s=
ketch a design for vaults that someone would actually use. I don't see =
how CAT alone (without many auxiliary introspection opcodes) facilitates va=
ults that clear the usability hurdles I describe in this paper: <a href=3D"=
https://jameso.be/vaults.pdf">https://jameso.be/vaults.pdf</a>. For example=
, batched withdrawals and partial unvaultings don't seem possible.=C2=
=A0</div><div><br></div><div>Even with introspection opcodes, Burak's (=
<a href=3D"https://brqgoo.medium.com/emulating-op-vault-with-elements-opcod=
es-bdc7d8b0fe71">https://brqgoo.medium.com/emulating-op-vault-with-elements=
-opcodes-bdc7d8b0fe71</a>) prototype wasn't able to handle revaulting -=
an important feature for usability (<a href=3D"https://twitter.com/jamesob=
/status/1636546085186412544">https://twitter.com/jamesob/status/16365460851=
86412544</a>).</div><div><br></div><div>> Tree signatures</div><div><br>=
</div><div>To what extent does Taproot obviate this use?<br></div></div>
--0000000000002096c30608a0bc44--
|
