A bitcoin covenant is a mechanism to enforce conditions on future bitcoin transactions. A bitcoin vault is a specific type of covenant transaction that enforces a time-lock on the transfer of control of funds to a hot wallet, but enables an immediate transfer of funds into a deep cold recovery wallet. This paper demonstrates how to integrate a bitcoin vault into a custody protocol and demonstrates the security properties of that protocol. The vault is implemented using pre-signed transactions with secure key deletion (as proposed in [SHMB20]). It is shown that vault-custody protocols enable the wallet owner to specify their desired balance for an inherent trade-off between the security of and accessibility of bitcoin holdings by adjusting the length of time-locks used. It is also demonstrated that wallet owners have increased control of risk-management by compartmentalizing funds across numerous vault transactions. While it isn't realistic to completely prevent theft, the most likely theft scenarios (compromising the hot wallet) have severely limited profitability for an attacker, deterring attempts at theft from the beginning. The proposed architecture was designed to offer defence-in-depth through redundancy and fault-tolerant functionality as well as countermeasures for class breaks through diversity across hardware and software layers. Finally, the architecture employs a detection (a watchtower) and response system that enables fail-safe recovery from attempted or partial thefts through a second type of covenant transaction, a push-to-recovery-wallet transaction.

A bitcoin covenant is a mechanism to enforce conditions on how the control of coins will be transferred in the future. This work introduces a mechanism to construct a general class of covenants without requiring a change to the consensus rules of bitcoin, in contrast to previous covenant mechanism proposals. An exploration of the broad design space of deleted-key covenants (using pre-signed transactions with secure key deletion) is given with security analyses that demonstrate a range of possible security models. While the power derived from a mechanism for covenants is undisputed, the method of implementation is contentious. One purpose of this work is to contribute to that debate by demonstrating what is possible today without introducing new security risks to bitcoin. On the other hand, this work makes a compelling case for what can be gained through a soft-fork upgrade for either a Script-based covenant mechanism [Rub20] or a change to the signature hash (SIGHASH) system [Dec17]. The former has had several approaches proposed previously. The latter, introduced herein, is based on an independent proposal aimed at improving off-chain protocols which can be exapted to enable recovered-key covenants through elliptic curve key recovery.The dominant differing factor between a covenant mechanism that uses pre-signed transactions with secure key deletion and those that require soft-fork upgrades is the basis of security for each method. The process of secure key deletion is subject to a trade-off between convenience and security. Secure key deletion requires more procedural overhead for a higher level of security (e.g. by relying on multi-signature pre-signed transactions with more signing keys to add redundancy to the deletion process). Moreover, it is recommended that the deletion occurs quickly, which in a multi-party context necessitates interactivity, a practical downside when compared with other mechanisms. Script-based and recovered-key covenants have a non-interactive enforcement, tighter cryptographic assumptions and bypass the trade-off associated with a key deletion process.Key factors that determine the practicality of covenant mechanisms are discussed, including; the enforcement (activation) process, methods for proving accessibility of funds and whether or not they are bound by a covenant, methods for dynamic fee allocation, the cryptographic assumptions that form the basis of their security, and their feasibility in single-party, hierarchical multi-party and adversarial multi-party contexts. Despite the relative downsides of deleted-key covenants, the class of possible covenants it enables is broad and are most practical for custody protocol design. For example, a deleted-key covenant can be used to create layers of security in addition to key management by enforcing combinations of time-locked rate-limits and pre-defined coin flows through an organization. By comparison, it is shown precisely how soft-fork proposals could improve the practicality and utility of bitcoin covenants for custody protocols ...