Submarine Swap

Анна тримає біткоїн у звичайному гаманці, а крамниця виставляє їй Lightning-рахунок, тобто запит на оплату. Звичайний swap дозволяє заблокувати біткоїн у блокчейні за узгодженими умовами, а сервіс натомість сплачує рахунок. Щоб перевести залишок Lightning на адресу в блокчейні, потрібен зворотний напрямок: Reverse Submarine Swap, наприклад Loop Out. Закривати свої платіжні канали Анні не потрібно. Обмін не створює грошей, а для Lightning-платежу все одно потрібен доступний маршрут. [1] [4]

Уявімо секрет, цифровий відбиток якого можна перевірити, хоча практично відновити секрет із відбитка неможливо. Секретне значення називається preimage. Його цифровий відбиток — це hash, або хеш, який обчислюють за допомогою SHA256. Умовні платежі HTLC поєднують цей відбиток зі строком. У зворотному swap секрет створює застосунок Анни. Сервіс тримає її Lightning-платіж в очікуванні та блокує відповідний біткоїн у блокчейні. Забираючи кошти операцією claim, Анна розкриває секрет у блокчейні або передає його сервісу під час спільного завершення. Тоді сервіс може виконати пов’язаний платіж. Очікування ще не означає оплату. [1] [4]

Повідомлення сервісу — не те саме, що кошти в кінцевому гаманці. Boltz пояснює: invoice.settled у зворотному swap може з’явитися після передавання preimage та остаточного розрахунку за Lightning-рахунком. Сервіс не відстежує, чи застосунок Анни справді поширив транзакцію claim. Тому треба перевірити цільовий вихід, конкретну частину біткоїнів, призначену її гаманцю, та потрібні підтвердження в блоках. Блок — група транзакцій, додана до блокчейну. Включення транзакції до блоку дає їй перше підтвердження, а кожен наступний блок додає ще одне. Незрозумілий статус — не причина негайно повторювати той самий платіж. [1] [2]

У звичайному swap біткоїн Анни вже може бути заблокований у блокчейні, хоча рахунок не сплачено. Повернення, refund, тоді потребує транзакції, яку її застосунок готує та поширює. Без співпраці сервісу треба дочекатися timelock, узгодженої часової умови. У зворотному напрямку, доки Lightning-платіж не завершено, очікувані HTLC можуть бути скасовані. Тоді кошти вивільняються без Анниної refund-транзакції в блокчейні. Але вже виконаний платіж не повертається сам після розкриття preimage. Важливі напрямок і поточний етап. [1] [3]

Анна порівнює надіслану суму з тією, що справді надійшла. Різницю можуть утворити комісії сервісу, маршрутизації Lightning і транзакцій у блокчейні. Невдалий звичайний swap може додати комісію повернення. Має значення й час: опублікований claim здатен розкрити preimage до підтвердження блоком. Документація Loop попереджає, що перед timeout клієнт може підвищити понад початковий ліміт комісію sweep, транзакції забирання коштів. Криптографічний зв’язок не обіцяє миттєвого, безплатного чи безризикового обміну. [5] [6]

Слова відновлення іншого гаманця можуть не відновити незавершений swap. Залежно від застосунку потрібні refund-ключ або rescue key та дані обміну, зокрема заблокований вихід і строк. Boltz Swap Restore виводить ключі з власної резервної копії та знаходить відповідні swap. Для пошуку використовується xpub, розширений публічний ключ: він може розкрити історію, але сам не підписує й не витрачає кошти. Приватний ключ — секретне значення, за допомогою якого застосунок підписує транзакцію згідно з відповідними умовами. Ці ключі залишаються на пристрої. Що саме відновлює копія і де вона зберігається, має бути зрозуміло до переказу. [7] [3]

Користувач не має вручну обчислювати криптографічні умови, але його застосунок мусить їх перевірити. Просто довіритися адресі з API, інтерфейсу обміну даними між програмами, недостатньо. Клієнт перевіряє мережу, суми й комісії, hash, ключі та строки. Мають відповідати також скрипт, правила витрачання, або їхнє дерево в Taproot і виведена з них адреса. Lightning-рахунок повинен збігатися з узгодженим відбитком і сумою. Правильний механізм не врятує програму, яка надсилає кошти не туди. [2]

Taproot дає змогу сторонам через MuSig2 створити спільний підпис. Цей шлях key-path може коштувати менше й не потребує публічного розкриття умов swap. Застосунку потрібен також script-path, що безпосередньо застосовує ці умови, коли партнер не співпрацює: для claim або refund залежно від напрямку. Якщо звичайний swap не вдався, спільно підписаний refund може повернути кошти раніше. Але щоб забрати їх без співпраці сервісу, Анна має дочекатися моменту, коли узгоджений timelock дозволить повернення. Менше даних у блокчейні також не означає анонімності перед сервісом, який організував обмін. [3] [4]