Tengo un hábito bastante malo al probar protocolos: en cuanto veo true, mi cerebro lo marca automáticamente como “hecho”... y ese mismo reflejo una vez me hizo interpretar mal toda una State Machine.
Ese día, al ver ack_complete=true, casi ignoré vault_active=false.
Menos mal que me detuve.
El Pre-PegIn pasando 12 Confirmaciones de Bloque de Signet solo significa que el Conteo de Confirmaciones ha alcanzado la Condición de Disparo para que comience la Recolección de ACK, no que haya ocurrido la Activación del Vault.
Cambia una etiqueta de estado, y con ella cambian también los derechos de control.
Los Participantes que firman y completan la Configuración Colaborativa dentro de una Ventana de ACK de unas 24 horas hacen que ack_complete=true; pero la Autorización de Usuario aún no existe si el Usuario no ha realizado el Secret Reveal dentro de la Ventana de Activación de unas 48 horas.
24/48 = 50%.
En otras palabras, la Ventana de ACK ocupa solo aproximadamente la mitad del espacio de tiempo de la Ventana de Activación... y aun así antes yo trataba inconscientemente la Finalización de ACK como el Estado Final.
Sinceramente, aquí es donde encuentro que el diseño de @BabylonLabs_io es bastante intransigente.
El protocolo no le importa qué tan impacientes seamos.
Solo le importa que la Dependencia del Estado sea correcta.
Si no hay suficientes ACK antes de la Expiración, el Vault puede expirar y el Reembolso de la Comisión de Peg-in se convierte en una rama válida.
Si ya existen suficientes ACK, pero no ha ocurrido el Secret Reveal, seguir sospechando una Pérdida de Datos de ACK o hacer spam con reintentos de ACK solo nos manda en círculos.
Empecé a leer los logs en tres capas: Confirmación de Bloque primero, Configuración Colaborativa segundo, Activación de Usuario por último.
Sin saltarse pasos.
Sin interpretar el protocolo por nosotros.
Y a partir de ese punto, también noté algo bastante doloroso: Parámetros de Testnet como 12 bloques, ~24h o ~48h pueden ser Parámetros Mutables, pero lo más fiable en realidad es la Transición de Estado entre Pre-PegIn, Finalización de ACK, Estado Activo y Estado Final.
En tu opinión, ¿debería un buen Bitcoin Vault intentar que la experiencia se sienta “rápida”, o debería obligar a los usuarios a respetar cada capa de autoridad como esta?
#baby $BABY @BabylonLabs_io
Ese día, al ver ack_complete=true, casi ignoré vault_active=false.
Menos mal que me detuve.
El Pre-PegIn pasando 12 Confirmaciones de Bloque de Signet solo significa que el Conteo de Confirmaciones ha alcanzado la Condición de Disparo para que comience la Recolección de ACK, no que haya ocurrido la Activación del Vault.
Cambia una etiqueta de estado, y con ella cambian también los derechos de control.
Los Participantes que firman y completan la Configuración Colaborativa dentro de una Ventana de ACK de unas 24 horas hacen que ack_complete=true; pero la Autorización de Usuario aún no existe si el Usuario no ha realizado el Secret Reveal dentro de la Ventana de Activación de unas 48 horas.
24/48 = 50%.
En otras palabras, la Ventana de ACK ocupa solo aproximadamente la mitad del espacio de tiempo de la Ventana de Activación... y aun así antes yo trataba inconscientemente la Finalización de ACK como el Estado Final.
Sinceramente, aquí es donde encuentro que el diseño de @BabylonLabs_io es bastante intransigente.
El protocolo no le importa qué tan impacientes seamos.
Solo le importa que la Dependencia del Estado sea correcta.
Si no hay suficientes ACK antes de la Expiración, el Vault puede expirar y el Reembolso de la Comisión de Peg-in se convierte en una rama válida.
Si ya existen suficientes ACK, pero no ha ocurrido el Secret Reveal, seguir sospechando una Pérdida de Datos de ACK o hacer spam con reintentos de ACK solo nos manda en círculos.
Empecé a leer los logs en tres capas: Confirmación de Bloque primero, Configuración Colaborativa segundo, Activación de Usuario por último.
Sin saltarse pasos.
Sin interpretar el protocolo por nosotros.
Y a partir de ese punto, también noté algo bastante doloroso: Parámetros de Testnet como 12 bloques, ~24h o ~48h pueden ser Parámetros Mutables, pero lo más fiable en realidad es la Transición de Estado entre Pre-PegIn, Finalización de ACK, Estado Activo y Estado Final.
En tu opinión, ¿debería un buen Bitcoin Vault intentar que la experiencia se sienta “rápida”, o debería obligar a los usuarios a respetar cada capa de autoridad como esta?
#baby $BABY @BabylonLabs_io