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
|
Return-Path: <james.obeirne@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id DF421C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 18 Jan 2023 22:45:11 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id A708A40475
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 18 Jan 2023 22:45:11 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org A708A40475
Authentication-Results: smtp2.osuosl.org;
dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
header.a=rsa-sha256 header.s=20210112 header.b=ibvOv2HN
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 smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id hV_dtQKiqErL
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 18 Jan 2023 22:45:10 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 6F60C400D2
Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com
[IPv6:2607:f8b0:4864:20::330])
by smtp2.osuosl.org (Postfix) with ESMTPS id 6F60C400D2
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 18 Jan 2023 22:45:10 +0000 (UTC)
Received: by mail-ot1-x330.google.com with SMTP id
k1-20020a056830150100b006864d1cb279so231247otp.5
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 18 Jan 2023 14:45:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:from:to:cc:subject:date:message-id:reply-to;
bh=mibxAKZrdDt+bW0RYSRZLMjGBHo0VH2CgN7g0etYCXc=;
b=ibvOv2HN98o8Qv/q25LapD5oDLrT3cyVGzUcZkjIpImyuulTzOyKjYV+ZPObzHt4NL
Gsah3OIZOYaSNwmNlP0zbqSIApqYfrc9Yrh704fofg+Do7/sMxOzXSfV5YTTUHVJQhAS
ZykvMDnPTTlXhFhYB6ojqY8cwqdtYPdW2W83p3e27OAG13R0FvU/xLsdntxV/mZXW4J2
tQFFiOjPEp9uz4M61ZKhPn99QCNgAet+EvcCSGK2PmBlRQ6LydVaW1Vd3qAX3qETVLRb
aJDroc5W4G/yGqAOr2lRg/hXisS12ByfLdhiXTkAnno8RotcpYnqyUuRswlIQ9+AR3sa
yIEw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=cc: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=mibxAKZrdDt+bW0RYSRZLMjGBHo0VH2CgN7g0etYCXc=;
b=TDjgDt69Qf6phTPnEURuzEJN3Pywotox89jcEQYp2JPuAsWXsd+Ar+L2MFHAmKVfVr
+x9UM//JM/5zvIzHG5j95TCKbIGs9tvSd8efI03ZfplDpp3LvH9Y+cMBG8xIrIDbWTiS
GhDeeZGOjwnfKU1jk+IOiBFi7LVzcKjGvT+6K3v8nOdLsC2th3n/NOyqyeVuhZ87OA08
LeBoItc06e5LWBjPPLSR/8WTKXRngtcTiQ2u+M1FzwXKBAYlKaWHVmQCbKcUa+hR3Z/X
KnOV1cBwTIq3c//LcN0fJZmwJnfBGY9WinGbsViSvlRaO8iQIq+flIcnS0fpzJYhvlZQ
7i6Q==
X-Gm-Message-State: AFqh2kp3G7Lfa/7hvl2BxKlzEQ/tix2PzU25LRLLPoUhXWzFmOOhVfm3
q2CWsBtPL4Ok10Gl6ui7VP5hTrWY+TuWtsGyehCrG4ydiDOfcg==
X-Google-Smtp-Source: AMrXdXsAFwSZyeFMxLgge2GG5Hz0iE78oAbSTxTnxFzgMHqSYZWkI8h3gDLdmoZzniqwQLpKMrJ/TwRSUeytI1eGlS4=
X-Received: by 2002:a9d:4508:0:b0:686:5864:ecf1 with SMTP id
w8-20020a9d4508000000b006865864ecf1mr188185ote.143.1674081909194; Wed, 18 Jan
2023 14:45:09 -0800 (PST)
MIME-Version: 1.0
References: <afde051e-4e63-368c-3251-70f829a51c4e@achow101.com>
<Y8ZSXrxfR8HrB8zD@erisian.com.au>
In-Reply-To: <Y8ZSXrxfR8HrB8zD@erisian.com.au>
From: "James O'Beirne" <james.obeirne@gmail.com>
Date: Wed, 18 Jan 2023 17:45:01 -0500
Message-ID: <CAPfvXfKMsOF1g85Td8UpZdWSH+a0sRXK9Rur1ODduMauJhM+6A@mail.gmail.com>
To: Anthony Towns <aj@erisian.com.au>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000085c6a905f29191aa"
Subject: Re: [bitcoin-dev] OP_VAULT: a new vault proposal
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, 18 Jan 2023 22:45:12 -0000
--00000000000085c6a905f29191aa
Content-Type: text/plain; charset="UTF-8"
I've implemented three changes based on suggestions from Greg Sanders
and AJ Towns.
I've segmented the changes into commits that should be
reasonable to follow, even though I'll probably rearrange the commit
structure later on.
1. Greg's suggestion: OP_UNVAULT outputs can now live behind
scripthashes. This means that the lifecycle of a vault can live entirely
within, say, Taproot. In this case the only thing that would reveal
the operation of the vault would be the content of the witness stack
when triggering an unvault or recovering. So I think no real privacy
benefits over the previous scheme, but certainly some efficiency ones
since we're moving more content from the scriptPubKey into the witness.
Commit here:
https://github.com/bitcoin/bitcoin/pull/26857/commits/cd33d120c67cda7eb5c6bbfe3a1ea9fb6c5b93d1
2. AJ's suggestion: unvault trigger transactions can now have an extra
"revault" output that redeposits some balance to the same vault
scriptPubKey from which it came. This is nice because if the delay
period is long, you may want to manage a remaining vault balance
separately while the spent balance is pending an unvault.
Commit here:
https://github.com/bitcoin/bitcoin/pull/26857/commits/cf3764fb503bc17c4438d1322ecf780b9dc3ef30
3. AJ's suggestion: instead of specifying <recovery-spk-hash>, introduce
a replacement parameter: <recovery-params>. This contains the same
target recovery sPK hash as before, but the remaining bytes contain a
scriptPubKey that functions as authorization for the recovery process.
This allows users to optionally avoid the risk of "recovery replays" at
the expense of having to maintain a recovery key. Users can opt out of
this by passing OP_TRUE for the recovery sPK. I guess maybe I could even
support just omitting an sPK altogether for the legacy behavior.
Commit here:
https://github.com/bitcoin/bitcoin/pull/26857/commits/fdfd5e93f96856fbb41243441177a40ebbac6085
The suggestions were good ones, and I think they've improved the
proposal.
My next steps are to do minor updates to the paper and start writing a
BIP draft.
Thanks to achow for the valuable feedback, which I'm still mulling on.
James
--00000000000085c6a905f29191aa
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr">I've implemented three changes based =
on suggestions from Greg Sanders<br>and AJ Towns. <br><br>I've segmente=
d the changes into commits that should be<br>reasonable to follow, even tho=
ugh I'll probably rearrange the commit<br>structure later on.<br><br>1.=
Greg's suggestion: OP_UNVAULT outputs can now live behind<br>scripthas=
hes. This means that the lifecycle of a vault can live entirely<br>within, =
say, Taproot. In this case the only thing that would reveal<br>the operatio=
n of the vault would be the content of the witness stack<br>when triggering=
an unvault or recovering. So I think no real privacy<br>benefits over the =
previous scheme, but certainly some efficiency ones<br>since we're movi=
ng more content from the scriptPubKey into the witness.<br><br>=C2=A0Commit=
here: <a href=3D"https://github.com/bitcoin/bitcoin/pull/26857/commits/cd3=
3d120c67cda7eb5c6bbfe3a1ea9fb6c5b93d1">https://github.com/bitcoin/bitcoin/p=
ull/26857/commits/cd33d120c67cda7eb5c6bbfe3a1ea9fb6c5b93d1</a><br><br>2. AJ=
's suggestion: unvault trigger transactions can now have an extra<br>&q=
uot;revault" output that redeposits some balance to the same vault<br>=
scriptPubKey from which it came. This is nice because if the delay<br>perio=
d is long, you may want to manage a remaining vault balance<br>separately w=
hile the spent balance is pending an unvault.<br><br>=C2=A0Commit here: <a =
href=3D"https://github.com/bitcoin/bitcoin/pull/26857/commits/cf3764fb503bc=
17c4438d1322ecf780b9dc3ef30">https://github.com/bitcoin/bitcoin/pull/26857/=
commits/cf3764fb503bc17c4438d1322ecf780b9dc3ef30</a><br><br>3. AJ's sug=
gestion: instead of specifying <recovery-spk-hash>, introduce<br>a re=
placement parameter: <recovery-params>. This contains the same<br>tar=
get recovery sPK hash as before, but the remaining bytes contain a<br>scrip=
tPubKey that functions as authorization for the recovery process.<br>This a=
llows users to optionally avoid the risk of "recovery replays" at=
<br>the expense of having to maintain a recovery key. Users can opt out of<=
br>this by passing OP_TRUE for the recovery sPK. I guess maybe I could even=
<br>support just omitting an sPK altogether for the legacy behavior.<br><br=
>Commit here: <a href=3D"https://github.com/bitcoin/bitcoin/pull/26857/comm=
its/fdfd5e93f96856fbb41243441177a40ebbac6085">https://github.com/bitcoin/bi=
tcoin/pull/26857/commits/fdfd5e93f96856fbb41243441177a40ebbac6085</a><br><b=
r><br>The suggestions were good ones, and I think they've improved the<=
br>proposal.<br><br>My next steps are to do minor updates to the paper and =
start writing a<br>BIP draft.</div><div dir=3D"ltr"><br></div><div dir=3D"l=
tr">Thanks to achow for the valuable feedback, which I'm still mulling =
on.</div><div dir=3D"ltr"><br>James</div></div>
--00000000000085c6a905f29191aa--
|
