Andrew Chow [ARCHIVE] on Nostr: 📅 Original date posted:2023-01-16 🗒️ Summary of this message: Proposal for ...

📅 Original date posted:2023-01-16
🗒️ Summary of this message: Proposal for Bitcoin vaults raises concerns about address reuse and privacy. Implementation may require unique recovery scripts to avoid reuse. Limit usage to tapscripts for simpler implementation.
📝 Original message:Hi James,

This seems like a promising proposal, but I noticed have a few issues
regarding batching and privacy.

It seems like this proposal will encourage address reuse for vaults, at
least in some parts. It seems like it would not be difficult to ensure
that each vault address was unique through the use of key derivation.
The recovery and unvault scripts could be produced from ranged
descriptors and so there would each vault address would be unique as
each recovery and unvault script is unique. It would not be hard to have
descriptors for vaults, which would then allow for usage of other
descriptors and miniscript into the recovery and unvault scripts.

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, if there are
multiple inputs with different recovery scripts, then the transaction
will fail. I'm not sure how this could be solved though.

But from my reading of the code, it looks like the unvault scripts can
be unique, so at least address reuse can be avoided here. It just means
that the recovery scripts must be the same, and this would leave an
identifying mark on chain for every unvault. An observer would be able
to correlate unvault transactions by the hashes of the recovery scripts,
and I think this would be rather detrimental to user privacy, not to
mention that sweeping to recovery would also reveal all of your coins too.

On the topic of address reuse, the implemented optional re-vault output
explicitly requires address reuse, as well as breaking the batched
unvaulting of scripts that have different unvault scripts. It's
currently implemented as requiring the unvault script to exactly match
the prevout script of the inputs being spent. This means that all inputs
must have the same script. I think it would be sufficient to do the same
check as the OP_UNVAULT script and just require that the recovery script
and the delay are the same, with the hash of the trigger script being
provided in the input in the same way the target hash is provided for
OP_UNVAULT. This would break the address reuse requirement.

I'm also not convinced that OP_VAULT and OP_UNVAULT should be allowed
for bare and P2WSH outputs. It seems like it would make sense to just
limit their usage to tapscripts as this would simply their implementation.


Andrew

On 01/09/2023 11:07 AM, James O'Beirne via bitcoin-dev wrote:
> 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