From: "James O'Beirne" <james.obeirne@gmail•com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] OP_VAULT: a new vault proposal
Date: Mon, 9 Jan 2023 11:07:54 -0500 [thread overview]
Message-ID: <CAPfvXfL65cneOabmxfOzTZq14xN4vXNaGboq_g15-frM14RqGA@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2196 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 2587 bytes --]
next reply other threads:[~2023-01-09 16:06 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-09 16:07 James O'Beirne [this message]
2023-01-09 19:02 ` rot13maxi
2023-01-09 19:31 ` Greg Sanders
2023-01-09 20:32 ` James O'Beirne
2023-01-10 13:35 ` James O'Beirne
2023-01-10 12:29 ` Anthony Towns
2023-01-10 20:22 ` James O'Beirne
2023-01-11 6:52 ` Anthony Towns
2023-01-10 14:17 ` James O'Beirne
2023-01-16 23:47 Andrew Chow
2023-01-17 7:46 ` Anthony Towns
2023-01-18 19:00 ` Billy Tetrud
2023-01-18 23:37 ` James O'Beirne
2023-01-19 22:49 ` Billy Tetrud
2023-01-18 22:45 ` James O'Beirne
2023-01-20 17:43 ` James O'Beirne
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAPfvXfL65cneOabmxfOzTZq14xN4vXNaGboq_g15-frM14RqGA@mail.gmail.com \
--to=james.obeirne@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox