Author: Praveen Baratam 2019-08-13 02:44:03
Published on: 2019-08-13T02:44:03+00:00
Bryan Bishop has proposed a method for implementing bitcoin vaults that does not require any soft-forks. Vaults are interesting as a bitcoin cold storage security mechanism because they enable a publicly observable delay period during which time a user could be alerted by a watchtower that a thief might be in the process of stealing their coins. The delayed-spending transaction has a single output with a script like: (30 days AND hot wallet key OR 10 days AND re-vaulting public key OR 1 day AND 4-of-7 multisig OR 0 days and super-secure nuclear abort ragequit key). The proposal involves using pre-signed vault transactions which bind both the user and the attacker to always using a public observation and delay period before a weakly-secured hot key is allowed to arbitrarily spend coins. During the delay period, there is an opportunity to initiate recovery or clawback, which can either trigger deeper cold storage parameters or at least reset the delay period to start over again for the same keys. The idea is to have a sequence of pre-generated pre-signed transactions that are generated in a certain way.The security of this scheme is enforced by pre-signing transactions and deleting private keys, or with the help of SIGHASH_NOINPUT then there's another scheme where private keys are provably never known. This enforces that there's only a specific set of possible outcomes at every step of the vault. Bishop notes that one of the important components of this is the delete-the-key pre-signed transaction concept, where only a single transaction is (pre)signed before deleting the key. He also describes various definitions and pseudocode related to the implementation of the vaults. Bishop believes that having a vault construction might go a long way to discourage would-be attackers, on principle that the attacker might be incapable of recovering their cost-of-attack because the recovery mechanism can lock up the coins indefinitely. The article describes various techniques for improving the security of Bitcoin vaults. It discusses the 'delete-the-key' trick which involves pre-signing a transaction and deleting the private key to lock in that course of action. However, it doesn't work well with multisig scenarios because nobody would trust that anyone else in the scheme has actually deleted the secret.The article also suggests using alternative fee rates and storing parameters for generating the remainder of the tree to optimize the process. Another technique involves recursively-enforced multi-party multisig bitcoin vaults where a single script template is used but populated with different parameters. Moreover, the article discusses fail-deadly mechanisms, key rotation for vaults, single-use seals, and paid defection. The idea of adding the 4-of-7 multisig component is to avoid griefing situations, at the cost of additional security requirements for the 4-of-7 multisig group. It also highlights the importance of handling change and only funding the vault once, and only with the amount that was configured when setting up the vault. Additionally, the article discusses the advantages of financial privacy for custody and segregated vaults, besides being useful for personal cold storage solutions.This is an email thread from the bitcoin-dev mailing list, with Bryan Bishop as the author. The email includes links to transcripts about building on Bitcoin and closed-seal sets and truth lists for privacy. Bishop also acknowledges several people who helped him with his draft, including Jeremy Rubin, Bob McElrath, Andrew Poelstra, Joe Rayhawk, and Tadge Dryja. The email concludes with Bishop's contact information.
Updated on: 2023-06-13T20:51:44.609159+00:00