Bitcoin Vault

Anna keeps some savings in bitcoin. A wallet is an application or device for receiving and sending bitcoin. Signing here means using a private key, a secret numerical value, to create verifiable proof of authorization for a payment. Others can check the signature without knowing that secret. With an ordinary wallet controlled by a single key, a thief who obtains that key can sign a payment straight to their own address. Bitcoin Vault aims to change that moment: the everyday withdrawal key starts a process, giving Anna an opportunity to rescue the funds. Think of a safe with a waiting period and an emergency diversion. The comparison only holds where the network’s spending conditions actually enforce those restrictions. An app timer is not enough. Nor is a Hardware Wallet, a device protecting signing keys, automatically a vault; it addresses a different part of security. [1] [6]

A transaction output records an amount and the conditions for spending it later. Bitcoin records spendable transaction outputs, called UTXOs. A block groups transactions into a batch added to the shared history. In a simple model, the initial transaction spends the stored output and creates a new one with a waiting condition. That initial step is called unvault. The final payment can follow later, while a recovery branch allows an earlier intervention. Suppose the intermediate output confirms in block H with a delay of 144 blocks: the normal path can become usable no earlier than H+144, provided its other conditions are met. This is not exactly 24 hours, because blocks do not arrive on a timetable. Nor does it reverse a completed payment: the recovery transaction must confirm before the final spend. [1] [5] [7]

Anna spots a withdrawal she did not request. She now needs working network monitoring, a valid recovery transaction and a way to pay its fee. A Mempool holds unconfirmed transactions; acceptance there is not enough. Congestion or pinning, an attacker making a transaction harder to replace or confirm, can delay the response. The specific Revault design provides for CPFP: a child transaction adds a fee to encourage miners to confirm both together. Some recovery transactions use ALL | ANYONECANPAY, a signature mode allowing additional inputs, references to other unspent amounts used to fund the fee. These are tools for a particular design, not a promise of timely confirmation. Historical rates in the specification are not current fee recommendations. [1] [4]

An emergency transfer may stop the thief yet leave Anna with another problem: the destination wallet must remain usable. Knowing its address is insufficient. She needs the required keys, a description of its conditions and any previously prepared transactions. Permission to trigger a protective transfer is also different from permission to spend from its destination. A monitor can have the former without receiving the latter. However, an overly accessible recovery path may let someone repeatedly frustrate legitimate withdrawals. A sound design therefore considers access recovery and abuse of the protection itself, as well as theft. [1] [4]

Some vaults use today’s rules and presigned transactions. Necessary signatures are produced during setup; security may then rely on deleting one-time keys or on independent cosigners refusing other paths. The network cannot verify that someone really deleted every key copy. A hidden copy may bypass the intended protection. Backups may also need more than a Seed Phrase, the words used to derive wallet keys. Those words may not recreate a missing signature from a deleted one-time key. Presigned transactions and their supporting data can therefore be essential recovery material. [1] [4]

Revault shows why asking who has a key is only the beginning. Stakeholders hold the main authority; managers handle routine withdrawals and cosigning servers approve them alongside the managers. Deposits require N-of-N, meaning all designated stakeholder signatures: this is Multisig, joint approval using several keys. The intermediate output can be spent through the stakeholder path or through managers and servers after X blocks. Cancel returns it to the original deposit conditions; an emergency transfer goes to an Emergency Deep Vault. Stakeholders also have a direct bypass path. Someone obtaining all their keys need not wait. This arrangement describes one specification, not every vault. [4]

A BIP documents a Bitcoin proposal or standard; its number does not imply activation. Checked on 17 October 2026, BIP 345 is Closed and names BIP 443 in Proposed-Replacement. The original proposal combined OP_VAULT and OP_VAULT_RECOVER with OP_CHECKTEMPLATEVERIFY, instructions restricting withdrawal paths. BIP 443 proposes the more general OP_CHECKCONTRACTVERIFY, or OP_CCV, and remains Draft; its activation mechanism is undetermined. BIP 119 for OP_CHECKTEMPLATEVERIFY is also Draft. These belong to the broader discussion of Covenants, restrictions on an output’s subsequent use. Published code or a demonstration does not prove that mainnet, Bitcoin’s main network, enforces the protection. [1] [2] [3]

Before Anna entrusts savings to a vault, she needs to understand normal withdrawals, recovery and every bypass path. A practical rehearsal belongs in a separate test environment: a normal withdrawal, an attempt before the delay expires, an unexpected unvault, a monitor outage and unavailable fee funds. Distinguish a valid signature, mempool acceptance and confirmation in a block. One successful demonstration does not test the other branches. For a beginner, the key point is that a vault adds response time but also duties that someone must reliably perform. This explanation is not an instruction to fund an experimental script with real money. [1] [4]