-
Con los vaults, las firmas pasarían a abrir una espera que el dueño puede contradecir.
-
Operar un vault no es un botón en la aplicación, exige conocimiento técnico y vigilancia constante.
Vaciar una cuenta de Bitcoin no exige romper la criptografía del protocolo, alcanza con obtener o reproducir la clave por otro camino.
El phishing de frases semillas, la coacción física para forzar su entrega, el software malicioso capaz de firmar en nombre de la víctima y fallas de fabricación como la reportada en dispositivos Coldcard son caminos distintos hacia el mismo resultado, una clave que dejó de ser secreta.
En Bitcoin, gastar significa satisfacer el script, el programa que define bajo qué condiciones pueden moverse los UTXO de Bitcoin (salida de transacciones no gastadas). En la práctica, esto casi siempre equivale a tener la clave correcta, y no hay forma de deshacer un envío ya confirmado.
Los vaults (bóvedas), ¿una alternativa para mayor seguridad en Bitcoin?
Un vault, o bóveda en castellano, es un tipo de construcción que obliga a que cualquier intento de retiro pase primero por un estado intermedio con demora, es un posible obstáculo para que tener la clave equivalga a poder gastar los fondos de inmediato y sin posibilidad de deshacer el envío.
Durante esa demora, el dueño, o una vía de recuperación separada, puede redirigir los fondos a un destino seguro antes de que el retiro se complete.
Es decir, la clave seguiría siendo necesaria para mover el dinero, pero dejaría de ser suficiente para moverlo de inmediato y hacia cualquier destino.
Un informe del MIT Digital Currency Initiative, elaborado por la investigadora Lillian Wang y publicado el 4 de septiembre en el foro técnico Delving Bitcoin, compara seis maneras de construir estos vaults.
Todas dependen de un mismo mecanismo, el covenant, una restricción en el script, las condiciones que determinan cómo puede gastarse un UTXO, la unidad de fondos no gastados que Bitcoin usa para registrar cuánto BTC controla cada dirección, que va más allá de exigir solo una firma válida.
El informe ordena las seis propuestas de la más rígida a la más flexible.
- Transacciones presignadas: Firmadas y guardadas de antemano, permiten un vault sin cambios en el protocolo, pero exigen borrar la clave usada para firmar.
- OP_CHECKTEMPLATEVERIFY (BIP-119): Fija de antemano, en el script, la transacción que podrá gastar el UTXO.
- SIGHASH_ANYPREVOUTANYSCRIPT (BIP-118): Compromete las salidas sin atarse a un UTXO de entrada específico, lo que le permite residir en el propio script de bloqueo.
- OP_CHECKCONTRACTVERIFY (BIP-443): Reparte el monto de un UTXO entre varias salidas según reglas fijas, lo que habilita el retiro parcial.
- OP_TXHASH (BIP-346): Deja elegir qué partes de la transacción quedan comprometidas en el script, con más margen para comisiones y retiros parciales.
- OP_CAT (Purrfect Vault): Concatena datos dentro del script para construcciones a medida, el control más granular de las seis opciones.
De las seis, solo las transacciones presignadas funcionan bajo las reglas de consenso actuales de Bitcoin. Las otras cinco requieren cambios de consenso aún no activados. Ninguna está disponible para un usuario común en un monedero convencional.
Un vault no es un botón en la aplicación
Construir y operar un vault hoy no es una función que se activa con un interruptor en aplicaciones como Sparrow, Electrum o BlueWallet. Exige definir una política de gasto avanzada, una vía de recuperación distinta de la clave de uso diario, en el diseño más habitual, y alguien que vigile esos fondos.
Esa vigilancia no se concentra en una ventana fija, un vault puede permanecer intacto durante años sin que pase nada. El riesgo aparece cuando alguien, el dueño o un atacante, publica la transacción que inicia el retiro. Recién ahí el timelock abre una demora breve para reaccionar, no una cuenta regresiva permanente.
Delegar esa vigilancia en un watchtower traslada la tarea, no la elimina. Si ese servicio solo observa y avisa, sin poder mover fondos, su falla más probable no es un robo sino un silencio, dejar de avisar a tiempo. El riesgo de robo adicional solo aparece si además se le da poder de gasto.
Ese diseño de dos claves es el más habitual y el más fácil de explicar, pero no el único. Otras construcciones fijan el destino de recuperación directamente en el script, sin clave adicional, y eso permite que cualquiera, incluso un atacante, active esa vía sin poder robar, aunque sí adelante un retiro no deseado.
Nada de esto vuelve inútil a un vault. Es una manera concreta de aprovechar capacidades ya presentes en el protocolo, con beneficios reales, pero exige un aprendizaje que no toda persona tiene ni está dispuesta a adquirir. Ese esfuerzo es parte del costo de usarlo.
¿Qué resuelve un vault, y qué no?
Un vault protege un escenario preciso, que la clave usada para autorizar un retiro haya sido comprometida mientras otra vía, una clave de recuperación distinta o un observador atento, sigue intacta.
Ese escenario cubre buena parte de los ataques recientes contra usuarios de Bitcoin: el phishing de semillas, la coacción física para forzar la entrega de una clave y el software malicioso capaz de firmar transacciones en nombre de la víctima.
El límite aparece en fallas como la de Coldcard, donde una entropía defectuosa en la generación de claves permitió reconstruir semillas y sustraer casi 1.800 BTC de más de 8.600 direcciones, según confirmó la firma Galaxy.
Si esa misma falla generó también la clave de recuperación del vault, no queda ninguna vía intacta desde la cual reaccionar, y el atacante puede operar el vault entero como si fuera el dueño legítimo.
Un vault tampoco resuelve la coacción sostenida en el tiempo ni el abandono del monitoreo. Si la clave de recuperación cae junto con la de gasto, o si nadie vigila la cadena en el momento en que se publica un retiro, esa demora deja de proteger al dueño y pasa a jugar a favor del atacante.
De acto final a acto inicial
En Bitcoin, tener la clave y poder vaciar el saldo son el mismo acto. Una firma válida no es un pedido, es directamente el gasto. El protocolo no pregunta si esa firma coincide con la voluntad de quien la produjo, solo verifica si la matemática cierra.
El vault parte de otra premisa, que esa equivalencia ya no es un buen modelo de seguridad. Una clave puede estar comprometida por malware, coacción, una fuga o un dispositivo con entropía defectuosa, y la firma que produzca seguirá siendo válida. Si el protocolo trata esa validez como decisión soberana, el dueño no tiene un segundo movimiento posible.
Por eso el vault no busca interpretar mejor una firma, la degrada de acto final a acto inicial. Firmar con la clave de uso diario ya no cierra el envío, abre una espera, durante la cual el dueño, o una vía de recuperación más resguardada, puede enviar los fondos a un destino ya definido.
Este cambio admite algo que la idea de que quien tiene la clave tiene los fondos preferiría no decir, que la clave dejó de ser un indicador confiable de la voluntad de su dueño.
Puede ser la clave correcta y, aun así, no reflejar la decisión correcta. Un protocolo con vaults deja de tratar la firma como prueba suficiente de control y empieza a tratarla como un acto que todavía puede impugnarse.
La conclusión que dejan estas seis propuestas es acotada pero contundente. Bitcoin discute dejar de confundir la autorización criptográfica con el control efectivo sobre los fondos. Tener la clave seguiría siendo necesario para moverlos, dejaría de ser suficiente para moverlos de inmediato, hacia cualquier destino, sin que su dueño pueda intervenir.
