Bitcoin Vault — конструкция хранения с отдельными этапами вывода. После запуска действует период, когда её правила позволяют перевести средства на безопасный путь восстановления. Это не название одного активированного опкода и не другое обозначение аппаратного кошелька.
В обычном кошельке с одной подписью вор с ключом может создать прямой платёж. Vault должен ограничить такой немедленный отток: рабочий ключ запускает процесс, но не должен сам обходить ожидание и восстановление. Нужно выяснить, какие комбинации ключей платят напрямую, а какие требуют промежуточного состояния. Название vault или отложенный перевод в приложении не доказывают принудительного исполнения на blockchain. [BIP 345 — OP_VAULT]
Модель различает внесённый UTXO, подтверждённый промежуточный unvault-выход и завершённый платёж. Если обычная ветвь промежуточного выхода, подтверждённого в блоке H, требует 144 блока, она доступна не раньше H+144 при выполнении остальных условий. Ветвь восстановления должна позволять вмешаться раньше. Это не ровно 24 часа и не автоматический возврат: действенное вмешательство должно опередить окончательное подтверждённое расходование. [BIP 345 — OP_VAULT] [BIP 112 — CHECKSEQUENCEVERIFY]
Некоторые конструкции используют действующие правила и заранее подписанные транзакции. Они ограничивают альтернативные расходы требованием безопасно удалить одноразовые ключи или получить разрешение других независимых сторон. Сеть сама не доказывает удаление ключа. Сохранённая секретная копия может обойти задуманный путь. Предварительно подписанные транзакции нужны и для восстановления: один seed может не воссоздать подписи уже удалённого ключа. [BIP 345 — OP_VAULT] [Revault — Transaction specification]
Спецификация Revault различает stakeholders, managers и cosigning servers. Её deposit-выход использует ключи stakeholders N-of-N; unvault допускает их путь либо путь managers и cosigners после X блоков. Cancel возвращает выход под deposit-политику, emergency направляет в Emergency Deep Vault. Также существует bypass с подписями stakeholders. Поэтому модель не гарантирует задержку при компрометации всех их ключей и не описывает любой vault. [Revault — Transaction specification]
По состоянию на ревизию 8 сентября 2026 BIP 345 имеет статус Closed и указывает BIP 443 как Proposed-Replacement. Изначально он сочетал OP_VAULT и OP_VAULT_RECOVER с OP_CHECKTEMPLATEVERIFY. BIP 443 предлагает более общий OP_CHECKCONTRACTVERIFY, или OP_CCV, и имеет статус Draft; механизм активации не определён. BIP 119 тоже Draft. Номер BIP, тестовая реализация или опубликованный пример vault сами не доказывают активацию этих правил в Bitcoin mainnet. [BIP 345 — OP_VAULT] [BIP 443 — OP_CHECKCONTRACTVERIFY] [BIP 119 — CHECKTEMPLATEVERIFY]
Монитор должен распознать неожиданный вывод, а не просто увидеть транзакцию. Реакция требует действительной спасательной транзакции, доступной сети и достаточных комиссий. Отправка в mempool не означает подтверждения; перегрузка, pinning или неподходящее повышение комиссии могут растратить окно. Revault определяет CPFP и для некоторых спасательных транзакций ALL | ANYONECANPAY, позволяя добавлять оплачивающие комиссию входы. Исторические ставки не рекомендуют сегодняшнюю комиссию. [BIP 345 — OP_VAULT] [Revault — Transaction specification]
Перенаправление в скрипт восстановления помогает, только если законный владелец позже выполнит его условия. Недоступные ключи, отсутствующая конфигурация или утраченные предварительные подписи могут заменить кражу постоянной потерей собственного доступа. Слишком легко запускаемая спасательная ветвь также позволяет мешать повторными отменами вывода. Разделяйте право запускать защитный перевод и право расходовать с его цели, проверяя обе роли. [BIP 345 — OP_VAULT] [Revault — Transaction specification]
Проверка должна перечислить все пути вывода и bypass, консенсусные допущения, необходимые резервные материалы и время реакции. Отдельная тестовая система должна охватить обычный вывод, преждевременную попытку, неожиданный unvault, отказ монитора и недоступность средств на комиссии. Результаты должны различать действительную подпись, принятие mempool и подтверждение. Успешная демонстрация одного сценария не доказывает безопасность всех ветвей; эти модели не предлагают вносить реальные средства в экспериментальный скрипт. [BIP 345 — OP_VAULT] [Revault — Transaction specification]
Для полной картины прочитайте эту статью вместе с Bitcoin covenants, OP_CHECKTEMPLATEVERIFY, Timelock, Multisig, Bitcoin Inheritance Plan, Самостоятельное хранение. На эту статью также ссылаются Bitcoin covenants, OP_CHECKTEMPLATEVERIFY, Dead Man’s Switch.