i kept staring at the Babylon finality vote because the field that should have looked boring was the one refusing to change.
new block hash.
same height.
same public randomness.
and that last part started bothering me more than the conflict.
a Babylon Finality Provider commits public randomness before the block choice exists. later, when the block arrives, that height gets its EOTS signature and everything looks normal.
one height. one block. one use.
then another vote appears for the same height.
different block hash.
same public randomness.
why is the unchanged field the dangerous one?
i thought the contradiction lived in the two hashes. Babylon could compare them, see the Finality Provider backed incompatible histories, and punish it.
but the hashes only show the disagreement.
the repeated randomness shows how the signatures were made.
apparently that is what the Finality Provider was never allowed to repeat.
the same public randomness points back to the same private randomness underneath both EOTS signatures. once that one-time secret is used against two block hashes, the pair stops behaving like two ordinary votes.
it becomes enough to extract the Finality Provider’s EOTS private key.
which made the screen feel backwards.
the thing that changed shows the lie.
the thing that stayed the same makes the lie slashable.
Babylon does not need to send whole offence to Bitcoin after that. the extracted key supplies what the pre-signed slashing transactions behind the BTC delegations were missing.
voting power drops. the Finality Provider is tombstoned. native BTC can now enter slashing paths created before either vote existed.
and i still keep looking at that public randomness.
it was committed before either block looked dangerous.
the first vote used it once and exposed nothing.
the second vote did not alter it.
that was the problem.
two block hashes are arguing on the screen.
the quiet field between them is the clue that the one-time secret underneath was asked to survive twice.
@BabylonLabs_io #baby $BABY $BLESS $TAKE
new block hash.
same height.
same public randomness.
and that last part started bothering me more than the conflict.
a Babylon Finality Provider commits public randomness before the block choice exists. later, when the block arrives, that height gets its EOTS signature and everything looks normal.
one height. one block. one use.
then another vote appears for the same height.
different block hash.
same public randomness.
why is the unchanged field the dangerous one?
i thought the contradiction lived in the two hashes. Babylon could compare them, see the Finality Provider backed incompatible histories, and punish it.
but the hashes only show the disagreement.
the repeated randomness shows how the signatures were made.
apparently that is what the Finality Provider was never allowed to repeat.
the same public randomness points back to the same private randomness underneath both EOTS signatures. once that one-time secret is used against two block hashes, the pair stops behaving like two ordinary votes.
it becomes enough to extract the Finality Provider’s EOTS private key.
which made the screen feel backwards.
the thing that changed shows the lie.
the thing that stayed the same makes the lie slashable.
Babylon does not need to send whole offence to Bitcoin after that. the extracted key supplies what the pre-signed slashing transactions behind the BTC delegations were missing.
voting power drops. the Finality Provider is tombstoned. native BTC can now enter slashing paths created before either vote existed.
and i still keep looking at that public randomness.
it was committed before either block looked dangerous.
the first vote used it once and exposed nothing.
the second vote did not alter it.
that was the problem.
two block hashes are arguing on the screen.
the quiet field between them is the clue that the one-time secret underneath was asked to survive twice.
@BabylonLabs_io #baby $BABY $BLESS $TAKE