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
|
Return-Path: <james.obeirne@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 68562C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 9 Jan 2023 16:06:41 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 41FD3410BB
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 9 Jan 2023 16:06:41 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 41FD3410BB
Authentication-Results: smtp4.osuosl.org;
dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
header.a=rsa-sha256 header.s=20210112 header.b=BU6EoGZq
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 smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id FR3ZyN5iEJgs
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 9 Jan 2023 16:06:39 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org C3C3C410A3
Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com
[IPv6:2607:f8b0:4864:20::330])
by smtp4.osuosl.org (Postfix) with ESMTPS id C3C3C410A3
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 9 Jan 2023 16:06:39 +0000 (UTC)
Received: by mail-ot1-x330.google.com with SMTP id
v15-20020a9d69cf000000b006709b5a534aso5398718oto.11
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 09 Jan 2023 08:06:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=to:subject:message-id:date:from:mime-version:from:to:cc:subject
:date:message-id:reply-to;
bh=bFdIiMJqMuMuw2GoZnwrPl/6uLoaQ4bNyd6x69/4VnU=;
b=BU6EoGZqc1bGPcPrBrm+1oyFQ0aizVe2IYBWozndGYKbZ2pyYLaABy7bCKOB6TJaQs
63W/zCVSTixtFXI+pJObu0BCObYQbEUkg93gKsDhZtEoAYiHmO1A4FNK3lTapRM91EoF
PouPW+inbekSdyC28SBivIBS1Yn5KBb55jkz7EL2v6PzsF7POSlV1XTzxgDy1QQabZTU
EeSNeFBVDuHK6rpk4s08Wtw9mw2GsuTkNnNqxtFbv6JBz5DIs0AUf3ztbtTXV0M3QbA2
GvTBpyxFKDxNCue8WGbAM6y52MmQM3C3/yI6V/bWi/GK6qOc6hbfamZUtM51Zp05lTYt
tlBQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=to:subject:message-id:date:from:mime-version:x-gm-message-state
:from:to:cc:subject:date:message-id:reply-to;
bh=bFdIiMJqMuMuw2GoZnwrPl/6uLoaQ4bNyd6x69/4VnU=;
b=KTPBytgHnXFqwTa5c1L+ROiXDL4p0GYcDD8Vz6ZT8SmXiQ+5+1s4BOwyRmCh+WTUIp
0ZJq12ZJBBhY9kRbMJVX/qKElVqbpDs0pkSYvToqzIi0VOU/z+DRUkECUD27Qa7HF/W5
hBq9j5lNx6pi28gPTKSecckxucu4kGpGc/lSoWN0NtvJMjk86v48aq55taAHIQAEivnZ
i4IV9TXYCn4HFgmKcQgY2r0yuyfG75XlOTWztOj/aPrkxo7mhh5FouJSLPuiWDLpCfxV
ZCpgez5LnMftDp5PHZfTxK0aBQ0dFVUYyICqOCgMAzzyMovNU0Qoz9goLn/87YkHBava
Y5PQ==
X-Gm-Message-State: AFqh2kreCKAfvAhEf3YUtkDbG9/LcHAfU7h9bQrbX/1Kf4TgMwgwkyHY
raOWqKFLMu6RktgGfLTNQsWKN9i4q3tFS/WwkQEZCOJ+Nx4=
X-Google-Smtp-Source: AMrXdXtpd/vJOBhgfbO0kckyoPg7FIcwf81K/1CYxvenGI9mUZWGFT7EvXr9rK3CSHS6G6f6Eaxl3DL/6z0O9FJOM7g=
X-Received: by 2002:a9d:6a48:0:b0:678:23c0:5f3e with SMTP id
h8-20020a9d6a48000000b0067823c05f3emr4128994otn.347.1673280398235; Mon, 09
Jan 2023 08:06:38 -0800 (PST)
MIME-Version: 1.0
From: "James O'Beirne" <james.obeirne@gmail.com>
Date: Mon, 9 Jan 2023 11:07:54 -0500
Message-ID: <CAPfvXfL65cneOabmxfOzTZq14xN4vXNaGboq_g15-frM14RqGA@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000bf1ab505f1d6f320"
Subject: [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: Mon, 09 Jan 2023 16:06:41 -0000
--000000000000bf1ab505f1d6f320
Content-Type: text/plain; charset="UTF-8"
For the last few years, I've been interested in vaults as a way to
substantially derisk custodying Bitcoin, both at personal and commercial
scales. Instead of abating with familiarity, as enthusiasm sometimes
does, my conviction that vaults are an almost necessary part of bitcoin's
viability has only grown over the years.
Since people first started discussing vaults, it's been pretty clear that
some kind of covenant-enabling consensus functionality is necessary to
provide the feature set necessary to make vault use practical.
Earlier last year I experimented with using OP_CTV[1], a limited covenant
mechanism, to implement a "minimum-viable" vault design. I found that the
inherent limitations of a precomputed covenant scheme left the resulting
vault implementation wanting, even though it was an improvement over
existing strategies that rely on presigned transactions and (hopefully)
ephemeral keys.
But I also found proposed "general" covenant schemes to be
unsuitable for this use. The bloated scriptPubKeys, both in size and
complexity, that would result when implementing something like a vault
weren't encouraging. Also importantly, the social-consensus quagmire
regarding which covenant proposal to actually deploy feels at times
intractable.
As a result, I wanted to explore a middle way: a design solely concerned
with making the best vault use possible, with covenant functionality as a
secondary consideration. In other words, a proposal that would deliver
the safety benefits of vaults to users without getting hung up on
trying to solve the general problem of covenants.
At first this design, OP_VAULT, was just sort of a pipe dream. But as I
did more thinking (and eventually implementing) I became more convinced
that, even if it isn't considered for soft-fork, it is a worthwhile
device to serve as a standard benchmark against which other proposals
might be judged.
I wrote a paper that summarizes my findings and the resulting proposal:
https://jameso.be/vaults.pdf
along with an accompanying draft implementation:
https://github.com/bitcoin/bitcoin/pull/26857
I might work on a BIP if there's interest.
James
[1]: https://github.com/jamesob/simple-ctv-vault
--000000000000bf1ab505f1d6f320
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">For the last few years, I've been interested in vaults=
as a way to<br>substantially derisk custodying Bitcoin, both at personal a=
nd commercial<br>scales. Instead of abating with familiarity, as enthusiasm=
sometimes<br>does, my conviction that vaults are an almost necessary part =
of bitcoin's<br>viability has only grown over the years.<br><br>Since p=
eople first started discussing vaults, it's been pretty clear that<br>s=
ome kind of covenant-enabling consensus functionality is necessary to<br>pr=
ovide the feature set necessary to make vault use practical.<br><br>Earlier=
last year I experimented with using OP_CTV[1], a limited covenant<br>mecha=
nism, to implement a "minimum-viable" vault design. I found that =
the<br>inherent limitations of a precomputed covenant scheme left the resul=
ting<br>vault implementation wanting, even though it was an improvement ove=
r<br>existing strategies that rely on presigned transactions and (hopefully=
)<br>ephemeral keys.<br><br>But I also found proposed "general" c=
ovenant schemes to be<br>unsuitable for this use. The bloated scriptPubKeys=
, both in size and<br>complexity, that would result when implementing somet=
hing like a vault<br>weren't encouraging. Also importantly, the social-=
consensus quagmire<br>regarding which covenant proposal to actually deploy =
feels at times<br>intractable.<br><br>As a result, I wanted to explore a mi=
ddle way: a design solely concerned<br>with making the best vault use possi=
ble, with covenant functionality as a<br>secondary consideration. In other =
words, a proposal that would deliver<br>the safety benefits of vaults to us=
ers without getting hung up on<br>trying to solve the general problem of co=
venants.<br><br>At first this design, OP_VAULT, was just sort of a pipe dre=
am. But as I<br>did more thinking (and eventually implementing) I became mo=
re convinced<br>that, even if it isn't considered for soft-fork, it is =
a worthwhile<br>device to serve as a standard benchmark against which other=
proposals<br>might be judged.<br><br>I wrote a paper that summarizes my fi=
ndings and the resulting proposal:<br><a href=3D"https://jameso.be/vaults.p=
df">https://jameso.be/vaults.pdf</a><br><br>along with an accompanying draf=
t implementation:<br><a href=3D"https://github.com/bitcoin/bitcoin/pull/268=
57">https://github.com/bitcoin/bitcoin/pull/26857</a><br><br>I might work o=
n a BIP if there's interest.<br><div><br></div><div>James<br></div><br>=
[1]: <a href=3D"https://github.com/jamesob/simple-ctv-vault">https://github=
.com/jamesob/simple-ctv-vault</a><br></div>
--000000000000bf1ab505f1d6f320--
|
