Irgendetwas hat mich dazu gebracht, meine Finger vom Scrollen abzuhalten.

Ich habe in dem Dokument zu @BabylonLabs_io nachgesehen und den Ablauf zur Verpfändung geprüft. Dabei habe ich festgestellt, dass eine Verpfändung nicht aktiviert wird, sobald Bitcoin-Transaktionen den Mempool erreichen. Selbst nicht, nachdem eine Bestätigung erfolgt ist. Babylon betrachtet eine Verpfändung erst dann als erfüllt für die nachgelagerte Verarbeitung, wenn die im Protokoll konfigurierten k-depth erreicht sind, und durchläuft dann erst den nachfolgenden Aktivierungsprozess. Das ist ein Governance-Parameter im Modul x/btccheckpoint.

Das ist zwar ebenfalls ein Verkaufsargument in Bezug auf die Sicherheit von Bitcoin, aber die meisten Nutzer glauben wahrscheinlich, dass ein Block bereits das endgültige Ergebnis ist.

Das ist der Teil, den niemand in die Pitch-Unterlagen aufnimmt. Im Marketing heißt es, dass der Bitcoin-Zeitstempel dir eine Sicherheitsgarantie aus dem Bitcoin-PoW gibt – technisch stimmt das. Aber es gilt erst, nachdem deine Verpfändung tief genug in der Kette vergraben ist. Bei unzureichenden Bestätigungen kann eine flache Ketten-Reorganisation trotzdem dazu führen, dass diese Verpfändungstransaktion zurückgerollt wird. Daher wird Babylon sie nicht vorzeitig als erfüllt für die nachgelagerte Verarbeitung betrachten. Babylon behandelt die Bestätigungstiefe als wichtigen Sicherheitsschwellwert, um diese Verpfändung weiter zu verarbeiten – nicht nur als Nachweis, dass sie enthalten ist. Mechanisch macht das Sinn – man kann keine Sicherheit auf Sand aufbauen –, aber es verrät dir auch leise, dass nicht jede Bestätigung gleich viel Vertrauen trägt.

Ich habe die Aufgabe zur Hälfte unterbrochen und mir eine Tasse Kaffee geholt. Dabei habe ich die ganze Zeit nachgedacht: Schützt diese Verzögerung die Nutzer – oder macht sie nur sichtbar, wie zerbrechlich frühe Blöcke eigentlich sind? Vielleicht beides.

#baby $BABY