📅 Original date posted:2023-01-09
🗒️ Summary of this message: James O'Beirne proposes a new design, OP_VAULT, for Bitcoin vaults that prioritizes safety benefits without getting hung up on solving the general problem of covenants.
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230109/21bf137d/attachment.html>;
James O'Beirne [ARCHIVE] /
npub1dp…ymz3t
2023-06-07 23:18:16
in reply to nevent1q…8v9k
Author Public Key
npub1dpdfw74plzm03mzglkdegp3hqn6qs9yffqefa5kh98mru49nrg7szymz3tPublished at
2023-06-07 23:18:16Event JSON
{
"id": "2942771c04f998ecf6acb1d6d88423ca9e5e2569c2e74c5a0b91bb72f4ba8b6a",
"pubkey": "685a977aa1f8b6f8ec48fd9b94063704f408148948329ed2d729f63e54b31a3d",
"created_at": 1686179896,
"kind": 1,
"tags": [
[
"e",
"a84542afe0efb7efffac7c1bbcfb71ebcb322bb4dd5fb2586b4f66533f300f6e",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2023-01-09\n🗒️ Summary of this message: James O'Beirne proposes a new design, OP_VAULT, for Bitcoin vaults that prioritizes safety benefits without getting hung up on solving the general problem of covenants.\n📝 Original message:For the last few years, I've been interested in vaults as a way to\nsubstantially derisk custodying Bitcoin, both at personal and commercial\nscales. Instead of abating with familiarity, as enthusiasm sometimes\ndoes, my conviction that vaults are an almost necessary part of bitcoin's\nviability has only grown over the years.\n\nSince people first started discussing vaults, it's been pretty clear that\nsome kind of covenant-enabling consensus functionality is necessary to\nprovide the feature set necessary to make vault use practical.\n\nEarlier last year I experimented with using OP_CTV[1], a limited covenant\nmechanism, to implement a \"minimum-viable\" vault design. I found that the\ninherent limitations of a precomputed covenant scheme left the resulting\nvault implementation wanting, even though it was an improvement over\nexisting strategies that rely on presigned transactions and (hopefully)\nephemeral keys.\n\nBut I also found proposed \"general\" covenant schemes to be\nunsuitable for this use. The bloated scriptPubKeys, both in size and\ncomplexity, that would result when implementing something like a vault\nweren't encouraging. Also importantly, the social-consensus quagmire\nregarding which covenant proposal to actually deploy feels at times\nintractable.\n\nAs a result, I wanted to explore a middle way: a design solely concerned\nwith making the best vault use possible, with covenant functionality as a\nsecondary consideration. In other words, a proposal that would deliver\nthe safety benefits of vaults to users without getting hung up on\ntrying to solve the general problem of covenants.\n\nAt first this design, OP_VAULT, was just sort of a pipe dream. But as I\ndid more thinking (and eventually implementing) I became more convinced\nthat, even if it isn't considered for soft-fork, it is a worthwhile\ndevice to serve as a standard benchmark against which other proposals\nmight be judged.\n\nI wrote a paper that summarizes my findings and the resulting proposal:\nhttps://jameso.be/vaults.pdf\n\nalong with an accompanying draft implementation:\nhttps://github.com/bitcoin/bitcoin/pull/26857\n\nI might work on a BIP if there's interest.\n\nJames\n\n[1]: https://github.com/jamesob/simple-ctv-vault\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230109/21bf137d/attachment.html\u003e",
"sig": "9168057827edefd662beaaca90e985a90b8f0453402fc17da9058f4d4aafed62248f151e46c1fa5eb90a18c661ba9e27537cca404eb52daa7771227770521f86"
}