Ich habe bei Tests für Protokolle eine ziemlich schlechte Angewohnheit: Sobald ich „true“ sehe, stempelt mein Gehirn das automatisch als „erledigt“ ab … und genau dieser Reflex ließ mich einmal eine komplette Zustandsmaschine falsch lesen.
An dem Tag habe ich, als ich ack_complete=true gesehen habe, fast ignoriert, dass vault_active=false ist.
Zum Glück habe ich aufgehört.
„Pre-PegIn“ bedeutet, dass bei dem Passieren von 12 Signet-Block-Bestätigungen nur die Confirmation Count die Triggerbedingung erreicht hat, damit die ACK-Sammlung beginnen kann – nicht, dass eine Vault-Aktivierung bereits stattgefunden hat.
Ein Zustandslabel ändert sich, und mit ihm ändern sich auch die Kontrollrechte.
Wenn Signing Participants die Collaborative Setup innerhalb eines ACK Windows von ungefähr 24 Stunden abschließen, gilt ack_complete=true; aber eine User Authorization existiert immer noch nicht, wenn der User das Secret Reveal nicht innerhalb des Aktivierungsfensters von ungefähr 48 Stunden durchgeführt hat.
24/48 = 50%.
Mit anderen Worten: Das ACK Window nimmt nur ungefähr die Hälfte des Zeitraums des Aktivierungsfensters ein … und trotzdem habe ich früher unbewusst ACK Completion als den Endzustand behandelt.
Ehrlich gesagt finde ich genau hier die Gestaltung von <c-1/>@BabylonLabs_io </c-1/>pretty kompromisslos.
Das Protokoll kümmert sich nicht darum, wie ungeduldig wir sind.
Es kümmert sich nur darum, ob die Zustandsabhängigkeit korrekt ist.
Wenn nicht genügend ACKs vor Ablauf eintreffen, kann die Vault ablaufen und die Peg-in Fee Refund wird zu einem gültigen Zweig.
Wenn genug ACKs bereits existieren, aber das Secret Reveal nicht passiert ist, weiter zu vermuten, dass ACK-Daten verloren gegangen sind, oder das ACK-Retry zu spammen, bringt uns nur im Kreis.
Ich habe angefangen, Logs in drei Ebenen zu lesen: zuerst Block Confirmation, dann Collaborative Setup, und zuletzt User Activation.
Keine Schritte überspringen.
Das Protokoll nicht in unserem Namen interpretieren.
Und von da an habe ich auch noch etwas ziemlich Schmerzliches bemerkt: Testnet-Parameter wie 12 Blöcke, ~24h oder ~48h mögen veränderbare Parameter sein, aber das Zuverlässigste ist tatsächlich die Zustandsübergang zwischen Pre-PegIn, ACK Completion, Active State und Final State.
Sollte deiner Meinung nach eine gute Bitcoin-Vault versuchen, dass sich die Erfahrung „schnell“ anfühlt, oder soll sie Benutzer dazu zwingen, jede dieser Autoritätsebenen so zu respektieren?
#baby $BABY @BabylonLabs_io
An dem Tag habe ich, als ich ack_complete=true gesehen habe, fast ignoriert, dass vault_active=false ist.
Zum Glück habe ich aufgehört.
„Pre-PegIn“ bedeutet, dass bei dem Passieren von 12 Signet-Block-Bestätigungen nur die Confirmation Count die Triggerbedingung erreicht hat, damit die ACK-Sammlung beginnen kann – nicht, dass eine Vault-Aktivierung bereits stattgefunden hat.
Ein Zustandslabel ändert sich, und mit ihm ändern sich auch die Kontrollrechte.
Wenn Signing Participants die Collaborative Setup innerhalb eines ACK Windows von ungefähr 24 Stunden abschließen, gilt ack_complete=true; aber eine User Authorization existiert immer noch nicht, wenn der User das Secret Reveal nicht innerhalb des Aktivierungsfensters von ungefähr 48 Stunden durchgeführt hat.
24/48 = 50%.
Mit anderen Worten: Das ACK Window nimmt nur ungefähr die Hälfte des Zeitraums des Aktivierungsfensters ein … und trotzdem habe ich früher unbewusst ACK Completion als den Endzustand behandelt.
Ehrlich gesagt finde ich genau hier die Gestaltung von <c-1/>@BabylonLabs_io </c-1/>pretty kompromisslos.
Das Protokoll kümmert sich nicht darum, wie ungeduldig wir sind.
Es kümmert sich nur darum, ob die Zustandsabhängigkeit korrekt ist.
Wenn nicht genügend ACKs vor Ablauf eintreffen, kann die Vault ablaufen und die Peg-in Fee Refund wird zu einem gültigen Zweig.
Wenn genug ACKs bereits existieren, aber das Secret Reveal nicht passiert ist, weiter zu vermuten, dass ACK-Daten verloren gegangen sind, oder das ACK-Retry zu spammen, bringt uns nur im Kreis.
Ich habe angefangen, Logs in drei Ebenen zu lesen: zuerst Block Confirmation, dann Collaborative Setup, und zuletzt User Activation.
Keine Schritte überspringen.
Das Protokoll nicht in unserem Namen interpretieren.
Und von da an habe ich auch noch etwas ziemlich Schmerzliches bemerkt: Testnet-Parameter wie 12 Blöcke, ~24h oder ~48h mögen veränderbare Parameter sein, aber das Zuverlässigste ist tatsächlich die Zustandsübergang zwischen Pre-PegIn, ACK Completion, Active State und Final State.
Sollte deiner Meinung nach eine gute Bitcoin-Vault versuchen, dass sich die Erfahrung „schnell“ anfühlt, oder soll sie Benutzer dazu zwingen, jede dieser Autoritätsebenen so zu respektieren?
#baby $BABY @BabylonLabs_io