Eu tenho um hábito bem ruim ao testar protocolos: no momento em que vejo o verdadeiro, meu cérebro automaticamente carimba como “feito”... e esse reflexo exato já me fez interpretar mal uma State Machine inteira.
naquele dia, ao ver ack_complete=true, quase ignorei vault_active=false.
graças a Deus eu parei.
Passar 12 Confirmações do Signet antes do PegIn apenas significa que a Contagem de Confirmações atingiu a Condição de Gatilho para que a Coleta de ACK comece, não que a Ativação do Vault tenha acontecido.
um rótulo de estado muda, e junto com ele mudam os direitos de controle.
Os Participantes de Assinatura que concluem a Configuração Colaborativa dentro de uma Janela de ACK de cerca de 24 horas obtêm ack_complete=true; mas a Autorização do Usuário ainda não existe se o Usuário não tiver feito o Secret Reveal dentro da Janela de Ativação de cerca de 48 horas.
24/48 = 50%.
em outras palavras, a Janela de ACK ocupa apenas cerca de metade do espaço de tempo da Janela de Ativação... ainda assim, eu costumava tratar inconscientemente a Conclusão do ACK como o Estado Final.
sinceramente, é aqui que eu acho o design de @BabylonLabs_io pretty implacável.
o protocolo não se importa com o quanto impacientes somos.
ele só se importa se a Dependência de Estado está correta.
se não houver ACKs suficientes antes do Expiration, o Vault pode expirar e o Reembolso da Taxa do Peg-in vira um ramo válido.
se ACKs suficientes já existirem, mas o Secret Reveal ainda não aconteceu, continuar a suspeitar de Perda de Dados do ACK ou ficar fazendo spam de Retentativa de ACK só nos coloca em círculos.
comecei a ler logs em três camadas: Confirmação de Bloco primeiro, Configuração Colaborativa segundo, Ativação do Usuário por último.
sem pular etapas.
sem interpretar o protocolo por conta própria.
e a partir desse ponto, eu também notei algo bem doloroso: Parâmetros de Testnet como 12 blocos, ~24h ou ~48h podem ser Parâmetros Mutáveis, mas a coisa mais confiável na prática é realmente a Transição de Estado entre Pre-PegIn, Conclusão do ACK, Estado Ativo e Estado Final.
na sua visão, um bom Bitcoin Vault deve tentar fazer a experiência parecer “rápida”, ou deve obrigar os usuários a respeitar cada camada de autoridade assim?
#baby $BABY @BabylonLabs_io
naquele dia, ao ver ack_complete=true, quase ignorei vault_active=false.
graças a Deus eu parei.
Passar 12 Confirmações do Signet antes do PegIn apenas significa que a Contagem de Confirmações atingiu a Condição de Gatilho para que a Coleta de ACK comece, não que a Ativação do Vault tenha acontecido.
um rótulo de estado muda, e junto com ele mudam os direitos de controle.
Os Participantes de Assinatura que concluem a Configuração Colaborativa dentro de uma Janela de ACK de cerca de 24 horas obtêm ack_complete=true; mas a Autorização do Usuário ainda não existe se o Usuário não tiver feito o Secret Reveal dentro da Janela de Ativação de cerca de 48 horas.
24/48 = 50%.
em outras palavras, a Janela de ACK ocupa apenas cerca de metade do espaço de tempo da Janela de Ativação... ainda assim, eu costumava tratar inconscientemente a Conclusão do ACK como o Estado Final.
sinceramente, é aqui que eu acho o design de @BabylonLabs_io pretty implacável.
o protocolo não se importa com o quanto impacientes somos.
ele só se importa se a Dependência de Estado está correta.
se não houver ACKs suficientes antes do Expiration, o Vault pode expirar e o Reembolso da Taxa do Peg-in vira um ramo válido.
se ACKs suficientes já existirem, mas o Secret Reveal ainda não aconteceu, continuar a suspeitar de Perda de Dados do ACK ou ficar fazendo spam de Retentativa de ACK só nos coloca em círculos.
comecei a ler logs em três camadas: Confirmação de Bloco primeiro, Configuração Colaborativa segundo, Ativação do Usuário por último.
sem pular etapas.
sem interpretar o protocolo por conta própria.
e a partir desse ponto, eu também notei algo bem doloroso: Parâmetros de Testnet como 12 blocos, ~24h ou ~48h podem ser Parâmetros Mutáveis, mas a coisa mais confiável na prática é realmente a Transição de Estado entre Pre-PegIn, Conclusão do ACK, Estado Ativo e Estado Final.
na sua visão, um bom Bitcoin Vault deve tentar fazer a experiência parecer “rápida”, ou deve obrigar os usuários a respeitar cada camada de autoridade assim?
#baby $BABY @BabylonLabs_io