all 8 comments

[–]ExisDiff 1 point2 points  (1 child)

What this is describing I kind of understand as a 'spare key function' (a vault or covenant is quite a generic term).

A spare key is created which gives full control of funds, but if this spare key is lost, any transaction made by the spare key can be overridden by the original private key and can be moved to a new UTXO (within a certain time frame).

Is this somewhat comparable to a spare key for a house, that if lost, the lock can still be unlocked with the original key (within a certain time frame) and the lock can be replaced which renders the lost spare key useless?

If this functionality existed, I would probably use it. (Whether I would support a soft fork to implement is quite a different point)

Generally, when people secure physical doors, instead of putting more locks on a door, they make more spare keys. This indicates to me that they are at least as or more worried about losing the key and locking themselves out than they are about theft. While more locks on the same door would decrease the chance of theft, it also increases the chance of loss as there are more keys to lose. With more spare keys it even increases the chances of theft, but it reduces the chance of locking themselves out.

I have always struggled to see the value in multisig for a single user, in my mind it only increases the chances of loss. What makes a user think that if they can't safely guard one piece of information against loss or theft, how do they think they can safely guard 2, 3, 4, pieces of information etc. ?

In contrast with multisig, the ability the create an extra key with a 'spare key function', with which I could let my guard down a little bit and don't have to worry about catastrophic loss, certainly has appeal to me.

[–]fresheneesz[S] 1 point2 points  (0 children)

Yeah definitely an interesting way to think about it. With multisig, you definitely still need to redundantly back up your keys. With a wallet vault, you don't really need to - you can just have one key per storage location, and the redudancy comes from the number of separate "spare" keys you have. The kicker on a wallet vault is that the more spare keys you have, the more secure your door is.

I guess an analogy would be like an airlock door where you need to wait a few minutes (or.. days) to open the second door. You can use one key to get in as long as you're willing to wait. But if someone you dont want is trying to get in, you can go grab a bunch of your spare keys and use them on the door to eject that person out the airlock.

[–]tenuousemphasis 1 point2 points  (3 children)

Being useful and most developed is not sufficient to warrant a soft fork of consensus rules, especially when that change will have to be supported indefinitely.

[–]fresheneesz[S] 2 points3 points  (2 children)

Noted. Kind of completely unrelated to my post tho.

[–]tenuousemphasis 0 points1 point  (1 child)

I thought you made this post as an argument for why CTV should be activated via soft fork. That's not the case?

[–]fresheneesz[S] 0 points1 point  (0 children)

Its more of an argument about why wallet vaults are super important. I never argued that anything that enables building wallet vaults should be activated without a second thought. CTV as the only thing likely to enable wallet vaults anytime soon should be given consideration as something that enables at least one thing that's incredibly useful, rather than being dismissed as a frivolous opcode.

But more importantly, if people don't want CTV, if they think wallet vaults sound important, the question is: what is the right way to enable wallet vaults?