Sigo pensando en que si Babylon coloca un checkpoint de la época de Babylon Genesis en la capa base de Bitcoin, entonces Bitcoin debe, de alguna manera, entender qué significa ese checkpoint.
¿cierto?
porque si el timestamping de Bitcoin está ayudando a proteger Babylon Genesis de un ataque de largo alcance, entonces seguramente Bitcoin debe saber algo sobre el conjunto de validadores de CometBFT respaldado por BABY. las votaciones de consenso. el límite de la época. lo que sea en lo que esos validadores realmente estaban de acuerdo...
si no, ¿qué exactamente está protegiendo Bitcoin?
pero el checkpointing de BTC de Babylon es más frío que eso.
un checkpoint de la época de Babylon Genesis llega al ledger de Bitcoin y queda enterrado bajo la acumulación de Prueba de Trabajo de Bitcoin. ahora, una bifurcación posterior de largo alcance tiene este desagradable problema.
¿por qué tu supuestamente historia canónica apareció después de que ya hubiera un checkpoint de Babylon dentro de Bitcoin?
y esas firmas posteriores ni siquiera tienen que parecer obviamente falsas. antiguos validadores de CometBFT aún pueden conservar claves de firma que eran legítimas dentro de un conjunto anterior de validadores de Babylon Genesis. pueden armar otra historia más tarde. limpia por dentro. firmada correctamente. lo bastante convincente, quizá.
pero, ¿convincente para quién... una vez que Bitcoin ya tiene el checkpoint anterior?
“Bitcoin nunca entendió la historia. solo atrapó una versión llegando primero.”
Eso no deja de rascarme la cabeza.
quizá seguí pidiéndole a Bitcoin que hiciera un trabajo que Babylon nunca le dio.
Bitcoin no ejecuta bloques de Babylon Genesis. no vuelve a reproducir el estado de CometBFT, inspecciona la delegación $BABY , ni decide si cada voto del validador tiene sentido.
solo deja a toda historia posterior de Babylon con esta incómoda pregunta.
¿por qué el pasado supuestamente real llegó segundo?
@BabylonLabs_io #baby $EUL
¿cierto?
porque si el timestamping de Bitcoin está ayudando a proteger Babylon Genesis de un ataque de largo alcance, entonces seguramente Bitcoin debe saber algo sobre el conjunto de validadores de CometBFT respaldado por BABY. las votaciones de consenso. el límite de la época. lo que sea en lo que esos validadores realmente estaban de acuerdo...
si no, ¿qué exactamente está protegiendo Bitcoin?
pero el checkpointing de BTC de Babylon es más frío que eso.
un checkpoint de la época de Babylon Genesis llega al ledger de Bitcoin y queda enterrado bajo la acumulación de Prueba de Trabajo de Bitcoin. ahora, una bifurcación posterior de largo alcance tiene este desagradable problema.
¿por qué tu supuestamente historia canónica apareció después de que ya hubiera un checkpoint de Babylon dentro de Bitcoin?
y esas firmas posteriores ni siquiera tienen que parecer obviamente falsas. antiguos validadores de CometBFT aún pueden conservar claves de firma que eran legítimas dentro de un conjunto anterior de validadores de Babylon Genesis. pueden armar otra historia más tarde. limpia por dentro. firmada correctamente. lo bastante convincente, quizá.
pero, ¿convincente para quién... una vez que Bitcoin ya tiene el checkpoint anterior?
“Bitcoin nunca entendió la historia. solo atrapó una versión llegando primero.”
Eso no deja de rascarme la cabeza.
quizá seguí pidiéndole a Bitcoin que hiciera un trabajo que Babylon nunca le dio.
Bitcoin no ejecuta bloques de Babylon Genesis. no vuelve a reproducir el estado de CometBFT, inspecciona la delegación $BABY , ni decide si cada voto del validador tiene sentido.
solo deja a toda historia posterior de Babylon con esta incómoda pregunta.
¿por qué el pasado supuestamente real llegó segundo?
@BabylonLabs_io #baby $EUL
