Author: Peter Todd 2019-08-12 15:01:10
Published on: 2019-08-12T15:01:10+00:00
A proposal for implementing Bitcoin vaults without the need for soft-forks or software upgrades has been suggested. The scheme binds both users and attackers to use a public observation and delay period before a weakly-secured hot key is allowed to arbitrarily spend coins. This is called pre-signed vaults. During the delay period, there is an opportunity to initiate recovery/clawback which can either trigger deeper cold storage parameters or reset the delay period to start over again for the same keys. One of the components of this is the delete-the-key pre-signed transaction concept where only a single transaction is pre-signed before deleting the key. This is an emulation of a covenant and enforces a certain outcome. Any coin bound by a covenant isn't a coin in the normal sense of the word, and is only acceptable as payment directly if the receiver chooses to accept it. The nuclear abort key is also unnecessary. Unfortunately, delete-the-key doesn't really work for multisig scenarios because nobody would trust that anyone else in the scheme has actually deleted the secret. Alternative fee rates are easier to deal with using delete-the-key, compared to a technique where the private key never existed which can only be used to sign one fee rate per public key, requiring an entirely new vault subtree for each alternative fee rate. A group can participate in a multisig scheme with provably-unknown ECDSA keys. To fix exceedingly large scripts that exceed size limits and sigop limits, they should split up the script into usable chunks and then use the delete-the-key mechanism (or the other one) to create an OR branch that is signable by a single key for which only a single signature is known.
Updated on: 2023-06-13T20:50:04.698013+00:00