-
El informe del MIT comparó seis diseños de covenants para vaults de Bitcoin.
-
Solo las transacciones presignadas funcionan sin cambios de consenso.
Taproot, Miniscript, MuSig2, los covenants y los descriptors multiplicaron en pocos años las formas en que un usuario de Bitcoin puede proteger sus fondos. Firmas más flexibles, gasto condicionado a reglas específicas, demoras programables y políticas de recuperación separadas de la clave de uso diario ya no son teoría de desarrollador, son opciones reales disponibles hoy o a un cambio de consenso de distancia. Cada una nació para cerrar una falla concreta de seguridad o privacidad. Ninguna nació para simplificar el sistema.
Ese es el punto que conviene sostener con cuidado, porque no es una crítica al diseño de esas herramientas, sino a una consecuencia que ninguna de ellas resuelve por sí sola. Cada mecanismo que cierra un riesgo abre una condición nueva que alguien, una wallet, un firmware, una persona frente a una pantalla, tiene que interpretar correctamente. Y una condición mal interpretada es, en la práctica, un riesgo tan real como el que se buscaba eliminar.
El ejemplo más reciente lo deja ver con claridad. Un informe del MIT Digital Currency Initiative comparó seis diseños de vaults, construcciones pensadas para que tener la clave ya no alcance para vaciar los fondos al instante, sino que abra una demora que el dueño puede contradecir. Las seis dependen de un covenant, una restricción en el script que va más allá de exigir solo una firma válida.
Pero el propio informe reconoce algo que la promesa de seguridad no menciona de entrada: operar un vault no es un botón en la aplicación. Exige definir una vía de recuperación distinta de la clave diaria, entender qué hace esa vía y, sobre todo, alguien que vigile la cadena durante años, porque el riesgo aparece justo en el momento en que se publica un intento de retiro.
La misma paradoja ya se documentó en Ethereum
Este problema de interpretación no es exclusivo de Bitcoin, y eso es lo que lo vuelve más difícil de descartar como un caso aislado. En Ethereum, una aprobación puede desencadenar múltiples acciones dentro de un contrato inteligente mientras el usuario solo ve, en su wallet, una descripción resumida de lo que en verdad está firmando.
Esa brecha entre lo que se firma y lo que se comprende no es hipotética. El robo de USD 1.500 millones a Bybit se ejecutó alterando precisamente la interfaz de firma, no rompiendo ninguna primitiva criptográfica. Trezor activó recientemente el estándar de firma clara en mayo de 2026, un intento de que la wallet muestre con exactitud qué autoriza cada operación.
La comparación entre ambas redes no es casual. Vitalik Buterin ha señalado en más de una ocasión que la ventaja estructural de Bitcoin frente a Ethereum es justamente su simplicidad: menos superficie de interpretación, menos piezas que puedan fallar en silencio sin que nadie lo note a tiempo.
Ahí está la tesis que sostiene esta nota. Las nuevas políticas de gasto empujan a Bitcoin hacia el mismo terreno donde Ethereum ya tropezó, no porque la criptografía de Bitcoin se debilite, sino porque la cantidad de condiciones que una wallet debe interpretar correctamente empieza a parecerse a la de un contrato inteligente complejo.
Lo que cada capa promete, y lo que en realidad traslada
La tabla resume el patrón que se repite en cada una de estas herramientas: resuelven un riesgo específico, pero no en el vacío, sino trasladando el trabajo de interpretación a otro punto del sistema.
| Mecanismo | Riesgo que reduce | Dónde traslada la complejidad |
|---|---|---|
| Taproot / Miniscript | Expone menos información de la política de gasto en cadena | La wallet debe construir y validar scripts más elaborados |
| MuSig2 | Reduce el tamaño y la exposición de firmas multisig | Los firmantes deben coordinar rondas de firma sin errores |
| Vaults / covenants | Evita que una clave comprometida vacíe los fondos al instante | Exige vigilancia constante y una vía de recuperación separada |
| Descriptors | Estandariza cómo se describe una política de gasto | El usuario debe confiar en que la wallet interpreta el descriptor sin ambigüedad |
Ninguna fila de esta tabla describe una herramienta defectuosa. Todas resuelven problemas documentados con incidentes reales detrás: robos de semillas, claves filtradas, fondos vaciados sin posibilidad de reacción. El límite no está en el mecanismo, está en asumir que resolver el riesgo criptográfico agota el problema de seguridad.
El costo que no aparece en la promesa de venta
Aquí conviene reconocer el contraargumento más fuerte a esta lectura: nada de esto obliga a nadie a usar estas herramientas. Un usuario que solo necesita una dirección y una clave puede seguir operando exactamente como en 2013, sin covenants ni políticas de recuperación.
Eso es cierto, y es una diferencia real frente a Ethereum, donde interactuar con la mayoría de las aplicaciones sí exige enfrentar contratos inteligentes cuya lógica el usuario promedio no puede auditar. La complejidad en Bitcoin es opcional, no impuesta por el protocolo a cada transacción.
Pero esa opcionalidad tiene un límite práctico. A medida que más wallets, custodios y servicios adoptan Taproot, vaults o esquemas MuSig2 como configuración por defecto para ofrecer mejor seguridad, la decisión de «mantenerlo simple» deja de ser una opción activa del usuario y pasa a depender de qué tan bien la industria explique lo que activó en su nombre.
Lo que esto revela sobre la seguridad real
La conclusión que se desprende de este contraste no es que Bitcoin deba dejar de evolucionar en materia de scripts y políticas de gasto. Es que la seguridad de un sistema no se mide solo por la solidez de su criptografía, sino por la distancia entre lo que esa criptografía permite y lo que la persona que la usa entiende que está autorizando.
Bitcoin no se vuelve menos seguro por incorporar Taproot, covenants o vaults. Se vuelve más difícil de operar sin margen de error, y ese margen de error humano o de interfaz ya es, hoy, un vector de ataque tan documentado como cualquier falla en el protocolo. Aunque vale aclarar que no es que Bitcoin se haga más inseguro, los vectores de ataque se añaden sobre capas superiores. La capa base sigue intacta.
La sofisticación no elimina el riesgo: lo reubica, de la matemática que Satoshi Nakamoto dejó cerrada hace más de una década a la persona y el software que hoy tienen que interpretarla por ella.
