Date: Tue, 17 Jan 2023 17:46:38 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Andrew Chow <lists@achow101.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <Y8ZSXrxfR8HrB8zD@erisian.com.au>
References: <afde051e-4e63-368c-3251-70f829a51c4e@achow101.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <afde051e-4e63-368c-3251-70f829a51c4e@achow101.com>
Subject: Re: [bitcoin-dev] OP_VAULT: a new vault proposal
Precedence: list

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