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 출력은 N-of-N stakeholder 키를 사용하며, unvault 출력은 stakeholder 경로 또는 X블록 이후 managers와 cosigners 경로를 허용한다. Cancel은 출력을 deposit 정책으로 돌리고 emergency는 Emergency Deep Vault로 보낸다. stakeholders가 서명하는 bypass도 있다. 따라서 모든 stakeholder 키가 침해되면 이 모델은 지연을 보장하지 않으며 모든 vault를 설명하는 것도 아니다. [Revault — Transaction specification]

2026년 9월 8일 검토 시 BIP 345는 Closed이며 Proposed-Replacement로 BIP 443을 가리킨다. 원래 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]