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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
