“Se puede recuperar el BTC uno mismo si falla la acumulación” suena como si, después de fallar, solo hubiera que pulsar para reembolsar. Yo ordené en una línea de tiempo los parámetros de timeout de la red de pruebas TBV de @BabylonLabs_io , y entonces descubrí que la solución trustless garantiza el recupero final, no el reenvío inmediato por el mismo camino.
En la red de pruebas actual, primero hay que esperar la confirmación de 12 bloques signet; un peg-in completo suele tardar aproximadamente 2 horas. Los participantes deben completar el ACK dentro de unas 24 horas; una vez validado el vault, el usuario debe enviar la activación dentro de unas 48 horas desde la creación. Si no se completa algún paso, el estado entra en Expired, pero la devolución del lado de Bitcoin también está limitada por un timelock de 3 días: solo cuando llega el tiempo se puede difundir el reembolso usando la clave privada del BTC.
Esto se parece a un check-in de hotel con autoservicio: si la máquina de la tarjeta falla, el depósito no se lo traga el personal de recepción, pero la caja fuerte tiene que esperar al bloqueo programado para poder abrirse. Que sea recuperable es una garantía de seguridad; aun así, esperar, vigilar el estado y volver a emitir transacciones sigue siendo un costo para el usuario.
Los costos de los dos escenarios de fallo también son distintos. Si la coordinación sin conexión no se completa en unas 24 horas, la comisión del peg-in se reembolsa automáticamente; si el sistema ya puso el vault en estado Verified, y solo el usuario olvidó activar dentro de la ventana de 48 horas, el BTC aún puede tomar la ruta de reembolso, pero esa tarifa de servicio no se reembolsa. Un fallo del protocolo y que el usuario se desaparezca no van en la misma factura.
Esta distinción tiene sentido: en el primer caso el servicio no se completa, y por eso se devuelve el costo; en el segundo, los participantes ya hicieron la firma y los preparativos, y el usuario no presionó el botón, así que no se puede exigir que todo el trabajo en segundo plano vuelva a cero. Pero si el frontend solo escribe “seguridad de los fondos” y no pone juntas las tres “balizas” de 24 horas, 48 horas y 3 días, la gente común puede interpretar fácilmente que “recuperable” significa que llega en segundos.
Así que al observar la experiencia TBV de #baby , me centraré en probar la ruta de fallo: si la notificación llega a tiempo, si la razón de Expired es clara y si la transacción de reembolso puede difundirse sin problemas. El relato de producto de $BABY ya está realmente maduro: no es que el flujo “salga perfecto” y sea muy bonito, sino que cuando se atora, el usuario aún sabe cuál es el siguiente paso.
$BLESS $CYS
En la red de pruebas actual, primero hay que esperar la confirmación de 12 bloques signet; un peg-in completo suele tardar aproximadamente 2 horas. Los participantes deben completar el ACK dentro de unas 24 horas; una vez validado el vault, el usuario debe enviar la activación dentro de unas 48 horas desde la creación. Si no se completa algún paso, el estado entra en Expired, pero la devolución del lado de Bitcoin también está limitada por un timelock de 3 días: solo cuando llega el tiempo se puede difundir el reembolso usando la clave privada del BTC.
Esto se parece a un check-in de hotel con autoservicio: si la máquina de la tarjeta falla, el depósito no se lo traga el personal de recepción, pero la caja fuerte tiene que esperar al bloqueo programado para poder abrirse. Que sea recuperable es una garantía de seguridad; aun así, esperar, vigilar el estado y volver a emitir transacciones sigue siendo un costo para el usuario.
Los costos de los dos escenarios de fallo también son distintos. Si la coordinación sin conexión no se completa en unas 24 horas, la comisión del peg-in se reembolsa automáticamente; si el sistema ya puso el vault en estado Verified, y solo el usuario olvidó activar dentro de la ventana de 48 horas, el BTC aún puede tomar la ruta de reembolso, pero esa tarifa de servicio no se reembolsa. Un fallo del protocolo y que el usuario se desaparezca no van en la misma factura.
Esta distinción tiene sentido: en el primer caso el servicio no se completa, y por eso se devuelve el costo; en el segundo, los participantes ya hicieron la firma y los preparativos, y el usuario no presionó el botón, así que no se puede exigir que todo el trabajo en segundo plano vuelva a cero. Pero si el frontend solo escribe “seguridad de los fondos” y no pone juntas las tres “balizas” de 24 horas, 48 horas y 3 días, la gente común puede interpretar fácilmente que “recuperable” significa que llega en segundos.
Así que al observar la experiencia TBV de #baby , me centraré en probar la ruta de fallo: si la notificación llega a tiempo, si la razón de Expired es clara y si la transacción de reembolso puede difundirse sin problemas. El relato de producto de $BABY ya está realmente maduro: no es que el flujo “salga perfecto” y sea muy bonito, sino que cuando se atora, el usuario aún sabe cuál es el siguiente paso.
$BLESS $CYS