A dishonest actor is not afraid of being inspected. What they fear most is not knowing where the inspection will happen.
That was the first thought that came to mind when I encountered the numbers 307–301–6 in the BABE mechanism behind Trustless Bitcoin Vaults (TBV) by @BabylonLabs_io. I understood the numbers. What I didn’t understand was why a protocol would intentionally create so much extra work.
During peg-in, BABE generates 307 garbled circuit instances. Through a cut-and-choose protocol, 301 instances are opened to verify how the circuits were created, while only the remaining 6 are actually used.
At first, that looked terribly inefficient. Nearly 98% of the circuits never contribute to the final computation. If only six are needed, why not generate six from the start? Because that only works if the circuit generator already knows which six will survive. BABE removes exactly that advantage.
All 307 instances must be created before the protocol randomly selects 301 for inspection. The verifier is not simply checking the final result, but the integrity of the generation process itself. Since no one knows in advance which circuits will be challenged, preparing separate “honest” and “dishonest” versions becomes impractical.
That was when the 301 opened circuits stopped looking like wasted work. They are the cost of making verification unpredictable.
To me, that is the real design choice behind BABE. The protocol does not rely on participants being honest. It makes honesty the safer strategy because no one can predict what will be inspected.
The numbers 307–301–6 are therefore more than implementation details. They reflect a deliberate architectural trade-off inside TBV: spending more computation during verification to reduce trust assumptions before Bitcoin secures an application.
@BabylonLabs_io $ON $BABY #baby
That was the first thought that came to mind when I encountered the numbers 307–301–6 in the BABE mechanism behind Trustless Bitcoin Vaults (TBV) by @BabylonLabs_io. I understood the numbers. What I didn’t understand was why a protocol would intentionally create so much extra work.
During peg-in, BABE generates 307 garbled circuit instances. Through a cut-and-choose protocol, 301 instances are opened to verify how the circuits were created, while only the remaining 6 are actually used.
At first, that looked terribly inefficient. Nearly 98% of the circuits never contribute to the final computation. If only six are needed, why not generate six from the start? Because that only works if the circuit generator already knows which six will survive. BABE removes exactly that advantage.
All 307 instances must be created before the protocol randomly selects 301 for inspection. The verifier is not simply checking the final result, but the integrity of the generation process itself. Since no one knows in advance which circuits will be challenged, preparing separate “honest” and “dishonest” versions becomes impractical.
That was when the 301 opened circuits stopped looking like wasted work. They are the cost of making verification unpredictable.
To me, that is the real design choice behind BABE. The protocol does not rely on participants being honest. It makes honesty the safer strategy because no one can predict what will be inspected.
The numbers 307–301–6 are therefore more than implementation details. They reflect a deliberate architectural trade-off inside TBV: spending more computation during verification to reduce trust assumptions before Bitcoin secures an application.
@BabylonLabs_io $ON $BABY #baby