continuo pensando se a Babylon coloca um checkpoint de época do Babylon Genesis na camada base do Bitcoin; então o Bitcoin deve de algum modo entender o que esse checkpoint significa.
certo?
porque se o timestamping do Bitcoin está ajudando a proteger o Babylon Genesis contra um ataque de longo alcance, então com certeza o Bitcoin deve saber algo sobre o conjunto de validadores do CometBFT apoiado pelo BABY. os votos de consenso. o limite de época. seja lá o que esses validadores estavam concordando de fato...
caso contrário, o que exatamente o Bitcoin está protegendo?
mas o checkpointing de BTC da Babylon é mais frio do que isso.
um checkpoint de época do Babylon Genesis alcança o ledger do Bitcoin e fica enterrado sob o Proof-of-Work acumulado do Bitcoin. agora um fork posterior de longo alcance tem esse problema feio.
por que seu supostamente canônico histórico apareceu depois do checkpoint da Babylon já estar dentro do Bitcoin?
e essas assinaturas posteriores nem sequer precisam parecer obviamente falsas. ex-validadores do CometBFT ainda podem manter chaves de assinatura que eram legítimas dentro de um conjunto anterior de validadores do Babylon Genesis. eles podem montar outro histórico depois. internamente limpo. devidamente assinado. suficientemente convincente, talvez.
mas convincente para quem... uma vez que o Bitcoin já tem o checkpoint anterior?
“o Bitcoin nunca entendeu o histórico. ele só capturou uma versão chegando primeiro.”
isso fica me arranhando.
talvez eu tenha continuado pedindo ao Bitcoin para fazer um trabalho que a Babylon nunca pediu.
o Bitcoin não executa blocos do Babylon Genesis. ele não faz replay do estado do CometBFT, não inspeciona <c-1/> $BABY delegação, nem decide se cada voto de validador faz sentido.
ele só deixa todo histórico posterior da Babylon com essa pergunta desconfortável.
por que o supostamente passado real chegou em segundo lugar?
@BabylonLabs_io #baby $EUL
certo?
porque se o timestamping do Bitcoin está ajudando a proteger o Babylon Genesis contra um ataque de longo alcance, então com certeza o Bitcoin deve saber algo sobre o conjunto de validadores do CometBFT apoiado pelo BABY. os votos de consenso. o limite de época. seja lá o que esses validadores estavam concordando de fato...
caso contrário, o que exatamente o Bitcoin está protegendo?
mas o checkpointing de BTC da Babylon é mais frio do que isso.
um checkpoint de época do Babylon Genesis alcança o ledger do Bitcoin e fica enterrado sob o Proof-of-Work acumulado do Bitcoin. agora um fork posterior de longo alcance tem esse problema feio.
por que seu supostamente canônico histórico apareceu depois do checkpoint da Babylon já estar dentro do Bitcoin?
e essas assinaturas posteriores nem sequer precisam parecer obviamente falsas. ex-validadores do CometBFT ainda podem manter chaves de assinatura que eram legítimas dentro de um conjunto anterior de validadores do Babylon Genesis. eles podem montar outro histórico depois. internamente limpo. devidamente assinado. suficientemente convincente, talvez.
mas convincente para quem... uma vez que o Bitcoin já tem o checkpoint anterior?
“o Bitcoin nunca entendeu o histórico. ele só capturou uma versão chegando primeiro.”
isso fica me arranhando.
talvez eu tenha continuado pedindo ao Bitcoin para fazer um trabalho que a Babylon nunca pediu.
o Bitcoin não executa blocos do Babylon Genesis. ele não faz replay do estado do CometBFT, não inspeciona <c-1/> $BABY delegação, nem decide se cada voto de validador faz sentido.
ele só deixa todo histórico posterior da Babylon com essa pergunta desconfortável.
por que o supostamente passado real chegou em segundo lugar?
@BabylonLabs_io #baby $EUL
