Ich frage mich ständig, ob Babylon einen Babylon-Genesis-Epoch-Checkpoint auf der Bitcoin-Basisschicht einträgt – dann muss Bitcoin doch irgendwie verstehen, was dieser Checkpoint bedeutet.
richtig?
weil, wenn Bitcoin- Timestamping dabei hilft, Babylon Genesis vor einem Long-Range-Angriff zu schützen, dann muss Bitcoin doch etwas über den BABY-gestützten CometBFT-Validator-Set wissen. die Konsensabstimmungen. die Epoch-Grenze. was auch immer diese Validatoren tatsächlich vereinbart haben...
sonst – wogegen schützt Bitcoin eigentlich genau?
aber Babylons BTC-Checkpointing ist kälter als das.
ein Babylon-Genesis-Epoch-Checkpoint erreicht das Bitcoin-Ledger und wird unter aufgehäufter Bitcoin Proof-of-Work begraben. nun hat eine spätere Long-Range-Gabel dieses hässliche Problem.
warum tauchte deine angeblich kanonische Geschichte auf, nachdem der Babylon-Checkpoint bereits in Bitcoin saß?
und diese späteren Signaturen müssen nicht einmal offensichtlich gefälscht wirken. ehemalige CometBFT-Validatoren können weiterhin Signaturschlüssel besitzen, die innerhalb eines älteren Babylon-Genesis-Validator-Sets legitim waren. sie können später eine weitere Geschichte zusammenstellen. intern sauber. korrekt signiert. überzeugend genug, vielleicht.
aber überzeugend für wen... sobald Bitcoin den früheren Checkpoint bereits hat?
„Bitcoin hat die Geschichte nie verstanden. es hat einfach nur eine Version erwischt, die zuerst ankam.“
das lässt mir keine Ruhe.
vielleicht habe ich Bitcoin immer wieder gebeten, eine Aufgabe zu übernehmen, die Babylon ihm nie gegeben hat.
Bitcoin führt keine Babylon-Genesis-Blöcke aus. es spielt CometBFT-Zustand nicht erneut ab, prüft keine $BABY -Delegation und entscheidet nicht, ob jede Validator-Abstimmung sinnvoll ist.
es lässt lediglich jede spätere Babylon-Geschichte mit dieser unbequemen Frage zurück.
warum kam die angeblich echte Vergangenheit zu spät?
@BabylonLabs_io #baby $EUL
richtig?
weil, wenn Bitcoin- Timestamping dabei hilft, Babylon Genesis vor einem Long-Range-Angriff zu schützen, dann muss Bitcoin doch etwas über den BABY-gestützten CometBFT-Validator-Set wissen. die Konsensabstimmungen. die Epoch-Grenze. was auch immer diese Validatoren tatsächlich vereinbart haben...
sonst – wogegen schützt Bitcoin eigentlich genau?
aber Babylons BTC-Checkpointing ist kälter als das.
ein Babylon-Genesis-Epoch-Checkpoint erreicht das Bitcoin-Ledger und wird unter aufgehäufter Bitcoin Proof-of-Work begraben. nun hat eine spätere Long-Range-Gabel dieses hässliche Problem.
warum tauchte deine angeblich kanonische Geschichte auf, nachdem der Babylon-Checkpoint bereits in Bitcoin saß?
und diese späteren Signaturen müssen nicht einmal offensichtlich gefälscht wirken. ehemalige CometBFT-Validatoren können weiterhin Signaturschlüssel besitzen, die innerhalb eines älteren Babylon-Genesis-Validator-Sets legitim waren. sie können später eine weitere Geschichte zusammenstellen. intern sauber. korrekt signiert. überzeugend genug, vielleicht.
aber überzeugend für wen... sobald Bitcoin den früheren Checkpoint bereits hat?
„Bitcoin hat die Geschichte nie verstanden. es hat einfach nur eine Version erwischt, die zuerst ankam.“
das lässt mir keine Ruhe.
vielleicht habe ich Bitcoin immer wieder gebeten, eine Aufgabe zu übernehmen, die Babylon ihm nie gegeben hat.
Bitcoin führt keine Babylon-Genesis-Blöcke aus. es spielt CometBFT-Zustand nicht erneut ab, prüft keine $BABY -Delegation und entscheidet nicht, ob jede Validator-Abstimmung sinnvoll ist.
es lässt lediglich jede spätere Babylon-Geschichte mit dieser unbequemen Frage zurück.
warum kam die angeblich echte Vergangenheit zu spät?
@BabylonLabs_io #baby $EUL
