Während ich das Toolkit „Babylon’s Trustless Bitcoin Vaults“ (TBV) las, stellte ich mir eine Frage: „Was passiert mit dem BTC-Betrag, bevor die Bitcoin-Transaktion erstellt wird?“
Der Wert existiert zunächst in JavaScript. Das ist die Schicht, die ein Wallet oder eine Web-App verwendet.
Dann gelangt der Betrag in Rust WASM. Dieses Modul verarbeitet die Transaktionslogik innerhalb der Anwendung.
Um die Zahl zu übertragen, legt das Toolkit sie in einem BigUint64Array ab. Dieser Container akzeptiert nur vorzeichenlose 64‑Bit-Integer.
Also testete ich den ersten Wert oberhalb seiner Grenze.
18,446,744,073,709,551,616n wurde eingegeben.
0n kam zurück.
Nichts ist abgestürzt. Die Zahl war exakt 2^64.
Das ist einen Schritt über dem größten Wert, den der Container speichern kann. JavaScript hat ihn stattdessen auf Null „gewrapped“, statt ihn abzulehnen.
Jetzt ergeben Bablon’s Checks mehr Sinn.
Bevor ein PegIn-Betrag in Rust gelangt, verlangt das Toolkit einen positiven Bigint. Es weist außerdem alles zurück, was größer ist als 2^64 - 1, oder 18,446,744,073,709,551,615.
Auch der Rückweg wird geprüft.
HTLC-Werte, PegIn-Beträge, Vault-Wert und der Mindestanspruchswert müssen weiterhin positive Bigints sein. Nur dann können sie in Satoshi-Berechnungen einfließen.
Die Gefahr zeigt sich, bevor Bitcoin überhaupt die Transaktion sieht.
Eine TBV-Transaktion kann dennoch ein gültiges Taproot-Skript haben. Auch Hashlocks und Signaturen könnten korrekt sein.
Der Betrag kann jedoch falsch sein.
JavaScript und Rust müssen sich nur darüber nicht einig sein, was eine bestimmte Zahl bedeutet. Es muss kein privater Schlüssel geleakt werden. Es muss kein Beweis fehlschlagen.
Die kryptografische Korrektheit kann überleben. Die monetäre Korrektheit vielleicht nicht.
Um fair zu sein: Kein echter Nutzer versucht, 2^64 Satoshis zu hinterlegen. Babylon blockiert diesen Wert auch in seinem offiziellen Toolkit.
Das ist kein aktiver Overflow-Bug.
Der Grenzfall ist wichtig, weil er die Schranke sichtbar macht. Eine Änderung am ABI oder eine modifizierte WASM-Binärdatei könnte einen fehlerhaften Betrag zurückgeben.
Auch ein Wallet oder eine Drittanbieter-Integration könnte die gleichen Checks überspringen. Jede Signatur könnte weiterhin gültig bleiben, während die Transaktion den falschen Wert trägt.
Babylon schützt diese Grenze in dem Toolkit, das es kontrolliert. Der schwierigere Test beginnt, wenn TBV Software erreicht, die es nicht kontrolliert. @BabylonLabs_io #baby $BABY $AKE
Der Wert existiert zunächst in JavaScript. Das ist die Schicht, die ein Wallet oder eine Web-App verwendet.
Dann gelangt der Betrag in Rust WASM. Dieses Modul verarbeitet die Transaktionslogik innerhalb der Anwendung.
Um die Zahl zu übertragen, legt das Toolkit sie in einem BigUint64Array ab. Dieser Container akzeptiert nur vorzeichenlose 64‑Bit-Integer.
Also testete ich den ersten Wert oberhalb seiner Grenze.
18,446,744,073,709,551,616n wurde eingegeben.
0n kam zurück.
Nichts ist abgestürzt. Die Zahl war exakt 2^64.
Das ist einen Schritt über dem größten Wert, den der Container speichern kann. JavaScript hat ihn stattdessen auf Null „gewrapped“, statt ihn abzulehnen.
Jetzt ergeben Bablon’s Checks mehr Sinn.
Bevor ein PegIn-Betrag in Rust gelangt, verlangt das Toolkit einen positiven Bigint. Es weist außerdem alles zurück, was größer ist als 2^64 - 1, oder 18,446,744,073,709,551,615.
Auch der Rückweg wird geprüft.
HTLC-Werte, PegIn-Beträge, Vault-Wert und der Mindestanspruchswert müssen weiterhin positive Bigints sein. Nur dann können sie in Satoshi-Berechnungen einfließen.
Die Gefahr zeigt sich, bevor Bitcoin überhaupt die Transaktion sieht.
Eine TBV-Transaktion kann dennoch ein gültiges Taproot-Skript haben. Auch Hashlocks und Signaturen könnten korrekt sein.
Der Betrag kann jedoch falsch sein.
JavaScript und Rust müssen sich nur darüber nicht einig sein, was eine bestimmte Zahl bedeutet. Es muss kein privater Schlüssel geleakt werden. Es muss kein Beweis fehlschlagen.
Die kryptografische Korrektheit kann überleben. Die monetäre Korrektheit vielleicht nicht.
Um fair zu sein: Kein echter Nutzer versucht, 2^64 Satoshis zu hinterlegen. Babylon blockiert diesen Wert auch in seinem offiziellen Toolkit.
Das ist kein aktiver Overflow-Bug.
Der Grenzfall ist wichtig, weil er die Schranke sichtbar macht. Eine Änderung am ABI oder eine modifizierte WASM-Binärdatei könnte einen fehlerhaften Betrag zurückgeben.
Auch ein Wallet oder eine Drittanbieter-Integration könnte die gleichen Checks überspringen. Jede Signatur könnte weiterhin gültig bleiben, während die Transaktion den falschen Wert trägt.
Babylon schützt diese Grenze in dem Toolkit, das es kontrolliert. Der schwierigere Test beginnt, wenn TBV Software erreicht, die es nicht kontrolliert. @BabylonLabs_io #baby $BABY $AKE