I have a pretty bad habit when testing protocols: the moment I see true, my brain automatically stamps it as “done”... and that exact reflex once made I misread an entire State Machine.
that day, looking at ack_complete=true, I almost ignored vault_active=false.
good thing I stopped.
Pre-PegIn passing 12 Signet Block Confirmations only means the Confirmation Count has reached the Trigger Condition for ACK Collection to begin, not that Vault Activation has happened.
one state label changes, and the control rights change with it.
Signing Participants completing the Collaborative Setup within an ACK Window of roughly 24 hours gives ack_complete=true; but User Authorization still does not exist if the User has not performed the Secret Reveal within the Activation Window of roughly 48 hours.
24/48 = 50%.
in other words, the ACK Window occupies only about half of the Activation Window's time space... yet I used to unconsciously treat ACK Completion as the Final State.
honestly, this is where I find the design of @BabylonLabs_io pretty uncompromising.
the protocol does not care how impatient we are.
it only cares whether the State Dependency is correct.
if there are not enough ACKs before Expiration, the Vault may expire and Peg-in Fee Refund becomes a valid branch.
if enough ACKs already exist but Secret Reveal has not happened, continuing to suspect ACK Data Loss or spamming ACK Retry only sends us in circles.
I started reading logs in three layers: Block Confirmation first, Collaborative Setup second, User Activation last.
no skipping steps.
no interpreting the protocol on its behalf.
and from that point on, I also noticed something rather painful: Testnet Parameters such as 12 blocks, ~24h, or ~48h may be Mutable Parameters, but the most reliable thing is actually the State Transition between Pre-PegIn, ACK Completion, Active State, and Final State.
in your view, should a good Bitcoin Vault try to make the experience feel “fast”, or should it force users to respect each layer of authority like this?
#baby $BABY @BabylonLabs_io
that day, looking at ack_complete=true, I almost ignored vault_active=false.
good thing I stopped.
Pre-PegIn passing 12 Signet Block Confirmations only means the Confirmation Count has reached the Trigger Condition for ACK Collection to begin, not that Vault Activation has happened.
one state label changes, and the control rights change with it.
Signing Participants completing the Collaborative Setup within an ACK Window of roughly 24 hours gives ack_complete=true; but User Authorization still does not exist if the User has not performed the Secret Reveal within the Activation Window of roughly 48 hours.
24/48 = 50%.
in other words, the ACK Window occupies only about half of the Activation Window's time space... yet I used to unconsciously treat ACK Completion as the Final State.
honestly, this is where I find the design of @BabylonLabs_io pretty uncompromising.
the protocol does not care how impatient we are.
it only cares whether the State Dependency is correct.
if there are not enough ACKs before Expiration, the Vault may expire and Peg-in Fee Refund becomes a valid branch.
if enough ACKs already exist but Secret Reveal has not happened, continuing to suspect ACK Data Loss or spamming ACK Retry only sends us in circles.
I started reading logs in three layers: Block Confirmation first, Collaborative Setup second, User Activation last.
no skipping steps.
no interpreting the protocol on its behalf.
and from that point on, I also noticed something rather painful: Testnet Parameters such as 12 blocks, ~24h, or ~48h may be Mutable Parameters, but the most reliable thing is actually the State Transition between Pre-PegIn, ACK Completion, Active State, and Final State.
in your view, should a good Bitcoin Vault try to make the experience feel “fast”, or should it force users to respect each layer of authority like this?
#baby $BABY @BabylonLabs_io