Incorporation of bitcoin vaults into the draft

[corollari]

After reading through the current draft, I'd like to bring to your attention the concept of Bitcoin Vaults, which hasn't received much focus so far but that I believe might be interesting to discuss in this scenario, as it could add some value to this draft.

Concept

Instead of using standard multisigs or P2KH to store the coins under custody, a more complex script can be used to deters attackers and/or establish withdrawal protocols enforced by the Bitcoin consensus.

Background

As far as I know the idea of Bitcoin Vaults was originally proposed on the Bitcoin covenants paper but that proposal required a soft-fork to work, so it's not really interesting.

A few years later, Bryan Bishop proposed another scheme on the bitcoin-dev mailing list that takes the original idea and makes it's implementation viable in the current Bitcoin chain, turning it into something much more interesting for custodians.

Bitcoin Vaults

Essentially, the scheme describes a system where withdrawal of funds is delayed and during that delay it's possible to send the coins back to the vault, thus if the keys ever get stolen, the original owner can just lock them forever. The idea is that, by introducing the possibility of denying the attacker their reward, attackers will be less likely to target the system.

Expanded vaults

Using the same primitives, covenants and relative timelocks, it is possible to construct the following schemes:

• Arbitrary hierarchy of keys: At the bottom you'd have weakly-secured keys that can withdraw the money really slowly, and as you go up in the hierarchy the keys get more strongly secured and have more power (can revoke transactions issued by lower keys).
• Staged partial withdrawals: Make it possible for weakly-secured keys to only withdraw small amounts (eg: 1% per day) while strongly-secured keys can withdraw more money. This is interesting because current custodian solutions need to use their keys every time there is a movement of funds to a hot wallet, therefore putting the whole cold wallet at risk, while with staged withdrawals you could just use the lower-level keys for that and if they get stolen an attacker would only be able to steal part of the funds. This may also be able to remove the need to have hot wallets.

Drawbacks

The main problem I can see with this approach is that the script used for these vaults will need to be revealed to the world, and given that it is a non-standard script, that will leak data on the owner of the coins locked there. Note that this has already happened in the past with non-standard multisig scripts, see the section on Real life example - Rare multisignature scripts in the Privacy page of the bitcoin wiki. I don't really know how if this is a problem at all for this usecase, but it might be possible to solve it by using P2SH-encumbered transaction trees and ECDSA MPC (Multi Party Computation) schemes.

Other blockchains

The design proposed here can be also easily implemented in any chain that supports smart contracts, such as Ethereum, where smart-contract-based wallets are starting to become the norm and could actually be used to build much more complex mechanisms than the ones described here.

As of 21/2/2021, a back-of-the-envelope sum of the market cap of the biggest currencies that could support vaults (btc, eth, bch, bsv, ltc, eos) accounts for 80% of the global cryptocurrency market cap.

[kanzure]

I would clarify that in the "expanded vaults" section, or just before it, that I actually consider the staged partial withdrawals to be required. Otherwise, the scheme breaks down and isn't helpful. The reason why is because the attacker might just wait for the user to broadcast the delay transaction, and then the attacker strikes by stealing 100% of the funds from the hot wallet when the user moves the funds over. The staged withdrawals are, therefore, required to have any security benefit, in a model where attackers can be patient.

There are a few implementations and demos floating around now, mine was released yesterday:

• https://github.com/kanzure/python-vaults
• https://github.com/re-vault/re-vault

cc @kloaec @shommel @JSwambo @mcelrath

[mcelrath]

Vaults are an incredible additional complexity.

In addition to Bryan's point about sharding your wallet, there are at least 3 implied wallets, each of which should have multi-sig in principle. Your "active wallet" can be divided into a "sending" and "receiving" wallet, then there's the "vault" device(s) which hold pay-to-recovery-wallet transactions/data (in the case of CTV), and the recovery wallet itself. On top of that there is design considerations around the "watchtower" which is responsible for noticing a theft and sending to your recovery wallet. This could be automated but there are new privacy and attack vectors there, as well as concerns about how to properly incentivize a watchtower. Then there's questions about secure communication and nonce protocols for the multiple devices involved.

While I generally favor adding these considerations, it's complex.

I think first anyone interested in this topic should first weigh in on @kanzure's post to the bitcoin-dev mailing list, and his code.

Anyone interested in reviewing our paper drafts on this topic before publication, please ping me privately. We're looking for someone to look at our "threat model" through the lens of a CSO/Risk type person, and give us some feedback. (right now...)