Erstes Mal „Redeem“ von 0.01 BTC auf dem @BabylonLabs_io Public Testnet ausprobiert. Ich dachte, in ein paar Minuten würde das BTC wieder in die Wallet zurückkommen, wie bei den früheren Auszahlungen, also habe ich den Laptop einfach dastehen lassen und gewartet.
Irgendwann kam gar nichts an, also habe ich die Wallet mehrmals wieder geöffnet und dann F5 gedrückt, um zu prüfen, ob das Testnet überhaupt läuft.
Als ich dann die Docs noch einmal geöffnet und den neuen Abschnitt zum „peg-out“ gelesen habe, habe ich verstanden, dass ich auf die falsche Sache gewartet habe.
Nachdem ich die Anfrage zum Rücktausch von BTC gesendet habe, versucht das System nicht, das Ganze zu beschleunigen. Das BTC muss erst den gesamten, bereits beim Erstellen des Vault vorgesehenen Prozess durchlaufen, die Bestätigung auf Bitcoin L1 abwarten und erst dann in die Wallet zurückkehren.
Das, was ich eigentlich erwartet habe, war nicht die Antwort des Servers, sondern dass Bitcoin seine Arbeit vollständig erledigt.
Erst danach ist mir beim Lesen wieder eingefallen, dass ich beim Erstellen des Vault ziemlich viele Transaktionen signiert habe, es damals aber nicht so genau beachtet habe. Jetzt verstehe ich, warum Babylon das so macht. Das Gefühl von Ungeduld beim Warten auf den peg-out stellte sich am Ende als Teil des Designs heraus – nicht als langsame Systemreaktion.
Während ein peg-out läuft: Wenn die Benutzeroberfläche klar zeigt, in welchem Schritt man sich befindet, zum Beispiel Bitcoin Confirmation oder Vault Release, dann wissen Nutzer, dass sie gerade darauf warten, dass Bitcoin selbst etwas verarbeitet, statt zu denken, die Transaktion sei hängen geblieben und ständig die Wallet zu öffnen und zu überprüfen – so wie ich es gemacht habe (kleiner Hinweis).
Nach diesem Test: Wenn ich noch ein paar weitere Blöcke warten muss, werde ich beim nächsten Mal wahrscheinlich nicht mehr so ungeduldig sein wie beim ersten Mal.
@BabylonLabs_io $BABY #baby $BTC #BABY #Aavev4 #BTCFi
Irgendwann kam gar nichts an, also habe ich die Wallet mehrmals wieder geöffnet und dann F5 gedrückt, um zu prüfen, ob das Testnet überhaupt läuft.
Als ich dann die Docs noch einmal geöffnet und den neuen Abschnitt zum „peg-out“ gelesen habe, habe ich verstanden, dass ich auf die falsche Sache gewartet habe.
Nachdem ich die Anfrage zum Rücktausch von BTC gesendet habe, versucht das System nicht, das Ganze zu beschleunigen. Das BTC muss erst den gesamten, bereits beim Erstellen des Vault vorgesehenen Prozess durchlaufen, die Bestätigung auf Bitcoin L1 abwarten und erst dann in die Wallet zurückkehren.
Das, was ich eigentlich erwartet habe, war nicht die Antwort des Servers, sondern dass Bitcoin seine Arbeit vollständig erledigt.
Erst danach ist mir beim Lesen wieder eingefallen, dass ich beim Erstellen des Vault ziemlich viele Transaktionen signiert habe, es damals aber nicht so genau beachtet habe. Jetzt verstehe ich, warum Babylon das so macht. Das Gefühl von Ungeduld beim Warten auf den peg-out stellte sich am Ende als Teil des Designs heraus – nicht als langsame Systemreaktion.
Während ein peg-out läuft: Wenn die Benutzeroberfläche klar zeigt, in welchem Schritt man sich befindet, zum Beispiel Bitcoin Confirmation oder Vault Release, dann wissen Nutzer, dass sie gerade darauf warten, dass Bitcoin selbst etwas verarbeitet, statt zu denken, die Transaktion sei hängen geblieben und ständig die Wallet zu öffnen und zu überprüfen – so wie ich es gemacht habe (kleiner Hinweis).
Nach diesem Test: Wenn ich noch ein paar weitere Blöcke warten muss, werde ich beim nächsten Mal wahrscheinlich nicht mehr so ungeduldig sein wie beim ersten Mal.
@BabylonLabs_io $BABY #baby $BTC #BABY #Aavev4 #BTCFi