Submarine Swap

Anna trzyma bitcoiny w zwykłym portfelu, a sklep wystawia jej fakturę Lightning, czyli żądanie płatności. Zwykły swap pozwala zablokować bitcoiny w blockchainie na uzgodnionych warunkach, a usługa w zamian opłaca fakturę. Aby przenieść saldo Lightning na adres w blockchainie, Anna potrzebuje odwrotnego kierunku: Reverse Submarine Swap, na przykład Loop Out. Nie musi zamykać swoich kanałów płatniczych. Wymiana nie tworzy pieniędzy, a płatność Lightning nadal potrzebuje dostępnej trasy. [1] [4]

Wyobraźmy sobie sekret, którego cyfrowy odcisk da się sprawdzić, choć praktycznie nie można odtworzyć sekretu z odcisku. Tajna wartość nazywa się preimage. Jej cyfrowy odcisk to hash, obliczany za pomocą SHA256. Warunkowe płatności HTLC łączą odcisk z terminem. W odwrotnym swapie sekret tworzy aplikacja Anny. Usługa utrzymuje jej płatność Lightning w oczekiwaniu i blokuje odpowiednie bitcoiny w blockchainie. Odbierając je w operacji claim, Anna ujawnia sekret w blockchainie albo przekazuje go usłudze podczas wspólnego rozliczenia. Wtedy usługa może zakończyć powiązaną płatność. Oczekująca nie znaczy opłacona. [1] [4]

Komunikat usługi nie jest tym samym co środki w docelowym portfelu. Boltz podaje, że invoice.settled przy odwrotnym swapie może pojawić się po przekazaniu preimage i rozliczeniu faktury Lightning. Usługa nie śledzi, czy aplikacja Anny rzeczywiście rozgłosiła transakcję claim. Trzeba więc sprawdzić wyjście docelowe, konkretną część bitcoinów przypisaną jej portfelowi, oraz potrzebne potwierdzenia w blokach. Blok to grupa transakcji dodana do blockchaina. Umieszczenie transakcji w bloku daje jej pierwsze potwierdzenie; każdy kolejny blok dodaje następne. Niejasny status nie uzasadnia natychmiastowego ponowienia tej samej płatności. [1] [2]

W zwykłym swapie bitcoiny Anny mogą już być zablokowane w blockchainie, choć faktura nie jest opłacona. Zwrot, refund, wymaga wtedy transakcji przygotowanej i rozgłoszonej przez jej aplikację. Bez współpracy usługi trzeba poczekać na timelock, uzgodniony warunek czasowy. W drugą stronę nierozliczona płatność Lightning może zostać anulowana przez usunięcie oczekujących HTLC, uwalniając saldo bez transakcji refund Anny w blockchainie. Nie oznacza to jednak, że rozliczona płatność wróci sama po ujawnieniu preimage. Liczą się kierunek i etap. [1] [3]

Anna porównuje to, co wysyła, z tym, co rzeczywiście dociera. Różnicę mogą stanowić opłaty usługi, routingu Lightning i transakcji w blockchainie. Nieudany zwykły swap może dodać opłatę za zwrot. Znaczenie ma też czas: publikacja claim może ujawnić preimage przed potwierdzeniem w bloku. Dokumentacja Loop ostrzega, że przed timeout klient może podnieść ponad pierwotny limit opłatę za sweep, transakcję odbierającą środki. Kryptograficzne powiązanie nie obiecuje więc wymiany natychmiastowej, darmowej ani pozbawionej ryzyka. [5] [6]

Słowa odzyskiwania innego portfela mogą nie odtworzyć rozpoczętego swapu. Zależnie od aplikacji potrzebny jest klucz refund lub rescue key i dane konkretnej wymiany, w tym zablokowane wyjście oraz termin. Boltz Swap Restore wyprowadza klucze z własnej kopii i odnajduje powiązane swapy. Wyszukuje je za pomocą xpub, rozszerzonego klucza publicznego: może on ujawnić historię, lecz sam nie podpisuje ani nie wydaje pieniędzy. Klucz prywatny to tajna wartość, której aplikacja używa do podpisania transakcji zgodnie z odpowiednimi warunkami. Te klucze pozostają na urządzeniu. Przed wysłaniem trzeba wiedzieć, co odtwarza kopia i gdzie jest przechowywana. [7] [3]

Użytkownik nie powinien ręcznie obliczać warunków kryptograficznych, ale jego aplikacja musi je zweryfikować. Nie wystarczy zaufać adresowi zwróconemu przez API, interfejs wymiany danych między programami. Klient sprawdza sieć, kwoty i opłaty, hash, klucze oraz terminy. Musi też zweryfikować skrypt, czyli zasady wydawania środków, lub ich drzewo w Taproot, oraz wynikający z nich adres. Faktura Lightning musi pasować do uzgodnionego odcisku i kwoty. Poprawny mechanizm nie naprawi programu wysyłającego pieniądze gdzie indziej. [2]

Taproot pozwala obu stronom użyć MuSig2 do utworzenia wspólnego podpisu. Taka droga key-path może być tańsza i nie musi publicznie ujawniać warunków swapu. Aplikacja potrzebuje też drogi script-path, bezpośrednio korzystającej z tych warunków, jeśli partner nie współpracuje: dla claim albo refund, zależnie od kierunku. Jeśli zwykły swap się nie powiedzie, refund podpisany przez obie strony może zwrócić środki wcześniej. Aby odzyskać je bez współpracy usługi, Anna musi jednak poczekać, aż uzgodniony timelock pozwoli na zwrot. Mniej danych w blockchainie nie daje też anonimowości wobec pośredniczącej usługi. [3] [4]