Esperaba que el paso de pre-firma durante la configuración de la bóveda cubriera los casos obvios: repago, liquidación, quizá redención. Lo que no esperaba era que el caso de fallo ya estuviera firmado también, antes de que se moviera siquiera un solo satoshi.

Configurando una bóveda para Trustless Bitcoin Vaults (TBV) desde @BabylonLabs_io , el BTC permanece temporalmente en una salida de Pre-PegIn mientras llegan las confirmaciones de Bitcoin. Durante esa ventana exacta, antes incluso de que la bóveda se haya activado, ya estás firmando la transacción de reembolso que te permite recuperar tu BTC si el peg-in nunca se completa. No es una promesa de construir una más adelante si algo se rompe. Es una ruta de gasto ya firmada que queda ahí, sin uso, esperando un escenario que en la mayoría de los casos nunca ocurre.

Eso me sorprendió más que las rutas de liquidación y redención, honestamente, porque esas parecían ser las partes de las que todo el mundo habla.

La ruta de reembolso es la que nadie menciona, y está firmada en el mismo momento que todo lo demás, bajo la misma lógica de pre-compromiso; nada se improvisa después, incluido el “salida” para cuando las cosas van mal antes incluso de que vayan bien.

Replantea lo que significa realmente la pre-firma aquí. No es solo fijar cómo se comporta una bóveda saludable. También es fijar cómo se comporta el fallo, en un punto en el que el fallo no ha ocurrido y quizá nunca ocurra.

Aún no tengo una respuesta clara sobre qué sucede si la configuración de firma propia de un depositante se descompone durante esa misma ventana, antes de que existan aún cualquiera de estas rutas pre-firmadas. La documentación cubre lo que pasa después de que se construye el grafo. Lo que pasa si algo falla antes de ese punto me queda menos claro.

#baby $BABY