Ich hatte erwartet, dass der Pre-Signing-Schritt bei der Einrichtung des Vaults die naheliegenden Fälle abdeckt: Rückzahlung, Liquidation, vielleicht auch Redemption. Was ich nicht erwartet habe, ist, dass der Fehlerfall schon ebenfalls unterschrieben ist – noch bevor sich irgendwo auch nur ein einziger Satoshi bewegt hat.
Beim Einrichten eines Vaults für Trustless Bitcoin Vaults (TBV) ab @BabylonLabs_io liegt das BTC vorübergehend in einem Pre-PegIn-Ausgang, während die Bitcoin-Bestätigungen eintreffen. In genau diesem Zeitfenster, bevor der Vault überhaupt aktiviert ist, signierst du bereits die Refund-Transaktion, mit der du dein BTC zurückholen kannst, falls der Peg-in niemals abgeschlossen wird. Keine Zusage, das später zu bauen, wenn etwas kaputtgeht. Ein bereits signierter Ausgabepfad liegt dort bereit, ungenutzt, und wartet auf ein Szenario, das in den meisten Fällen nie eintritt.
Das hat mich ehrlich gesagt mehr überrascht als die Liquidations- und Redemption-Pfade, weil man über diese zumindest alle reden.
Der Refund-Pfad ist der, den niemand erwähnt, und er wird im selben Moment unterschrieben wie alles andere – nach derselben Pre-Commitment-Logik. Es wird später nichts improvisiert, einschließlich des Ausstiegs, wenn Dinge schiefgehen, noch bevor sie überhaupt richtig losgehen.
Das stellt neu in den Fokus, was Pre-Signing hier tatsächlich bedeutet. Es ist nicht nur das Festschreiben dessen, wie ein gesunder Vault sich verhält. Es ist auch das Festschreiben dessen, wie sich ein Fehlerfall verhält – zu einem Zeitpunkt, an dem der Fehler noch nicht eingetreten ist und möglicherweise nie eintreten wird.
Ich habe immer noch keine klare Antwort darauf, was passiert, wenn die eigene Signing-Konfiguration eines Depositors in genau diesem Zeitraum zusammenbricht, bevor diese Pre-signierten Pfade überhaupt existieren. Die Dokumentation beschreibt, was passiert, nachdem der Graph aufgebaut ist. Was passiert, wenn etwas schon vorher fehlschlägt, ist mir weniger klar.
#baby $BABY
Beim Einrichten eines Vaults für Trustless Bitcoin Vaults (TBV) ab @BabylonLabs_io liegt das BTC vorübergehend in einem Pre-PegIn-Ausgang, während die Bitcoin-Bestätigungen eintreffen. In genau diesem Zeitfenster, bevor der Vault überhaupt aktiviert ist, signierst du bereits die Refund-Transaktion, mit der du dein BTC zurückholen kannst, falls der Peg-in niemals abgeschlossen wird. Keine Zusage, das später zu bauen, wenn etwas kaputtgeht. Ein bereits signierter Ausgabepfad liegt dort bereit, ungenutzt, und wartet auf ein Szenario, das in den meisten Fällen nie eintritt.
Das hat mich ehrlich gesagt mehr überrascht als die Liquidations- und Redemption-Pfade, weil man über diese zumindest alle reden.
Der Refund-Pfad ist der, den niemand erwähnt, und er wird im selben Moment unterschrieben wie alles andere – nach derselben Pre-Commitment-Logik. Es wird später nichts improvisiert, einschließlich des Ausstiegs, wenn Dinge schiefgehen, noch bevor sie überhaupt richtig losgehen.
Das stellt neu in den Fokus, was Pre-Signing hier tatsächlich bedeutet. Es ist nicht nur das Festschreiben dessen, wie ein gesunder Vault sich verhält. Es ist auch das Festschreiben dessen, wie sich ein Fehlerfall verhält – zu einem Zeitpunkt, an dem der Fehler noch nicht eingetreten ist und möglicherweise nie eintreten wird.
Ich habe immer noch keine klare Antwort darauf, was passiert, wenn die eigene Signing-Konfiguration eines Depositors in genau diesem Zeitraum zusammenbricht, bevor diese Pre-signierten Pfade überhaupt existieren. Die Dokumentation beschreibt, was passiert, nachdem der Graph aufgebaut ist. Was passiert, wenn etwas schon vorher fehlschlägt, ist mir weniger klar.
#baby $BABY