Submarine Swap

Anna détient du bitcoin dans un portefeuille ordinaire. Un magasin lui remet pourtant une facture Lightning, une demande de paiement. Un swap normal lui permet de verrouiller du bitcoin sur la chaîne selon des conditions convenues ; le service paie la facture en contrepartie. Pour envoyer son solde Lightning vers une adresse sur la chaîne, elle utilise le sens inverse : un Reverse Submarine Swap, par exemple Loop Out. Elle n’a pas besoin de fermer ses canaux de paiement. L’échange ne crée pas d’argent et le paiement Lightning nécessite toujours un chemin disponible. [1] [4]

Imaginez un secret dont on puisse vérifier l’empreinte numérique, sans pouvoir en pratique retrouver le secret à partir de cette empreinte. La valeur secrète s’appelle preimage. Son empreinte numérique est un hash, calculé avec SHA256. Les paiements conditionnels HTLC associent cette empreinte à un délai. Dans un swap inverse, l’application d’Anna crée le secret. Le service garde son paiement Lightning en attente et verrouille le bitcoin correspondant sur la chaîne. Quand Anna le récupère par une opération claim, elle révèle le secret sur la chaîne ou le transmet au service en coopérant. Celui-ci peut alors régler le paiement lié. En attente ne veut pas dire payé. [1] [4]

Un message du service ne vaut pas la présence des fonds dans le portefeuille de destination. Boltz indique que, pour un swap inverse, invoice.settled peut suivre la transmission de la preimage et le règlement de la facture Lightning. Le service ne vérifie pas que l’application d’Anna diffuse effectivement la transaction claim. Il faut donc vérifier la sortie de destination, la part précise de bitcoin attribuée à son portefeuille, et les confirmations nécessaires dans les blocs. Un bloc est un groupe de transactions ajouté à la blockchain. L’inclusion d’une transaction dans un bloc lui donne sa première confirmation ; chaque bloc qui suit en ajoute une. Un statut ambigu ne justifie pas de renvoyer immédiatement le même paiement. [1] [2]

Dans un swap normal, le bitcoin d’Anna peut déjà être verrouillé sur la chaîne alors que la facture reste impayée. Le remboursement, refund, exige alors une transaction préparée et diffusée par son application. Sans coopération du service, il faut attendre le timelock, la condition temporelle convenue. Dans l’autre sens, un paiement Lightning non réglé peut voir ses HTLC en attente annulés et le solde libéré sans transaction refund d’Anna sur la chaîne. Cela ne signifie pas qu’un paiement déjà réglé reviendra seul après révélation de la preimage. Le sens et l’étape comptent. [1] [3]

Anna compare ce qu’elle envoie à ce qui arrive réellement. La différence peut inclure les frais du service, de routage Lightning et des transactions sur la chaîne. Un swap normal échoué peut ajouter des frais de remboursement. Le temps compte aussi : publier un claim peut révéler la preimage avant sa confirmation dans un bloc. La documentation Loop précise qu’à l’approche du timeout, le client peut augmenter au-delà de la limite initiale les frais du sweep, la transaction qui récupère les fonds. Le lien cryptographique ne promet donc pas un échange instantané, gratuit ou sans risque. [5] [6]

Les mots de récupération d’un autre portefeuille ne restaurent pas forcément un swap en cours. Selon l’application, il faut une clé refund ou rescue key et les données de l’échange, dont la sortie verrouillée et le délai. Boltz Swap Restore dérive les clés de sa propre sauvegarde et retrouve les swaps associés. Il recherche avec un xpub, une clé publique étendue : celui-ci peut révéler l’historique, mais ne permet ni de signer ni de dépenser à lui seul. Une clé privée est une valeur secrète utilisée par l’application pour signer une transaction selon les conditions prévues. Ces clés restent sur l’appareil. Ce que restaure la sauvegarde et où elle se trouve doit être clair avant l’envoi. [7] [3]

L’utilisateur ne devrait pas calculer à la main les conditions cryptographiques, mais son application doit les contrôler. Faire confiance à une adresse fournie par une API, l’interface d’échange de données entre programmes, ne suffit pas. Le client vérifie réseau, montants et frais, hash, clés et délais. Il doit aussi contrôler le script, les règles de dépense, ou leur arborescence dans Taproot, ainsi que l’adresse qui en découle. La facture Lightning doit correspondre à l’empreinte et au montant convenus. Un bon mécanisme ne sauve pas un programme qui envoie les fonds ailleurs. [2]

Avec Taproot, les deux parties peuvent produire une signature commune grâce à MuSig2. Cette voie key-path peut coûter moins cher et n’exige pas de rendre publiques les conditions du swap. L’application doit aussi disposer de la voie script-path, qui applique directement ces conditions si le partenaire ne coopère pas : pour un claim ou un refund selon le sens. Si un swap normal échoue, un refund signé par les deux parties peut rendre les fonds plus tôt. Mais pour les récupérer sans la coopération du service, Anna doit attendre que le timelock convenu autorise le remboursement. Moins de données visibles sur la chaîne ne signifie pas non plus anonymat vis-à-vis du service intermédiaire. [3] [4]