From: Anthony Towns <aj@erisian•com.au>
To: Andrew Chow <lists@achow101•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] OP_VAULT: a new vault proposal
Date: Tue, 17 Jan 2023 17:46:38 +1000 [thread overview]
Message-ID: <Y8ZSXrxfR8HrB8zD@erisian.com.au> (raw)
In-Reply-To: <afde051e-4e63-368c-3251-70f829a51c4e@achow101.com>
On Mon, Jan 16, 2023 at 11:47:09PM +0000, Andrew Chow via bitcoin-dev wrote:
> It seems like this proposal will encourage address reuse for vaults,
(That is listed as an explicit goal: "A single vault scriptPubKey should
be able to "receive" multiple deposits")
> However the current construction makes it impossible to spend these
> vaults together. Since OP_VAULT requires the recovery script of the
> unvault output to match what's provided in the input,
I don't think this part is a big problem -- the recovery path requires
revealing a secret, but if you separate that secret from the recovery
path sPK, you could vary the secret. ie:
unvault1 delay recovery1 VAULT
unvault2 delay recovery2 VAULT
where recovery1 = SHA256(SHA256(secret1), rSPK) and recovery2 =
SHA256(SHA256(secret2), rSPK), and both are spendable when the top stack
element is secretN and the first output pays at least the sum of all
the OP_VAULT using inputs to rSPK. So batched recovery could work fine,
I think.
(If you're using the same "recovery" parameter to each VAULT, then
you're revealing which txs are in your vault at spend time, rather than
at receive time, which doesn't seem all that much better to me)
But the problem with this is it prevents you from combining vaults when
spending normally: so if you've got a bunch of vaults with 1 BTC each,
and want to spend 10 BTC on a house, you'll need to make 11 separate
transactions:
* 10 txs each spending a single vault utxo, satisfying
<uN> <delay> <rN> OP_VAULT
via the uN path, creating an output of
<outhash> <delay> <rN> OP_UNVAULT
* 1 tx spending all the OP_UNVAULT outputs to a common set of outputs
<uN>, with nSequence set to a relative timelock of at least <delay>
Whereas if you use an identical OP_VAULT script for all the utxos in
your vault, that can look like:
* 1 tx, spending all the vault utxos, to a single OP_UNVAULT output,
with the same <delay> <rN> that all the inputs share.
* 1 tx spending the OP_UNVAULT output after a delay
But maybe you can get the best of both worlds just by having the unvault
path for OP_VAULT require you to put the vout number for its corresponding
OP_UNVAULT output on the stack? Then if you're doing address reuse, you
use a single vout for multiple inputs; and if you're avoiding address
reuse, you use multiple outputs, and provide the mapping between inputs
and outputs explicitly.
Cheers,
aj
next prev parent reply other threads:[~2023-01-17 7:46 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 [this message]
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
-- 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=Y8ZSXrxfR8HrB8zD@erisian.com.au \
--to=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=lists@achow101$(echo .)com \
/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