From: "James O'Beirne" <james.obeirne@gmail•com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] OP_VAULT: a new vault proposal
Date: Tue, 10 Jan 2023 09:17:49 -0500 [thread overview]
Message-ID: <CAPfvXfKRmhHBP8KTKsGCac4OTPydxXQPDv0LqeOrzXNxgZxfrQ@mail.gmail.com> (raw)
In-Reply-To: <CAPfvXfL65cneOabmxfOzTZq14xN4vXNaGboq_g15-frM14RqGA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3358 bytes --]
Forwarding in some conceptual feedback from the pull request.
From ariard:
> I've few open questions, like if the recovery path should be committed
with a signature rather than protected by a simple scriptpubkey preimage.
That's something I've wondered about too. I have to ruminate on AJ's good
post about this, but a pretty straightforward way of enabling this (at the
expense of some complexity) is to do something like "if
<recovery-path-hash> is 32 bytes, treat it as it's currently used. If it's
33 bytes, use the first byte as a parameter for how to interpret it." To
start with, an extra prefix byte of 0x00 could mean "require a witness
satisfying the scriptPubKey that hashes to the remaining 32 bytes" in the
same way we do the unvault signing. This would enable a "sign-to-recover"
flow at the option of the user, specified during vault creation.
> The current OP_VAULT implementation is using OP_NOP repurposing but this
doesn't seem compatible with Taproot-only extensions (e.g ANYPREVOUT) and
maybe a OP_SUCCESS could be used.
Yes, with Greg's suggestion of putting <target-hash> on the witness stack
during OP_VAULT (-> OP_UNVAULT) spend, we could conceivably move
OP_VAULT/OP_UNVAULT into Taproot-only OP_SUCCESSx opcodes. I haven't
thought hard about how worthwhile it is to preserve the ability to use
OP_VAULT in pre-Taproot contexts.
> There is a conceptual wonder, if a CTV and template malleability approach
wouldn't better suit the vault use-case and allow other ones, as such
better re-usability of primitives.
I dedicated a whole section of the paper ("Precomputed vaults with
covenants") to explaining why precomputed covenant mechanisms have big
shortcomings for vaults.
That said, a number of people have commented about OP_VAULT's ability to
(inefficiently) emulate CTV. I'm still very supportive of CTV, I just don't
really have any uses I personally understand inside and out aside from
vaults... so if others do, they should really post about it on this list
and we should resume working on an activation for CTV!
---
From naumenkogs:
> I'm personally not sure batching withdrawals is that compelling... It's a
nice-to-have, but I'd think about the benefits dropping this feature would
provide.
Having familiarity with a few large-scale custodial operations, I think
batching is a really big deal. And if you're going to support multiple
deposits to the same vault, no support for batching is going to result in a
lot of unnecessary output creation even as a small user if you're, e.g.,
doing weekly automated deposits from an exchange to a vault you've
configured.
Darosior comments:
> On the contrary i think the batching feature is very compelling. The
impossibility to batch Unvaults in Revault is a major drawback: it
significantly increases the cost of any realistic operation (you need one
whole additional transaction per input, and each have likely more than one
output). It also potentially increases the cost on the network (you'd
likely want some sort of anchor output on each Unvault tx, that you might
not spend, so that's 2*n outputs created with n the number of coins spent):
we definitely don't want to prevent batching. The ability to batch the
recovery transactions (what we called Emergency tx in Revault) is also very
compelling but i think your comment was only about batched withdrawals.
[-- Attachment #2: Type: text/html, Size: 14209 bytes --]
next prev parent reply other threads:[~2023-01-10 14:18 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-09 16:07 James O'Beirne
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 [this message]
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=CAPfvXfKRmhHBP8KTKsGCac4OTPydxXQPDv0LqeOrzXNxgZxfrQ@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