Puede impedir Payout, pero no equivale a poder reescribir el destino de BTC
En los Trustless Bitcoin Vaults (TBV), el Security Council se puede malinterpretar fácilmente como un multisig que controla BTC. La red de pruebas pública actual usa 5 llaves públicas de Bitcoin y 3 de 5 como número mínimo legal; las llaves públicas se escriben en parámetros de protocolo fuera de la cadena versionados, para firmar conjuntamente CouncilNoPayout. Esto puede impedir el Payout de un Vault en particular, pero no puede redirigir los BTC a una nueva dirección especificada por el Council.
Las limitaciones provienen del diagrama de gastos de Bitcoin ya fijado en el momento de crear el Vault. Los depositantes prefirman el Payout y determinan el destino legal: una salida normal o un self-claim que regresa a la dirección del depositante bajo condiciones existentes no requieren aprobación del Council; la ruta de liquidación entra en la dirección ya autorizada del Application Vault Keeper. Las claves del Council no están incluidas en ese conjunto de destinatarios, por lo que incluso si se alcanza el quórum, solo existe el poder de bloqueo, pero no el de redirección de activos.
Esto es distinto de lo que el challenger difunde como No-Payout en un proceso de disputa normal: lo primero se basa en que un Claim inválido sea desafiado y no pueda ser refutado; CouncilNoPayout se usa para fallos extremos o recuperaciones especiales que el mecanismo estándar no puede gestionar. El pause de la parte de Ethereum es otra capa: puede pausar acciones de la aplicación, pero no puede reescribir rutas ya existentes como el Pre-PegIn refund y el WOTS self-claim.
CouncilNoPayout cambió mis criterios de evaluación: ya no solo pregunto si existe un comité dentro del sistema, sino qué resultados puede permitirle aceptar al Bitcoin. Puede impedir un gasto y aun así generar riesgos de disponibilidad y retraso de salida; si no puede crear nuevos destinos, entonces limita el peor desenlace al bloqueo, en lugar de la redirección de activos. Si las facultades del Council se abusan, los Payouts legítimos aún podrían quedar bloqueados; si el Council se desconecta, también se reduce la capacidad de recuperación de emergencia, así que no se puede escribir este diseño como de riesgo cero.
@BabylonLabs_io define el Security Council como una red de seguridad transitoria, con el objetivo de ir retirando gradualmente su poder conforme el protocolo madure. Lo que de verdad vale la pena observar no es si existe un multisig, sino en qué punto las facultades de emergencia quedan limitadas dentro de las rutas de gasto de Bitcoin.$BTC $ETH
$BABY
#baby
En los Trustless Bitcoin Vaults (TBV), el Security Council se puede malinterpretar fácilmente como un multisig que controla BTC. La red de pruebas pública actual usa 5 llaves públicas de Bitcoin y 3 de 5 como número mínimo legal; las llaves públicas se escriben en parámetros de protocolo fuera de la cadena versionados, para firmar conjuntamente CouncilNoPayout. Esto puede impedir el Payout de un Vault en particular, pero no puede redirigir los BTC a una nueva dirección especificada por el Council.
Las limitaciones provienen del diagrama de gastos de Bitcoin ya fijado en el momento de crear el Vault. Los depositantes prefirman el Payout y determinan el destino legal: una salida normal o un self-claim que regresa a la dirección del depositante bajo condiciones existentes no requieren aprobación del Council; la ruta de liquidación entra en la dirección ya autorizada del Application Vault Keeper. Las claves del Council no están incluidas en ese conjunto de destinatarios, por lo que incluso si se alcanza el quórum, solo existe el poder de bloqueo, pero no el de redirección de activos.
Esto es distinto de lo que el challenger difunde como No-Payout en un proceso de disputa normal: lo primero se basa en que un Claim inválido sea desafiado y no pueda ser refutado; CouncilNoPayout se usa para fallos extremos o recuperaciones especiales que el mecanismo estándar no puede gestionar. El pause de la parte de Ethereum es otra capa: puede pausar acciones de la aplicación, pero no puede reescribir rutas ya existentes como el Pre-PegIn refund y el WOTS self-claim.
CouncilNoPayout cambió mis criterios de evaluación: ya no solo pregunto si existe un comité dentro del sistema, sino qué resultados puede permitirle aceptar al Bitcoin. Puede impedir un gasto y aun así generar riesgos de disponibilidad y retraso de salida; si no puede crear nuevos destinos, entonces limita el peor desenlace al bloqueo, en lugar de la redirección de activos. Si las facultades del Council se abusan, los Payouts legítimos aún podrían quedar bloqueados; si el Council se desconecta, también se reduce la capacidad de recuperación de emergencia, así que no se puede escribir este diseño como de riesgo cero.
@BabylonLabs_io define el Security Council como una red de seguridad transitoria, con el objetivo de ir retirando gradualmente su poder conforme el protocolo madure. Lo que de verdad vale la pena observar no es si existe un multisig, sino en qué punto las facultades de emergencia quedan limitadas dentro de las rutas de gasto de Bitcoin.$BTC $ETH
$BABY
#baby