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

I discovered the right way to flip round these steps for the ‘reverse’ case.

Within the ahead case, the Lightning bill doesn’t must be generated by the Payer, however may be by a 3rd occasion, as described within the query. Whether it is generated by the Payer, and there are solely two events concerned, then that case may be ‘turned’ round for the reverse, LN->BTC case, with very related vault utilization.

First I re-describe the ahead case, by way of two events, after which I describe the trustless answer for the reverse case. Notice that I name the swapper actor Consumer (as a substitute of Payer).

Ahead case (BTC->LN):

• Actors: Consumer, who needs to swap onchain BTC to Lightning BTC, and Supplier of the swap service

Steps:

1. Consumer creates a Lightning bill it needs to be paid, with desired quantity.
2. Consumer initiates a request to the Supplier, with the small print of the bill (quantity, cost hash, timeouts, and so on.) and its personal pubkey.
3. Supplier units up a ‘vault’ BTC handle, managed by a script, permitting to be spent by somebody who can show that the LN bill has been paid (regular department), or by the Consumer after a while (timeout refund department). Supplier communicates the vault handle, the script and the BTC quantity it expects to Consumer.
4. Consumer verifies the script: that it has the correct quantity, and it has a timeout department with its personal pubkey.
5. Consumer performs the on-chain BTC cost to the vault handle.
6. Supplier observes the cost, waits for affirmation, verifies it.
7. Supplier pays the LN bill (from its LN funds).
8. As soon as the bill is paid, Supplier transfers the BTC from the vault to an handle of its personal management.

Finish consequence: LN bill is paid, Consumer has much less BTC and extra LN-BTC, Supplier has much less LN-BTC however extra BTC.

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

Reverse case (LN->BTC):

Actors: Consumer, who needs to swap Lightning BTC to onchain BTC, and Supplier of the swap service.

Steps:

1. Consumer initiates a request to the Supplier, with the specified quantity.
2. Supplier creates a Lightning bill.
3. Supplier units up a ‘vault’ BTC handle, managed by a script, permitting to be spent by somebody who can show that the LN bill has been paid (regular department), or by itself after a while (timeout refund department).
4. Supplier makes BTC cost to the vault handle.
5. Supplier communicates the lightning bill to Consumer (with out the cost secret, in fact), the vault handle and script.
6. Consumer verifies the vault, that it has payout department secured by the cost hash of the bill.
7. Consumer verifies that the vault has the correct quantity of BTC, waits for affirmation if wanted.
8. Consumer pays the Lighting bill.
9. Now within the possession of the cost secret, Consumer transfers the BTC from the vault to itself.

Finish consequence: LN bill is paid, Consumer has much less LN-BTC and extra BTC, Supplier has much less BTC however extra LN-BTC.

Some notes:

• In each circumstances it’s the Supplier who units up the vault.
• I didn’t develop on the fallback case (ahead case: the shopper can recuperate its BTC if Supplier fails to meet; reverse case: Supplier can recuperate its BTC if Consumer fails to pay).
• The Supplier can add some further service charge, the Consumer is conscious of the elevated quantity earlier than paying, however this must be agreed/communicated earlier than.
• Within the ahead case the Lightning bill may be created upfront by a 3rd occasion, and the Consumer can organize that bill to be paid instantly, e.g. when eager to pay for an bill of an internet service provider (this use case variant is within the unique query). Within the reverse case this isn’t potential (to pay BTC on to the third occasion), because the BTC recipient should do a particular operation (transferring the BTC from the vault handle).