Submarine Swap

Anna hält Bitcoin in einer gewöhnlichen Wallet. Ein Laden stellt ihr jedoch eine Lightning-Rechnung, also eine Zahlungsanforderung. Beim normalen Swap sperrt sie Bitcoin auf der Blockchain unter vereinbarten Bedingungen; der Dienst bezahlt dafür die Rechnung. Will sie Lightning-Guthaben an eine On-Chain-Adresse übertragen, braucht sie die Gegenrichtung: einen Reverse Submarine Swap, etwa Loop Out. Ihre Zahlungskanäle muss sie dafür nicht schließen. Neues Geld entsteht dabei nicht, und für die Lightning-Zahlung muss weiterhin eine nutzbare Route bestehen. [1] [4]

Ein Geheimnis lässt sich durch einen digitalen Fingerabdruck prüfen, ohne es praktisch aus diesem zurückrechnen zu können. Der geheime Wert heißt preimage. Sein digitaler Fingerabdruck ist ein Hash, der mit SHA256 berechnet wird. Bedingte Zahlungen namens HTLC verbinden ihn mit einer Frist. Beim umgekehrten Swap erzeugt Annas Anwendung das Geheimnis. Der Dienst hält ihre Lightning-Zahlung offen und sperrt den entsprechenden Bitcoin-Betrag auf der Blockchain. Holt Anna die Mittel mit einem claim ab, legt sie das Geheimnis auf der Blockchain offen oder übermittelt es bei einer gemeinsamen Abwicklung an den Dienst. Dieser kann dann die verknüpfte Zahlung abschließen. Ausstehend heißt noch nicht bezahlt. [1] [4]

Eine Meldung des Dienstes ist nicht dasselbe wie Geld in der Ziel-Wallet. Laut Boltz kann invoice.settled beim umgekehrten Swap nach Offenlegung des preimage und Begleichung der Lightning-Rechnung erscheinen. Der Dienst verfolgt nicht, ob Annas Anwendung die claim-Transaktion tatsächlich veröffentlicht. Deshalb muss sie den Ziel-Output prüfen, also den ihrer Wallet zugewiesenen Bitcoin-Betrag, sowie die nötigen Blockbestätigungen. Ein Block ist eine Gruppe von Transaktionen, die zur Blockchain hinzugefügt wird. Mit der Aufnahme in einen Block erhält eine Transaktion ihre erste Bestätigung; jeder nachfolgende Block bringt eine weitere. Ein unklarer Status ist kein guter Grund, dieselbe Zahlung sofort erneut zu senden. [1] [2]

Beim normalen Swap können Annas Bitcoin bereits auf der Blockchain gesperrt sein, während die Rechnung unbezahlt bleibt. Für die Rückholung, refund genannt, muss ihre Anwendung eine Transaktion erstellen und verbreiten. Ohne Zusammenarbeit des Dienstes muss sie auf den timelock warten, die vereinbarte Zeitbedingung. Bei einer noch offenen Lightning-Zahlung in Gegenrichtung können dagegen ausstehende HTLC aufgehoben und das Guthaben ohne Annas On-Chain-Refund freigegeben werden. Eine bereits abgeschlossene Zahlung kehrt aber nach Offenlegung des preimage nicht von selbst zurück. Richtung und Phase sind entscheidend. [1] [3]

Anna vergleicht den gesendeten mit dem tatsächlich erhaltenen Betrag. Die Differenz kann aus Dienst-, Lightning-Routing- und On-Chain-Gebühren bestehen. Ein gescheiterter normaler Swap kann zusätzlich eine Refund-Transaktion kosten. Auch die Zeit zählt: Ein veröffentlichter claim kann das preimage offenlegen, bevor ein Block ihn bestätigt. Die Loop-Dokumentation weist darauf hin, dass kurz vor dem timeout die Gebühr für den sweep, die Transaktion zum Abholen der Mittel, über das ursprüngliche Limit steigen kann. Die kryptografische Verknüpfung verspricht also keinen sofortigen, kostenlosen oder risikofreien Tausch. [5] [6]

Wiederherstellungswörter einer anderen Wallet stellen einen laufenden Swap möglicherweise nicht wieder her. Je nach Anwendung braucht es einen refund-Schlüssel oder rescue key und die Daten dieses Swaps, einschließlich gesperrtem Output und Frist. Boltz Swap Restore leitet aus der eigenen Sicherung Schlüssel ab und findet zugehörige Swaps. Dazu nutzt es einen xpub, einen erweiterten öffentlichen Schlüssel: Er kann die Historie offenlegen, aber nicht selbst signieren oder Geld ausgeben. Ein privater Schlüssel ist ein geheimer Wert, mit dem die App eine Transaktion unter den jeweiligen Bedingungen signiert. Diese Schlüssel bleiben auf dem Gerät. Was die Sicherung wiederherstellt und wo sie liegt, sollte vor dem Senden klar sein. [7] [3]

Nutzer sollen kryptografische Bedingungen nicht von Hand berechnen müssen. Ihre Anwendung muss sie jedoch prüfen. Einer Adresse aus einer API, der Schnittstelle für den Datenaustausch zwischen Programmen, einfach zu vertrauen genügt nicht. Der Client kontrolliert Netzwerk, Beträge und Gebühren, Hash, Schlüssel und Fristen. Ebenso müssen das Skript mit den Ausgaberegeln oder der entsprechende Regelbaum in Taproot sowie die daraus abgeleitete Adresse stimmen. Die Lightning-Rechnung muss zum vereinbarten Fingerabdruck und Betrag passen. Ein gutes Verfahren hilft nicht, wenn die Software an die falsche Stelle zahlt. [2]

Mit Taproot können beide Seiten über MuSig2 gemeinsam signieren. Dieser key-path-Weg kann günstiger sein und muss die Swap-Bedingungen nicht öffentlich zeigen. Die Anwendung braucht außerdem den script-path-Weg, der die Bedingungen direkt nutzt, falls die Gegenseite nicht mitarbeitet: je nach Richtung für claim oder refund. Scheitert ein normaler Swap, kann ein gemeinsam signierter refund das Geld früher zurückbringen. Ohne Mitarbeit des Dienstes muss Anna dagegen warten, bis der vereinbarte timelock die Rückzahlung erlaubt. Weniger öffentliche Blockchain-Daten bedeuten außerdem keine Anonymität gegenüber dem vermittelnden Dienst. [3] [4]