Supongamos que la clave de emergencia cae en manos equivocadas: ¿cuál es el peor resultado, que BTC se desvíe a un destinatario incorrecto, o que quede bloqueado un pago normal? Al hacer modelado de amenazas para Trustless Bitcoin Vaults (TBV), el resultado se puede redactar en una nota de desestimación manual de tres casillas.
La casilla de pérdida de activos primero mira el script de cobro. El destino del Vault existente queda determinado en el momento de la creación: solo incluye la dirección del Depositor o la dirección del liquidation arbitrageur; la clave del Security Council no forma parte del conjunto de destinatarios. Controlar Council no puede, por arte de magia, agregar un nuevo destinatario de cobro, ni tampoco puede reemplazar la dirección original por la dirección de un atacante.
La casilla de interrupción del servicio, en cambio, no puede llenarse con “no”. Council tiene la capacidad de impedir el payout, así que si hay un problema con la clave de emergencia, habrá un impacto real de liveness: que las monedas no las reclame no significa que el usuario pueda completar la salida tal como estaba planeada. Este tipo de daño debe tratarse como un evento de disponibilidad, no como algo que pueda ocultarse porque los activos no se han re-ubicado.
La casilla de exposición de condiciones también debe listar las demás dependencias. TBV reduce el riesgo de custodios y de puentes, pero aun así utiliza contratos en Ethereum, oráculos, ZK/BABE y una tubería de pruebas entre cadenas; además, existen requisitos de gobernanza y de disponibilidad para los operadores. No todo eso pertenece a Council, pero aun así afecta “si es posible completar la operación según las condiciones”.
Por lo tanto, el orden temporal es: comprobar el conjunto de destinatarios al crear; si ocurre una anomalía, determinar si el payout queda bloqueado; al continuar con la disposición, verificar las pruebas, los contratos y las condiciones operativas. Las tres casillas corresponden a tres consecuencias distintas y no deberían fusionarse en una frase como “como hay multisig, entonces es custodia”.
Esta nota, al final, solo ofrece conclusiones limitadas: el poder de emergencia puede causar una interrupción del servicio, pero no permite inferir un derecho a retirar cambiando direcciones; la dirección de los activos está restringida, pero tampoco permite afirmar que el sistema esté totalmente libre del impacto de la gobernanza. Separar el peor resultado por tipo es lo que permite saber qué se intenta prevenir: el robo o el bloqueo.
@BabylonLabs_io $BABY #baby
La casilla de pérdida de activos primero mira el script de cobro. El destino del Vault existente queda determinado en el momento de la creación: solo incluye la dirección del Depositor o la dirección del liquidation arbitrageur; la clave del Security Council no forma parte del conjunto de destinatarios. Controlar Council no puede, por arte de magia, agregar un nuevo destinatario de cobro, ni tampoco puede reemplazar la dirección original por la dirección de un atacante.
La casilla de interrupción del servicio, en cambio, no puede llenarse con “no”. Council tiene la capacidad de impedir el payout, así que si hay un problema con la clave de emergencia, habrá un impacto real de liveness: que las monedas no las reclame no significa que el usuario pueda completar la salida tal como estaba planeada. Este tipo de daño debe tratarse como un evento de disponibilidad, no como algo que pueda ocultarse porque los activos no se han re-ubicado.
La casilla de exposición de condiciones también debe listar las demás dependencias. TBV reduce el riesgo de custodios y de puentes, pero aun así utiliza contratos en Ethereum, oráculos, ZK/BABE y una tubería de pruebas entre cadenas; además, existen requisitos de gobernanza y de disponibilidad para los operadores. No todo eso pertenece a Council, pero aun así afecta “si es posible completar la operación según las condiciones”.
Por lo tanto, el orden temporal es: comprobar el conjunto de destinatarios al crear; si ocurre una anomalía, determinar si el payout queda bloqueado; al continuar con la disposición, verificar las pruebas, los contratos y las condiciones operativas. Las tres casillas corresponden a tres consecuencias distintas y no deberían fusionarse en una frase como “como hay multisig, entonces es custodia”.
Esta nota, al final, solo ofrece conclusiones limitadas: el poder de emergencia puede causar una interrupción del servicio, pero no permite inferir un derecho a retirar cambiando direcciones; la dirección de los activos está restringida, pero tampoco permite afirmar que el sistema esté totalmente libre del impacto de la gobernanza. Separar el peor resultado por tipo es lo que permite saber qué se intenta prevenir: el robo o el bloqueo.
@BabylonLabs_io $BABY #baby