Un conjunto de Vault, si solo consideramos que los usuarios pueden conectarse y firmar en cualquier momento, asume un supuesto poco realista: que los tenedores de activos nunca se desconectarán.
Quienes mantienen BTC a largo plazo podrían cambiar de dispositivo, perder claves o, debido a una situación repentina, no poder gestionar los activos de manera temporal. En ese caso, el sistema no puede ceder el control con facilidad a un tercero, ni puede dejar el BTC detenido para siempre en un estado en el que nadie pueda operarlo.
Por eso, mientras exploro TBV en @BabylonLabs_io , también pienso cómo debe diseñarse el mecanismo de recuperación. ¿Puede el usuario especificar condiciones de respaldo con antelación? ¿El proceso de recuperación necesita un periodo de espera suficientemente largo? Cuando el tenedor original reaparece, ¿todavía existe la posibilidad de impedir una ejecución no prevista? Estas reglas deben quedar definidas antes de que el activo entre en el Vault, en lugar de decidirse improvisadamente después de que ocurra el problema.
Para el ecosistema de #baby , la capacidad de recuperación es igual de importante que el uso diario. Una ruta de recuperación demasiado laxa debilitaría la autocustodia; pero si no existe ninguna ruta de recuperación, una simple contingencia podría convertirse en una pérdida permanente.
La dirección más razonable es permitir que el usuario defina sus límites de seguridad de antemano: quién puede solicitar la recuperación, qué pruebas deben cumplirse y cuánto tiempo después de eso surtiría efecto.
A medida que las aplicaciones relacionadas con $BABY van asumiendo gradualmente la custodia de activos a largo plazo, el sistema no solo debe responder “quién puede controlar el BTC ahora”, sino también “cómo se puede continuar de forma segura el control cuando el tenedor original no puede operar”.
Quienes mantienen BTC a largo plazo podrían cambiar de dispositivo, perder claves o, debido a una situación repentina, no poder gestionar los activos de manera temporal. En ese caso, el sistema no puede ceder el control con facilidad a un tercero, ni puede dejar el BTC detenido para siempre en un estado en el que nadie pueda operarlo.
Por eso, mientras exploro TBV en @BabylonLabs_io , también pienso cómo debe diseñarse el mecanismo de recuperación. ¿Puede el usuario especificar condiciones de respaldo con antelación? ¿El proceso de recuperación necesita un periodo de espera suficientemente largo? Cuando el tenedor original reaparece, ¿todavía existe la posibilidad de impedir una ejecución no prevista? Estas reglas deben quedar definidas antes de que el activo entre en el Vault, en lugar de decidirse improvisadamente después de que ocurra el problema.
Para el ecosistema de #baby , la capacidad de recuperación es igual de importante que el uso diario. Una ruta de recuperación demasiado laxa debilitaría la autocustodia; pero si no existe ninguna ruta de recuperación, una simple contingencia podría convertirse en una pérdida permanente.
La dirección más razonable es permitir que el usuario defina sus límites de seguridad de antemano: quién puede solicitar la recuperación, qué pruebas deben cumplirse y cuánto tiempo después de eso surtiría efecto.
A medida que las aplicaciones relacionadas con $BABY van asumiendo gradualmente la custodia de activos a largo plazo, el sistema no solo debe responder “quién puede controlar el BTC ahora”, sino también “cómo se puede continuar de forma segura el control cuando el tenedor original no puede operar”.