Reading this I also have the feeling that this is just a combination of existing OP codes or a script that can be done using existing ones (OP_CHECKLOCKTIMEVERIFY and OP_IF).
I also disliked the unvaulting process where you have to send the "vaulted" coins to a new special output to be "unvaulted" before you can spend them normally. In other words it requires 2 transactions to spend a vaulted coin.
Yes. And?
I don't see much of a purpose for "vaulting" and "unvaulting" funds as it seems to serve the same purpose and doesn't add much/any extra security than a multisig might.
I disagree. Per the author,
Vaults are an especially useful kind of covenant that give Bitcoin users operational simplicity
during expected use, but heightened security in the event of unauthorized access to private keys
Multisig does the same though?
I'm.sure there could be a mistake I've made in this (hence why I didn't post it straight away) but why is this different from.a 2of2 multisig where a time locked transaction is signed from.them 2 and held in a wallet. The second can still sign for funds to be spent if they want to at any time (to cosign the first) but it could be stored in a more secure manner (such as on an airgapped machine).
Considering you have to store extra values in op_vault (an extra address at least) it just seems like a less efficient way to do it.
I think NotATether was getting at the idea that an attacker unvaulting coins wouldn't be waiting around with their transaction too and would try to do both broadcasts fairly quickly.
Multisigs with timelocks and other script constructions do not do what OP_VAULT enables.
There are constructions for vaults today, however they involve the use of presigned transactions and destroying keys. This is generally fragile and has several pitfalls, the obvious being loss of the presigned transactions means loss of the funds. It turns the transactions into secret data, and transactions are much larger, so this becomes harder to deal with. There are other issues such as the vault cannot be reused (the key was destroyed after setup, so no new inputs can be signed for) and the destinations and amounts cannot be changed after the setup. OP_VAULT solves these things.
OP_VAULT makes it so that the secret data in the vault is still just private keys. Because it's a script, it can be reused and receive coins even after setup. The destinations of the coins can be determined during unvaulting, not during setup.
And what happens if somebody needs to move the coins that are delayed by the vault, because an unauthorized person initiated the transfer in the first place? Will RBF still work in that kind of enclave, or does this design require the consensus to reject such transactions?
The way I understand it, the RBF itself has to be changed and added to the protocol as part of the consensus rules (it currently is just an option) at least for transactions containing the proposed OP codes so that they can treat them differently and enforce it correctly too (ie. reject if the "ephemeral anchor" was not optional).
Yeah, I don't see that happening. It sounds like a more extreme version of fullrbf where instead of being default-on, the "off" switch is completely disabled.
And then all the other full nodes which do not have any support for "node policies" would have to implement the RBF capability as well.
Actually it doesn't. There aren't any additional changes to RBF required that aren't already planned and in the works. Ephemeral anchors requires package relay and validation, which is already largely in progress. It just adds one additional rule for detecting and handling the anchor output. Otherwise, OP_TRUE outputs are already valid, as are 0-value outputs and spending them. It's just a policy change, there's no consensus meaning applied to ephemeral anchors.
And what happens if somebody needs to move the coins that are delayed by the vault, because an unauthorized person initiated the transfer in the first place? Will RBF still work in that kind of enclave, or does this design require the consensus to reject such transactions?
There are two methods for recovering the coins. The first is to double spend the unvault, and the second is to recover during the spend delay. In the first method, you would double spend the OP_VAULT input with a transaction that sends those funds to the recovery address. Doing this requires package RBF to be implemented (and this is something that is already in progress) as well as ephemeral anchors. The recovery just needs to pay a package feerate that's higher than the unvaulting. However, even if this fails (or is not done) and the unvaulting transaction is confirmed, there is still an additional delay before the unvaulted coins can actually be moved to their final destinations. During this time, the coins still be swept to the recovery address by a transaction that spends the OP_UNVAULT output and sends everything to the recovery address. This does not require RBF, and the only consensus changes are those required to implement the semantics of the opcodes themselves.
I also want to note that the author of this proposal has been working on vault constructions for a very long time. It's highly likely that if you think of an "obvious" construction, he's likely thought or heard of it already. The motivation of this proposal is that there is no way to construct a vault that meets the "idealized vault" described in the paper using today's consensus and policy rules.
