From: "James O'Beirne" <james.obeirne@gmail•com>
To: Billy Tetrud <billy.tetrud@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] OP_VAULT: a new vault proposal
Date: Wed, 18 Jan 2023 18:37:51 -0500 [thread overview]
Message-ID: <CAPfvXf+GaJ-fO9TJVpSaKKhQU79p7krzFQg7+92PA5wHS3ps0Q@mail.gmail.com> (raw)
In-Reply-To: <CAGpPWDbLC-om+SR5boRv8U0RptqRUMYJhYvnLbpvm3AKOuX4Fg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3793 bytes --]
> I don't see in the write up how a node verifies that the destination
> of a spend using an OP_VAULT output uses an appropriate OP_UNVAULT
> script.
It's probably quicker for you to just read through the
implementation that I reference in the last section of the paper.
https://github.com/bitcoin/bitcoin/blob/fdfd5e93f96856fbb41243441177a40ebbac6085/src/script/interpreter.cpp#L1419-L1456
> It would usually be prudent to store this recovery address with every
> key to the vault, ...
I'm not sure I really follow here. Worth noting now that in OP_VAULT the
recovery path can be optionally gated by an arbitrary scriptPubKey.
> This is rather limiting isn't it? Losing the key required to sign
> loses your recovery option.
This functionality is optional in OP_VAULT as of today. You can specify
OP_TRUE (or maybe I should allow empty?) in the <recovery-params> to
disable any signing necessary for recovery.
> Wouldn't it be reasonably possible to allow recovery outputs with any
> recovery address to be batched, and the amount sums sent to each to be
> added up and verified?
I think the space savings from this is pretty negligible, since you're
just saving on the transaction overhead, and it makes the implementation
decently more complicated. One benefit might be sharing a common
fee-management output (e.g. ephemeral anchor) across the separate vaults
being recovered.
> If someday wallet vaults are the standard wallet construct, people
> might not even want to have a non-vault wallet just for use in
> unvaulting.
If you truly lacked any non-vaulted UTXOs and couldn't get any at a
reasonable price (?), I can imagine there might be a mechanism where you
include a payout output to some third party in a drafted unvault trigger
transaction, and they provide a spend of the ephemeral output.
Though you do raise a good point that this construction as written may
not be compatible with SIGHASH_GROUP... I'd have to think about that
one.
> Hmm, it seems inaccurate to say that step is "skipped". While there
> isn't a warm wallet step, its replaced with an OP_UNVAULT script step.
It is "skipped" in the sense that your bitcoin can't be stolen by having
to pass through some intermediate wallet during an authorized withdrawal
to a given target, in the way that they could if you had to prespecify
an unvault target when creating the vault.
---
> My proposal for efficient wallet vaults was designed to meet all of
> those criteria, and allows batching as well.
Probably a discussion of your proposal merits a different thread, but
some thoughts that occur:
> [from the README]
>
> OP_BEFOREBLOCKVERIFY - Verifies that the block the transaction is
> within has a block height below a particular number. This allows a
> spend-path to expire.
I think this breaks fundamental reorgability of transactions. I think
some of the other opcodes, e.g the one that limits fee contribution on
the basis of historical feerate, are going to be similarly
controversial.
> This is done by using a static intermediate address that has no values
> that are unique to the particular wallet vault address.
Does mean either that (i) this proposal doesn't have dynamic unvaulting
targets or, (ii) if you do, in order to be batch unvaulted, vaulted
coins need to first be spent into this intermediate output?
It sounds like (ii) is the case, given that your unvault target
specification lives in (I think?) the witness for the spend creating the
intermediate output.
If the intermediate address doesn't have any values which are unique to
a particular vault, how do you authorize recoveries from it?
---
Personally I think if you'd like to pursue your proposal, it'd be
valuable to see a full implementation. Might also make it easier to
assess the viability of the proposal.
[-- Attachment #2: Type: text/html, Size: 4409 bytes --]
next prev parent reply other threads:[~2023-01-18 23:38 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2023-01-19 22:49 ` Billy Tetrud
2023-01-18 22:45 ` James O'Beirne
2023-01-20 17:43 ` James O'Beirne
-- strict thread matches above, loose matches on Subject: below --
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
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=CAPfvXf+GaJ-fO9TJVpSaKKhQU79p7krzFQg7+92PA5wHS3ps0Q@mail.gmail.com \
--to=james.obeirne@gmail$(echo .)com \
--cc=billy.tetrud@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