Trustless Lightning-to-Bitcoin Swap? – Bitcoin Stack Exchange

I found out how to turn around these steps for the ‘reverse’ case.

In the forward case, the Lightning invoice does not have to be generated by the Payer, but can be by a third party, as described in the question. If it is generated by the Payer, and there are only two parties involved, then that case can be ‘turned’ around for the reverse, LN->BTC case, with very similar vault usage.

First I re-describe the forward case, in terms of two parties, and then I describe the trustless solution for the reverse case. Note that I call the swapper actor Client (instead of Payer).

Forward case (BTC->LN):

• Actors: Client, who wants to swap onchain BTC to Lightning BTC, and Provider of the swap service

Steps:

1. Client creates a Lightning invoice it wishes to be paid, with desired amount.
2. Client initiates a request to the Provider, with the details of the invoice (amount, payment hash, timeouts, etc.) and its own pubkey.
3. Provider sets up a ‘vault’ BTC address, controlled by a script, allowing to be spent by someone who can prove that the LN invoice has been paid (normal branch), or by the Client after some time (timeout refund branch). Provider communicates the vault address, the script and the BTC amount it expects to Client.
4. Client verifies the script: that it has the right amount, and it has a timeout branch with its own pubkey.
5. Client performs the on-chain BTC payment to the vault address.
6. Provider observes the payment, waits for confirmation, verifies it.
7. Provider pays the LN invoice (from its LN funds).
8. Once the invoice is paid, Provider transfers the BTC from the vault to an address of its own control.

End result: LN invoice is paid, Client has less BTC and more LN-BTC, Provider has less LN-BTC but more BTC.

Here is the detailed description of the reverse, LN->BTC case:

Reverse case (LN->BTC):

Actors: Client, who wants to swap Lightning BTC to onchain BTC, and Provider of the swap service.

Steps:

1. Client initiates a request to the Provider, with the desired amount.
2. Provider creates a Lightning invoice.
3. Provider sets up a ‘vault’ BTC address, controlled by a script, allowing to be spent by someone who can prove that the LN invoice has been paid (normal branch), or by itself after some time (timeout refund branch).
4. Provider makes BTC payment to the vault address.
5. Provider communicates the lightning invoice to Client (without the payment secret, of course), the vault address and script.
6. Client verifies the vault, that it has payout branch secured by the payment hash of the invoice.
7. Client verifies that the vault has the right amount of BTC, waits for confirmation if needed.
8. Client pays the Lighting invoice.
9. Now in the possession of the payment secret, Client transfers the BTC from the vault to itself.

End result: LN invoice is paid, Client has less LN-BTC and more BTC, Provider has less BTC but more LN-BTC.

Some notes:

• In both cases it is the Provider who sets up the vault.
• I did not expand on the fallback case (forward case: the client can recover its BTC if Provider fails to fulfill; reverse case: Provider can recover its BTC if Client fails to pay).
• The Provider can add some extra service fee, the Client is aware of the increased amount before paying, but this should be agreed/communicated before.
• In the forward case the Lightning invoice can be created upfront by a third party, and the Client can arrange that invoice to be paid directly, e.g. when wanting to pay for an invoice of an online merchant (this use case variant is in the original question). In the reverse case this is not possible (to pay BTC directly to the 3rd party), as the BTC recipient must do a special operation (transferring the BTC from the vault address).