Bitcoin Vault

Anna guarda parte de sus ahorros en bitcoin. Una cartera es una aplicación o un dispositivo para recibir y enviar bitcoin. Firmar significa aquí usar una clave privada, un valor numérico secreto, para crear una prueba verificable de autorización del pago. Los demás pueden comprobar la firma sin conocer ese secreto. En una cartera corriente controlada por una sola clave, quien la robe puede firmar un pago directamente a su propia dirección. Bitcoin Vault pretende cambiar ese momento: la clave de uso habitual inicia un proceso y Anna dispone de una oportunidad para rescatar los fondos. Se parece a una caja fuerte con demora y salida de emergencia. Pero la comparación solo sirve si las condiciones de gasto de la red imponen realmente esas restricciones. Un temporizador en una aplicación no basta. Tampoco una Hardware Wallet, un dispositivo que protege las claves de firma, es por sí sola un vault: resuelve otra parte de la seguridad. [1] [6]

Una salida de transacción registra una cantidad y las condiciones para gastarla después. Bitcoin registra salidas de transacciones que pueden gastarse, llamadas UTXO. Un bloque agrupa transacciones en un lote que se añade al historial compartido. En un modelo sencillo, la transacción inicial gasta la salida guardada y crea otra con una condición de espera. Ese paso se llama unvault. El pago final podrá realizarse más tarde, mientras una vía de recuperación permite intervenir antes. Si la salida intermedia se confirma en el bloque H con una demora de 144 bloques, la vía normal podrá utilizarse como pronto en H+144, siempre que cumpla las demás condiciones. No son exactamente 24 horas: los bloques no llegan con un horario fijo. Tampoco se revierte un pago terminado; la transacción de rescate debe confirmarse antes del gasto final. [1] [5] [7]

Anna detecta una retirada que no ha solicitado. Necesita vigilancia operativa de la red, una transacción de rescate válida y fondos para su comisión. El Mempool contiene transacciones sin confirmar; que una transacción entre en él no basta. La congestión o el pinning, con el que un atacante dificulta sustituir o confirmar una transacción, pueden retrasar la respuesta. Revault contempla CPFP: una transacción descendiente añade comisión para incentivar que los mineros confirmen ambas juntas. Algunos rescates emplean ALL | ANYONECANPAY, un modo de firma que permite incorporar entradas adicionales, referencias a otros importes no gastados con los que pagar las comisiones. Son herramientas de un diseño concreto, no garantías de confirmación a tiempo. Las tarifas históricas de la especificación no son recomendaciones actuales. [1] [4]

El traslado de emergencia puede frenar al ladrón y aun así dejar a Anna otro problema: la cartera de destino debe seguir siendo utilizable. Conocer su dirección no basta. Hacen falta las claves exigidas, la descripción de las condiciones y las transacciones preparadas que correspondan. Poder activar un traslado protector no equivale a poder gastar desde su destino. Un vigilante puede tener el primer permiso sin recibir el segundo. Sin embargo, una vía de rescate demasiado accesible puede permitir que alguien frustre repetidamente retiradas legítimas. Un diseño sólido considera tanto la recuperación del acceso como el abuso de la protección, además del robo. [1] [4]

Algunos vaults utilizan las reglas actuales y transacciones firmadas por adelantado. Las firmas se generan durante la preparación; después, la seguridad puede depender de eliminar claves de un solo uso o de cofirmantes independientes que rechacen otras vías. La red no puede verificar que alguien haya borrado todas las copias de una clave. Una copia oculta puede eludir la protección. La copia de seguridad también puede necesitar más que una Seed Phrase, las palabras que permiten derivar las claves de la cartera. Esas palabras quizá no reconstruyan una firma perdida de una clave de un solo uso ya eliminada. Las transacciones prefirmadas y sus datos pueden ser indispensables para recuperar el acceso. [1] [4]

En Revault, preguntar quién tiene una clave es solo el principio. Los stakeholders poseen la autoridad principal; los managers gestionan las retiradas habituales y los cosigning servers las cofirman. El depósito exige N-of-N: todas las firmas de los stakeholders designados. Es Multisig, aprobación conjunta mediante varias claves. La salida intermedia puede gastarse por la vía de los stakeholders o, tras X bloques, por la de managers y servidores. Cancel la devuelve a las condiciones originales del depósito; una transferencia de emergencia va a Emergency Deep Vault. Los stakeholders también disponen de una vía directa, bypass. Quien consiga todas sus claves no necesita esperar. Esto describe una especificación concreta, no todos los vaults. [4]

Un BIP documenta una propuesta o estándar de Bitcoin; su número no implica activación. En la comprobación del 17 de octubre de 2026, BIP 345 figura como Closed y remite a BIP 443 en Proposed-Replacement. Combinaba OP_VAULT y OP_VAULT_RECOVER con OP_CHECKTEMPLATEVERIFY, instrucciones que restringen las vías de retirada. BIP 443 propone OP_CHECKCONTRACTVERIFY, abreviado OP_CCV, más general, y sigue en Draft; su mecanismo de activación no está decidido. BIP 119, sobre OP_CHECKTEMPLATEVERIFY, también está en Draft. Forman parte del debate sobre Covenants, restricciones al uso posterior de una salida. Publicar código o una demostración no prueba que mainnet, la red principal de Bitcoin, imponga esa protección. [1] [2] [3]

Antes de confiar sus ahorros a un vault, Anna debe entender la retirada normal, el rescate y cada vía bypass. Las pruebas corresponden a un entorno separado: retirada normal, intento antes de vencer el plazo, unvault inesperado, caída del vigilante y falta de fondos para comisiones. Hay que distinguir una firma válida, la aceptación en el mempool y la confirmación en un bloque. Una demostración exitosa no prueba las demás vías. Para quien empieza, lo esencial es que un vault da tiempo para reaccionar, pero añade tareas que alguien debe cumplir de forma fiable. Este texto no invita a depositar dinero real en un script experimental. [1] [4]