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
|
Return-Path: <roconnor@blockstream.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 9D046C000E
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 6 Jul 2021 11:26:41 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 7F93D8376D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 6 Jul 2021 11:26:41 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 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_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
dkim=pass (2048-bit key)
header.d=blockstream-com.20150623.gappssmtp.com
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 w17D2OBOd44g
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 6 Jul 2021 11:26:40 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com
[IPv6:2607:f8b0:4864:20::72b])
by smtp1.osuosl.org (Postfix) with ESMTPS id 62ADA83750
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 6 Jul 2021 11:26:40 +0000 (UTC)
Received: by mail-qk1-x72b.google.com with SMTP id g4so19771027qkl.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 06 Jul 2021 04:26:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=blockstream-com.20150623.gappssmtp.com; s=20150623;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=eacrwN+kD9OCFqE4loeIt0N9icanT+hhr5TNJGJifak=;
b=u56kFhhfqmNAr+EMRqHs0K85VszIkfXSBuuV9YPQKoaKKk6r8mP+oiy5GhmVIAucFF
71vZX71JvwSvn2ACmZFbLM7qFRFMoukaXbsG6PHtgwd83X5UY0n6vZd35Ur5VTbqV5AG
Bo7ye6FhZQdMpB5Yp26Qwaa4wEInuVKLZ6NKkEOEZlNxnuMnFFO+HjPf+GPsUe5e8SaL
NnNlquNnfHJZe0kS120kfdJkuyP9w2Ez33ov0ju0FOzbX+v6YHQ1Ggc+4opafUCbZVxz
moDam5wYz2JRZOdL1pxqw5864xHpqaHlI2tzE/AQvZ6pUgqj/X1a31FA6aGWLS9CB7B7
OLHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=eacrwN+kD9OCFqE4loeIt0N9icanT+hhr5TNJGJifak=;
b=PBSkmFG3tmTtKdsmKOq9MrsENyZ4eE4TKxynST/O7dPkDoNtLVdo6Idt0blbMLoDZU
2EGQf/q6XdSbT2G9LT/phkrkwb3h/urOBt2HZw70yhY29z1fV5R73H1ID4Wva1bx03zf
EH0c+htmhkHsTh8u31zxmB+Wq9QeEYKkoBfMHDOD3xgR4logwFyzm+OtE7eVhhMcb2BN
ri5kORiyEJ5eEJrsz3V57F/16AmS3ANAiTghl1g1hnfngivxq+JXNV7KDjPS7cpSfiS4
XDvGQ6jJUxd9XtCTstWFLCI4X9ZkqNv4oqHlH5nebuiRBzHVWuyy1tw5iqhhf+lpaP7t
njIw==
X-Gm-Message-State: AOAM53338tsKoLz5jLZIhLA6vQH0w3QGwLqX9NwyIvffTxysI+rDXbmy
vX0p0Nc9xn0aQIMJvKPCcDKNd47thM/PVVNSjE8djw==
X-Google-Smtp-Source: ABdhPJwad7nOhYdn3h1jZR0G+imqSAua8lPSm7wai+tLDGWLlVtHLM+qXfAoh1Lv5rnTuPVbplaSupQxeMdS3QkaNZ0=
X-Received: by 2002:a37:9606:: with SMTP id y6mr19248767qkd.13.1625570799152;
Tue, 06 Jul 2021 04:26:39 -0700 (PDT)
MIME-Version: 1.0
References: <CAD5xwhjmu-Eee47Ho5eA6E6+aAdnchLU0OVZo=RTHaXnN17x8A@mail.gmail.com>
<20210704011341.ddbiruuomqovrjn6@ganymede>
<CAD5xwhimPBEV_tLpSPxs9B+XGUhvPx_dnhok=8=hyksyi4=B6g@mail.gmail.com>
<20210704203230.37hlpdyzr4aijiet@ganymede>
<5keA_aPvmCO5yBh_mBQ6Z5SwnnvEW0T-3vahesaDh57f-qv4FbG1SFAzDvT3rFhre6kFl282VsxV_pynwn_CdvF7fzH2q9NW1ZQHPH1pmdo=@protonmail.com>
<CAMZUoKnuRXNG1pyupHrL+Wo80TXTbADVrexoB=+BKC633v-qMw@mail.gmail.com>
<CAGpPWDZ6FhAn+dBf-_yf7YVzRB7NWV7zaKqKYewgZecBxWUx5A@mail.gmail.com>
In-Reply-To: <CAGpPWDZ6FhAn+dBf-_yf7YVzRB7NWV7zaKqKYewgZecBxWUx5A@mail.gmail.com>
From: "Russell O'Connor" <roconnor@blockstream.com>
Date: Tue, 6 Jul 2021 07:26:28 -0400
Message-ID: <CAMZUoKkAUodCT+2aQG71xwHYD8KXeTAdQq4NmXZ4GBe0pcD=9A@mail.gmail.com>
To: Billy Tetrud <billy.tetrud@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000000a849f05c672b2e4"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Unlimited covenants,
was Re: CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin
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: Tue, 06 Jul 2021 11:26:41 -0000
--0000000000000a849f05c672b2e4
Content-Type: text/plain; charset="UTF-8"
On Tue, Jul 6, 2021 at 2:26 AM Billy Tetrud <billy.tetrud@gmail.com> wrote:
> > when people are talking about enabling covenants, we are talking about
> whether OP_CAT should be allowed or not
>
> Are they? Are you implying that anything that enables covenants is
> equivalent to enabling OP_CAT? Generally when I think about enabling
> covenants, I'm thinking more about OP_CTV (or some similarly specific
> opcode
> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/bip-constraindestination.md>
> ).
>
> > OP_TWEAK
>
> I wasn't able to find anything about what that is. Would you mind
> clarifying what that concept is?
>
In tapscript one can generally recover the current input's scriptPubkey
through sighash introspection via the usual covenant tricks. This allows
you to make a recursive covenant by spending funds back to the same
identical scriptPubkey. However, in order for a recursive covenant to be
actually interesting, there needs to be some sort of state update in each
transition. If there is no state update then sending funds back to itself
is of very limited value. It will reset the timer on relative locks, but
that is about all.
The "normal" way of writing useful recursive covenants is to modify the
scriptPubkey by changing a fragment of it that contains some sort of
state. However in order to update a tapscript pubkey one needs to apply
not only hashing, to create a Merkel root, but also to create a tweaked
taproot pubkey that commits to this root. While script currently comes
with a SHA-256 hashing opcode, there is no opcode that will let you perform
the necessary tweaking to create a taproot scriptPubkey.
But as I mentioned afterwards, there are other places in the UTXO that you
could put data in order to perform a state update.
--0000000000000a849f05c672b2e4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail=
_attr">On Tue, Jul 6, 2021 at 2:26 AM Billy Tetrud <<a href=3D"mailto:bi=
lly.tetrud@gmail.com">billy.tetrud@gmail.com</a>> wrote:<br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">>=C2=A0
when people are talking about enabling covenants, we are talking about whet=
her OP_CAT should be allowed or not<div><br></div><div>Are they? Are you im=
plying that anything that enables covenants is equivalent to enabling OP_CA=
T? Generally when I think about enabling covenants, I'm thinking more a=
bout OP_CTV (or some similarly specific <a href=3D"https://github.com/fresh=
eneesz/bip-efficient-bitcoin-vaults/blob/main/bip-constraindestination.md" =
target=3D"_blank">opcode</a>).</div><div><br></div><div>> OP_TWEAK=C2=A0=
</div><div><br></div><div>I wasn't able to find anything about=C2=A0wha=
t that is. Would you mind clarifying what that concept is? <br></div></div>=
</blockquote><div><br></div><div>In tapscript one can generally recover the=
current input's scriptPubkey through sighash introspection via the usu=
al covenant tricks.=C2=A0 This allows you to make a recursive covenant by s=
pending funds back to the same identical scriptPubkey.=C2=A0 However, in or=
der for a recursive covenant to be actually interesting, there needs to be =
some sort of state update in each transition.=C2=A0 If there is no state up=
date then sending funds back to itself is of very limited value.=C2=A0 It w=
ill reset the timer on relative locks, but that is about all.</div><div><br=
></div><div>The "normal" way of writing useful recursive covenant=
s is to modify the scriptPubkey by changing a fragment of it that contains =
some sort of state.=C2=A0 However in order to update a tapscript pubkey one=
needs to apply not only hashing, to create a Merkel root, but also to crea=
te a tweaked taproot pubkey that commits to this root.=C2=A0 While script c=
urrently comes with a SHA-256 hashing opcode, there is no opcode that will =
let you perform the necessary tweaking to create a taproot scriptPubkey.</d=
iv><div><br></div><div>But as I mentioned afterwards, there are other place=
s in the UTXO that you could put data in order to perform a state update.<b=
r></div></div></div>
--0000000000000a849f05c672b2e4--
|
