Cuando veo el TBV en el libro blanco de @BabylonLabs_io , lo que se ignora con más facilidad no es la fórmula, sino una frase muy ligera: “Antes de crear el Vault, se necesita prefirmar un conjunto de transacciones de Bitcoin; tal vez también deban participar otras partes para firmar”.
Esa frase parece normal, pero cuanto más lo piensas, más clave se vuelve. La lógica del “bóveda” del TBV estaba pensada para que dos partes que no se confían puedan colaborar: la ruta de gasto se escribe con antelación, las transacciones prefirmadas fijan las reglas futuras y nadie puede modificar las condiciones de forma improvisada. Pero en cuanto aparecen “otras partes”, todo se vuelve menos sencillo.
Por ejemplo, en escenarios de préstamos, el liquidador podría tener que entrar en el proceso de firma; en escenarios de stablecoins, los grandes tenedores de fondos también podrían tener que participar con anticipación. Cuanto más firmantes haya, técnicamente solo es “una llave más”, pero en la práctica implica una gran cantidad de problemas de coordinación: ¿quién firma primero? ¿quién firma después? ¿qué pasa si alguien está desconectado? ¿el tiempo de espera cuenta como fallo o hay que reintentar? Estas no son “cuestiones de ataque” por parte de hackers, sino los puntos que más fácilmente se atascan en los procesos cotidianos.#baby
Por eso pienso que el reto del TBV no solo está en el Bitcoin Script, sino también en la coordinación entre participantes. Dos personas, apoyándose en reglas, aún pueden hacerlo funcionar con mucha fluidez; pero cuando participan más personas, el proceso de prefirmas deja de ser solo un problema criptográfico y se convierte en un problema organizativo.$BTC
$BABY Si además hay gobernanza, sí se puede estandarizar el orden de firma, la gestión de tiempos de espera, los reintentos ante excepciones y el rollback. Pero eso también introduce una contradicción sutil: cuanto más se intenta reducir la confianza humana, más necesario es escribir con claridad las reglas de cooperación; y cuanto más reglas hay, más altos se vuelven los costos de la gobernanza.$ETH
Esa frase parece normal, pero cuanto más lo piensas, más clave se vuelve. La lógica del “bóveda” del TBV estaba pensada para que dos partes que no se confían puedan colaborar: la ruta de gasto se escribe con antelación, las transacciones prefirmadas fijan las reglas futuras y nadie puede modificar las condiciones de forma improvisada. Pero en cuanto aparecen “otras partes”, todo se vuelve menos sencillo.
Por ejemplo, en escenarios de préstamos, el liquidador podría tener que entrar en el proceso de firma; en escenarios de stablecoins, los grandes tenedores de fondos también podrían tener que participar con anticipación. Cuanto más firmantes haya, técnicamente solo es “una llave más”, pero en la práctica implica una gran cantidad de problemas de coordinación: ¿quién firma primero? ¿quién firma después? ¿qué pasa si alguien está desconectado? ¿el tiempo de espera cuenta como fallo o hay que reintentar? Estas no son “cuestiones de ataque” por parte de hackers, sino los puntos que más fácilmente se atascan en los procesos cotidianos.#baby
Por eso pienso que el reto del TBV no solo está en el Bitcoin Script, sino también en la coordinación entre participantes. Dos personas, apoyándose en reglas, aún pueden hacerlo funcionar con mucha fluidez; pero cuando participan más personas, el proceso de prefirmas deja de ser solo un problema criptográfico y se convierte en un problema organizativo.$BTC
$BABY Si además hay gobernanza, sí se puede estandarizar el orden de firma, la gestión de tiempos de espera, los reintentos ante excepciones y el rollback. Pero eso también introduce una contradicción sutil: cuanto más se intenta reducir la confianza humana, más necesario es escribir con claridad las reglas de cooperación; y cuanto más reglas hay, más altos se vuelven los costos de la gobernanza.$ETH