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
Precedence: list

--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&#39;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&#39;s<br>viability has only grown over the years.<br><br>Since p=
eople first started discussing vaults, it&#39;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 &quot;minimum-viable&quot; 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 &quot;general&quot; 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&#39;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&#39;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&#39;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--