Bitcoin Vault — це схема зберігання, у якій звичайне виведення проходить етап очікування. Тим часом кошти можна спрямувати за наперед визначеним шляхом порятунку. Мета — дати власникові час відреагувати на викрадення ключа. Схеми різняться; сама назва vault у застосунку такого захисту не гарантує.
Анна тримає частину заощаджень у біткоїні. Гаманець — це застосунок або пристрій для отримання й надсилання біткоїнів. Підписати тут означає за допомогою приватного ключа, секретного числового значення, створити перевірний доказ дозволу на платіж. Інші можуть перевірити підпис, не знаючи цього секрету. У звичайному гаманці з єдиним ключем злодій, який його отримав, може одразу підписати платіж на власну адресу. Bitcoin Vault має змінити цей момент: ключ для повсякденного виведення лише запускає процес, а Анна дістає нагоду врятувати кошти. Це нагадує сейф із затримкою та аварійним перенаправленням. Але порівняння доречне лише там, де обмеження справді забезпечують умови витрачання в мережі. Таймера в застосунку недостатньо. Hardware Wallet, пристрій для захисту ключів підпису, теж не є vault автоматично: він розв’язує інше завдання безпеки. [1] [6]
Вихід транзакції — це запис суми й умов, за яких її згодом можна витратити. Bitcoin обліковує виходи транзакцій, доступні для витрачання, — UTXO. Блок об’єднує транзакції в пакет, який додають до спільної історії. У простій моделі початкова транзакція витрачає збережений вихід і створює новий з умовою очікування. Цей крок називається unvault. Остаточний платіж можливий пізніше, а шлях порятунку дозволяє втрутитися раніше. Припустімо, проміжний вихід підтверджено в блоці H із затримкою 144 блоки: звичайний шлях може стати доступним не раніше H+144, якщо виконано й решту умов. Це не рівно 24 години, адже блоки не з’являються за розкладом. І це не скасування завершеного платежу: рятувальна транзакція має отримати підтвердження до остаточного витрачання. [1] [5] [7]
Анна помічає виведення, якого не замовляла. Тепер потрібні справне спостереження за мережею, дійсна рятувальна транзакція та кошти на її комісію. Mempool містить непідтверджені транзакції; потрапляння туди недостатньо. Перевантаження або pinning, коли нападник ускладнює заміну чи підтвердження транзакції, можуть затримати реакцію. Revault передбачає CPFP: наступна транзакція додає комісію, заохочуючи майнерів підтвердити обидві разом. Деякі рятувальні транзакції застосовують ALL | ANYONECANPAY — режим підпису, що дозволяє додати входи для оплати комісії, тобто посилання на інші невитрачені суми. Це засоби конкретної схеми, а не гарантія своєчасного підтвердження. Історичні ставки зі специфікації не є сучасною рекомендацією. [1] [4]
Захисний переказ може зупинити злодія й водночас залишити Анні іншу проблему: гаманець призначення має бути придатним до подальшого використання. Знати адресу недостатньо. Потрібні необхідні ключі, опис умов і, за потреби, заготовлені транзакції. Право запустити захисний переказ відрізняється від права витрачати з його кінцевого гаманця. Спостерігач може мати перше без другого. Проте надто доступний шлях порятунку може дозволити комусь раз у раз зривати законні виведення. Тому продумана схема враховує не лише крадіжку, а й відновлення доступу та зловживання самим захистом. [1] [4]
Деякі vault використовують чинні правила й наперед підписані транзакції. Підписи створюють під час налаштування; далі безпека може залежати від видалення одноразових ключів або від незалежних співпідписантів, які відмовлять в інших шляхах. Мережа не здатна перевірити, чи справді видалено всі копії ключа. Прихована копія може обійти захист. Резервна копія також може вимагати більшого, ніж Seed Phrase — слова, з яких обчислюються ключі гаманця. Вони не обов’язково відтворять втрачений підпис уже видаленого одноразового ключа. Отже, наперед підписані транзакції та їхні дані можуть бути необхідними для відновлення. [1] [4]
У Revault питання про власника ключа — лише початок. Stakeholders мають головні повноваження; managers керують звичайними виведеннями, а cosigning servers підписують їх разом із ними. Депозит вимагає N-of-N, тобто всіх визначених підписів stakeholders: це Multisig, спільне схвалення кількома ключами. Проміжний вихід можна витратити шляхом stakeholders або після X блоків шляхом managers разом із серверами. Cancel повертає його до початкових умов депозиту; аварійний переказ веде до Emergency Deep Vault. Stakeholders також мають прямий шлях bypass. Той, хто отримає всі їхні ключі, може не чекати. Це конкретна специфікація, а не опис усіх vault. [4]
BIP описує пропозицію або стандарт Bitcoin; номер не означає активації. Станом на перевірку 17 жовтня 2026 року BIP 345 має статус Closed і вказує BIP 443 у Proposed-Replacement. Початковий проєкт поєднував OP_VAULT і OP_VAULT_RECOVER з OP_CHECKTEMPLATEVERIFY — інструкціями, що обмежують шляхи виведення. BIP 443 пропонує загальніший OP_CHECKCONTRACTVERIFY, або OP_CCV, і залишається Draft; механізму активації не визначено. BIP 119 для OP_CHECKTEMPLATEVERIFY теж має статус Draft. Це частина дискусії про Covenants — обмеження подальшого використання виходу. Опублікований код чи демонстрація не доводять, що mainnet, основна мережа Bitcoin, забезпечує цей захист. [1] [2] [3]
Перш ніж довірити vault заощадження, Анні слід зрозуміти звичайне виведення, порятунок і кожен шлях bypass. Практичні перевірки проводять в окремому тестовому середовищі: нормальне виведення, передчасна спроба, несподіваний unvault, збій спостерігача та відсутність коштів на комісію. Дійсний підпис, прийняття до mempool і підтвердження в блоці — різні речі. Успішна демонстрація не перевіряє інші гілки. Для новачка головне: vault дає час, але додає обов’язки, які хтось має надійно виконувати. Цей текст не є інструкцією переказувати справжні кошти в експериментальний скрипт. [1] [4]
Для повної картини прочитайте також Covenants, OP_CHECKTEMPLATEVERIFY, Timelock, Multisig, Bitcoin Inheritance Plan, Самостійне зберігання. На цю статтю також посилаються Dead Man’s Switch.