Je continue de me demander si Babylon met un point de contrôle d’époque Babylon Genesis sur la couche de base de Bitcoin, alors Bitcoin doit d’une manière ou d’une autre comprendre ce que signifie ce point de contrôle.
c’est bien ça ?
car si l’horodatage de Bitcoin aide à protéger Babylon Genesis contre une attaque à long terme, alors forcément, Bitcoin doit savoir quelque chose sur l’ensemble de validateurs de CometBFT adossé au BABY. les votes de consensus. la frontière d’époque. peu importe sur quoi ces validateurs étaient réellement d’accord...
sinon, qu’est-ce que Bitcoin protège exactement ?
mais le checkpointing BTC de Babylon est plus froid que ça.
un point de contrôle d’époque Babylon Genesis atteint le registre Bitcoin et se retrouve enfoui sous une PoW Bitcoin accumulée. puis une fork à long terme plus tardive a ce problème affreux.
pourquoi votre histoire soi-disant canonique est-elle apparue après le checkpoint Babylon, déjà en place dans Bitcoin ?
et ces signatures ultérieures n’ont même pas besoin d’avoir l’air manifestement fausses. d’anciens validateurs CometBFT peuvent encore détenir des clés de signature qui étaient légitimes dans un ancien ensemble de validateurs Babylon Genesis. ils peuvent reconstituer une autre histoire plus tard. propre en interne. correctement signée. suffisamment convaincante, peut-être.
mais convaincante pour qui... une fois que Bitcoin a déjà le checkpoint précédent ?
« Bitcoin n’a jamais compris l’histoire. il a juste vu une version arriver la première. »
ça continue de me gratter l’esprit.
peut-être que j’ai continué à demander à Bitcoin de faire un travail que Babylon ne lui avait jamais donné.
Bitcoin n’exécute pas les blocs de Babylon Genesis. il ne rejoue pas l’état de CometBFT, n’inspecte pas la délégation <$BABY >, et ne décide pas si chaque vote de validateur a du sens.
il laisse simplement toutes les histoires Babylon ultérieures avec cette question inconfortable.
pourquoi le passé supposément réel est-il arrivé en second ?
@BabylonLabs_io #baby $EUL
c’est bien ça ?
car si l’horodatage de Bitcoin aide à protéger Babylon Genesis contre une attaque à long terme, alors forcément, Bitcoin doit savoir quelque chose sur l’ensemble de validateurs de CometBFT adossé au BABY. les votes de consensus. la frontière d’époque. peu importe sur quoi ces validateurs étaient réellement d’accord...
sinon, qu’est-ce que Bitcoin protège exactement ?
mais le checkpointing BTC de Babylon est plus froid que ça.
un point de contrôle d’époque Babylon Genesis atteint le registre Bitcoin et se retrouve enfoui sous une PoW Bitcoin accumulée. puis une fork à long terme plus tardive a ce problème affreux.
pourquoi votre histoire soi-disant canonique est-elle apparue après le checkpoint Babylon, déjà en place dans Bitcoin ?
et ces signatures ultérieures n’ont même pas besoin d’avoir l’air manifestement fausses. d’anciens validateurs CometBFT peuvent encore détenir des clés de signature qui étaient légitimes dans un ancien ensemble de validateurs Babylon Genesis. ils peuvent reconstituer une autre histoire plus tard. propre en interne. correctement signée. suffisamment convaincante, peut-être.
mais convaincante pour qui... une fois que Bitcoin a déjà le checkpoint précédent ?
« Bitcoin n’a jamais compris l’histoire. il a juste vu une version arriver la première. »
ça continue de me gratter l’esprit.
peut-être que j’ai continué à demander à Bitcoin de faire un travail que Babylon ne lui avait jamais donné.
Bitcoin n’exécute pas les blocs de Babylon Genesis. il ne rejoue pas l’état de CometBFT, n’inspecte pas la délégation <$BABY >, et ne décide pas si chaque vote de validateur a du sens.
il laisse simplement toutes les histoires Babylon ultérieures avec cette question inconfortable.
pourquoi le passé supposément réel est-il arrivé en second ?
@BabylonLabs_io #baby $EUL