Submarine Swap

Beim normalen Swap sperrt der Nutzer On-Chain-Bitcoin, und der Dienst bezahlt seine Lightning-Rechnung. Beim Reverse Submarine Swap stellt er eine bedingte Lightning-Zahlung bereit und ruft einen On-Chain-Ausgang ab. Das ist nicht zwingend ein Tausch in eine andere Währung oder das bloße Schließen des eigenen Kanals. [Boltz — Swap types and states]

Ein zum SHA256-Hash passendes Preimage ermöglicht die Abwicklung der verknüpften Zahlung und den Abruf des gesperrten Ausgangs. Beim Reverse-Verfahren erzeugt der Client das Preimage, und der Dienst hält den Lightning-HTLC bis zur Offenlegung offen. Ein On-Chain-Claim kann das Geheimnis offenlegen; ein kooperativer Weg kann es dem Dienst außerhalb der Kette geben. Eine offene Zahlung ist noch keine endgültige Abwicklung. [Boltz — Swap types and states] [Lightning Loop — Architecture]

Vor der Finanzierung muss der Client Netzwerk, Beträge einschließlich Gebühren, Hash, Schlüssel, Frist und die Bindung von Skript oder Taproot-Baum an die Zieladresse prüfen. Die Rechnung muss vereinbartem Hash und Betrag entsprechen. Richtige Kryptografie hilft nicht, wenn die Anwendung ungeprüft eine beliebige API-Adresse bezahlt. [Boltz — Client verification]

Taproot-Swaps können eine MuSig2-Key-Path-Signatur beider Seiten nutzen, um Platz zu sparen und das Skript zu verbergen. Kooperiert die Gegenseite nicht, muss der Client den jeweiligen Script-Path-Claim oder Refund unterstützen. Schnelle kooperative Erstattung ergänzt eine Möglichkeit; sie hebt die Zeitbedingung einseitiger Wiederherstellung nicht auf. [Boltz — Claims and refunds] [Lightning Loop — Architecture]

Bei einem gescheiterten normalen Swap mit bereits gesperrten On-Chain-Mitteln erstellt und sendet der Client aktiv eine Refund-Transaktion; der einseitige Weg wartet auf den Timelock. Bei einer nicht abgewickelten Reverse-Lightning-Zahlung kann der HTLC aufgehoben und Geld ohne solche Nutzertransaktion freigegeben werden. Nach Preimage-Offenlegung darf man jedoch keine automatische Rückkehr einer schon abgewickelten Zahlung erwarten. [Boltz — Swap types and states] [Boltz — Claims and refunds]

Ein Swap verursacht Dienst-, Routing- und On-Chain-Kosten; ein gescheiterter normaler Swap kann eine Refund-Gebühr hinzufügen. Das Preimage vor Claim-Bestätigung offenzulegen erzeugt einen Wettlauf mit der Frist. Loop dokumentiert ausdrücklich, dass die Sweep-Gebühr nahe dem Timeout über das ursprüngliche Limit steigen kann. Eine Schätzung begrenzt daher nicht bedingungslos jedes Risiko. [Lightning Loop — Fees] [Lightning Loop — Sweep fee limits]

Bewahren Sie Refund-Schlüssel oder Rescue Key und Swap-Daten gemäß dem verwendeten Client auf; ein gewöhnlicher Seed einer anderen Wallet ist keine universelle Swap-Wiederherstellung. Boltz Restore leitet Schlüssel ab und sucht Swaps, doch ein xpub allein kann nicht signieren. Auch Skript, Ausgang und Timeout zählen, nicht nur die Dienstkennung. [Boltz — Swap restore] [Boltz — Claims and refunds]

Im Reverse-Verfahren von Boltz kann invoice.settled die Lightning-Abwicklung nach Preimage-Offenlegung bedeuten, während Boltz nicht verfolgt, ob der Client den Claim gesendet hat. Prüfen Sie Zielausgang und nötige Bestätigungen vor Abschlussmeldung oder erneuter Zahlung. Taproot-Key-Path reduziert die Sichtbarkeit des Skripts, nicht das Wissen des Anbieters über Beträge und Zeitabläufe. [Boltz — Swap types and states] [Boltz — Client verification]