Submarine exchange between multiple parties

Author: conduition

Source: https://conduition.io/scriptless/multi-party-submarine-swaps/

" Submarine swaps " allow users on the Lightning Network to trustlessly swap in-chain UTXOs for balances in Lightning channels. It's essentially an atomic swap for the Lightning Network and is extremely useful for Lightning node operators (for rebalancing their channels, among other things).

As submarine swaps become increasingly important and common, it may be time to look at how to better scale submarine swap throughput – now that more peer nodes and liquidity providers can participate in swaps.

review

Traditional submarine swaps are atomic swaps between two parties, using two Hash Time Locked Contracts (HTLCs): one deployed on the Bitcoin chain and the other deployed on the Lightning Network.

Suppose Alice wants to sell her on-chain Bitcoin in exchange for a Lightning payment; and Bob wants to use his Lightning Channel balance to buy Alice's on-chain funds.

First, Alice needs to generate a random secret value $s$ that only she knows.

Alice and Bob construct a 2-of-2 managed address: if Bob knows $s$, he will have full spending rights to this address, expressed using a hash lock condition; furthermore, after the network reaches a certain block height $B$, Alice will gain full spending rights to this address.

This is an example expressed using descriptors:

 tr( musig(<alice_pubkey>, <bob_pubkey>), { and(sha256(<hash>), pk(<bob_pubkey>)), and(after(<B>), pk(<alice_pubkey>)) })

Alice deposits her coins into this 2-of-2 escrow contract, confident that she can retrieve her funds after block height $B$, and that Bob cannot currently withdraw the money because only she knows $s$.

Then, Alice gives Bob a lightning invoice, demanding a payment equal to the face value of the currency, using $SHA256(s)$ as the payment hash. Bob can pay this invoice, but (through the time lock of the HTLC) requires Alice to release the preimage (claim the payment) no later than block height $B - \Delta$, where $\Delta$ is the reasonable time delay. If Alice claims Bob's lightning payment HTLC (whether by negotiating with her channel counterpart to release the preimage off-chain and claim the funds, or by forcibly closing the channel and Alice exposing the preimage on-chain to claim the funds), Bob will know Alice's secret value preimage $s$, and then he can transfer the funds in the aforementioned escrow contract. If Alice is cunning and only claims the payment at the last minute, that is, at block height $B - \Delta$, Bob will also have $\Delta$ blocks to know $s$ and use it to claim Alice's HTLC in the chain (i.e., the contract mentioned above).

That's it! Bob and Alice can swap coins on and off-chain without either of them having the opportunity to cheat the other. To improve privacy and efficiency, Alice and Bob can collaborate: once Bob pays the Lightning Invoice, they use MuSig to jointly sign the transaction for spending the aforementioned contract and transfer the funds to Bob (so that outsiders cannot tell that this is an HTLC/Submarine swap transaction).

efficiency

Some submarine swap providers, such as Lightning Labs' Loop service , process their on-chain transactions in batches. When sweeping up the on-chain coins they receive, sweeping multiple contracts at once allows for better aggregation of large amounts of funds into a smaller number of UTXOs. This can also be done when funding escrow contract addresses for submarine swaps, with each output funding a separate submarine swap contract.

However, there is still an efficiency bottleneck stemming from the submarine swap protocol's own topology. We have many small nodes (users), all interacting with a single submarine swap service provider (such as Loop or Boltz). Users are completely unaware of each other's transactions, so each submarine swap is a completely independent contract between a single user and a swap service provider. This leads to waste.

Each submarine swap, from on-chain currency to off-chain payment, requires the user to initiate a separate funding transaction. Because users are unaware of each other, they cannot batch process their master-slave transactions together. Furthermore, each submarine swap creates a separate funding transaction output. Therefore, even if funding transactions are batched (similar to the off-chain to on-chain protocol in Loop), we still have $n$ individual HTLC addresses with injected funds, potentially requiring $n$ additional transactions to resolve.

Expansion

We can improve efficiency by transforming submarine swaps from a single-taker protocol to an $n$-taker protocol. Instead of assuming one maker and one taker in each swap, we assume one maker and $n$ takers capable of authenticated communication, whether through peer-to-peer or a proxy (such as the maker). These participants will aggregate their $n$ submarine swap contracts into a single injected UTXO to execute a trustless, atomic swap.

This increases the complexity and fragmentation of the protocol, but it also greatly improves on-chain efficiency. Let's see how this is achieved.

Eater who swaps between on-chain and off-chain

Let's first look at the scenario where $n$ eaters participate in the exchange of funds from on-chain to off-chain. In this case, the two sides of the transaction are:

• Single-eaters : A group of $n$ single-eaters who want to exchange small amounts of on-chain UTXOs for off-chain Lightning Channel balances.
• Order holder : A single individual or enterprise that wishes to convert their Lightning Balance into on-chain funds.

Unlike traditional submarine swaps where participants contribute to $n$ separate on-chain escrow addresses, this transaction involves collectively contributing to a single escrow contract, with funds transferred in a single transaction. This escrow contract is either spent by the order placer (if the contract executes successfully) or returned to the participants (if the contract does not execute successfully).

1. The person who places the order generates $n$ random secret values ${s_1, s_2, …, s_n}$ (one for each person who takes the order).
2. The order taker and the order placer work together to create an n-of-n taproot hash lock address. If the order placer can reveal ${s_1, s_2, …, s_n}$, they can transfer funds from this address.

The following is an example of a triple hash lock represented by a descriptor:

 tr( musig( <taker1_pubkey>, <taker2_pubkey>, <taker3_pubkey>, <maker_pubkey> ), and( hash160(<hash1>), hash160(<hash2>), hash160(<hash3>), pk(<maker_pubkey>) ))

Using the taproot script, we can use a 4-of-4 internal public key (via the aggregation public key protocol), thus completely hiding the bulky hash lock with the cooperation of all parties. We use hash160 instead of SHA256 to save block space while retaining the option to use HTLC with the same secret value (preimage) in the Lightning Network.

1. The participants construct a funding transaction , paying everyone's UTXOs to the aforementioned multi-signature address (there may be change output). The participants do not sign the funding transaction at this time.
2. The participants construct a timeout transaction , which is essentially a refund transaction. This timeout transaction returns the funds from the injection transaction output to each participant. The timeout transaction must include an absolute time lock with an unlock time of block height $B$.
3. Both the order taker and the order placer sign off on the timeout transaction . The order placer naturally has no objection because it has an absolute time lock.
4. The person who placed the order creates $n$ Lightning Network HTLCs, each HTLC paying a corresponding swap amount to one of the order takers. The HTLC for order taker $i$ uses $SHA256(s_i)$ as the payment hash. The swap amounts for each order taker may be different. Order takers cannot yet claim these HTLCs because only the person who placed the order knows the preimage ${s_1, s_2, …, s_n}$ of each HTLC. The absolute time lock of these HTLCs must be at least $B + \Delta$, where $\Delta$ is a reasonable latency (in blocks).
5. After all the order takers received HTLC in their respective channels, they signed together and posted the investment transaction .
6. Everyone is waiting for the investment transaction to be confirmed by the blockchain.

The person placing the order has three options.

1. (In-chain) Enforcement

The order placer can use the preimage ${s_1, s_2, …, s_n}$ to claim the funding transaction output in the hash lock spending path. Such a claim transaction will reveal all preimages in the network, so that order takers can use these preimages to claim the funds they have received in their HTLCs.

Even if the order placer delays posting the transaction to claim the funds until the last minute, the order takers still have a $\Delta$ block time window to claim the funds in their respective channels' HTLCs.

2. (Off-chain) cooperation

The order placer can assign each element in ${s_1, s_2, …, s_n}$ to the corresponding order taker. The order taker can use these preimages to claim HTLC in their channel. In exchange, the order takers should cooperate with the order placer to sign a transaction, thereby releasing the funds in the injection transaction output to the order placer.

Even if someone exchanges the original image for HTLC and then refuses to hand over the signature, the person who placed the order can still enforce the transaction and take away the funds from the investment transaction output within the chain.

Please note that it is irrational for the order placer to only hand over a portion of the preimage (instead of the entire preimage), because in essence, each preimage represents the right to receive some funds from the order placer. If the order placer wants to withdraw funds on the blockchain, they must reveal the entire preimage, not just a portion.

3. Timeout

The order placer can choose not to reveal any preimage. Therefore, order takers will not be able to claim the HTLCs in their respective channels. When the network reaches block height $B$, any order taker can post a timeout transaction , allowing funds to be returned to all order takers. After another $Delta$ blocks, the HTLCs in their respective channels will also expire.

performance

If we use $n$ traditional submarine swaps, the minimum footprint within the chain will be:

• There are $n$ distinct investment transactions, each containing at least one input and one output.
• Given $n$ distinct inputs, withdraw funds from each escrow address (perhaps this could be batched into a single transaction).

Ideally, our multi-swap method here can reduce the in-chain footprint of ($n$ swaps) to:

• An investment transaction will have at least $n$ inputs and at least 1 output (there may be more, as there are change outputs).
• One input, and the output of the investment receipt transaction (perhaps this can be batch processed with other investment receipt transactions).

It's worth noting that if $n$ is large, some order takers may not cooperate. In order to claim the funding transaction output on-chain, the order placer might need to publish a large number of RMD160 hashes and a huge script in the transaction's witness output. This could affect performance analysis and the choice of $n$.

Off-chain to on-chain swapping of single-users

Now, let's see how our method works in the opposite situation.

At this point, the two roles involved in the transaction are:

• Single participants : Multiple small participants who want to exchange the balance in the Lightning Channel for a small amount of on-chain UTXO.
• Order holder : A single individual or enterprise that wants to exchange a large amount of on-chain UTXO for a balance in the Lightning Channel.

At this point, instead of generating $n$ separate on-chain escrow addresses as in traditional submarine swaps, the order placer injects funds into a single escrow address, which is expected to be spent in a single transaction—either by sending funds to the takers (if the swap goes smoothly) or by returning them to the order placer (if the swap does not go smoothly).

1. The person who places the order generates $n$ random secret values ${s_1, s_2, …, s_n}$ (one for each person who takes the order).
2. The order taker and the order holder jointly create a 1-of-n taproot hash lock address.

Here is a case where the number of people eating a single dish is 3, represented by a descriptor:

 taker_joint_pubkey = musig( <taker1_pubkey>, <taker2_pubkey>, <taker3_pubkey>);tr( musig( <taker1_pubkey>, <taker2_pubkey>, <taker3_pubkey>, <maker_pubkey> ), { { and( hash160(<hash1>), pk(taker_joint_pubkey) ), and( hash160(<hash2>), pk(taker_joint_pubkey) ) }, and( hash160(<hash3>), pk(taker_joint_pubkey) ) })

Note that in this script, the "eater" is a joint recipient of funds from three different hash lock spending conditions. That is, any one of the three preimages, <hash1> , <hash2> , and <hash3> , can be used by the eater to collect funds from them.

1. The order placer constructs a funding transaction that consumes the order placer's UTXO and pays the amount to the aforementioned taproot address (the transaction may include a decree output). The order placer does not sign the funding transaction at this time.
2. The order holder constructs a timeout transaction that consumes the output of the funding transaction and returns the funds to the order holder. It includes an absolute time lock with an unlock time of block height $B$.
3. The order taker and the order placer both sign off on the timeout transaction . The order taker agrees to accept it because the timeout transaction has an absolute time lock.
4. The participants collaboratively construct $n$ claim transactions . Each claim transaction uses a different hash lock spending branch from the funding transaction to spend the funds and divide them among the participants. The participants collaboratively sign all $n$ claim transactions ; none are made public until one of ${s_1, s_2, …, s_n}$ is revealed. Participants are willing to sign these transactions because they do not embezzle their own funds. Each participant $i$ must obtain a fully signed claim transaction corresponding to their own hash value $RMD160(SHA256(s_i))$, thus enabling them to publish a claim transaction once they know $s_i$.
5. The person placing the order signs and broadcasts the investment transaction .
6. Everyone is waiting for the investment transaction to be confirmed by the blockchain.
7. Eaters create $n$ HTLCs and pay the order holders via the Lightning Network, paying the amount for the swap and using their corresponding $SHA256(s_i)$ as the payment hash. Eaters may use different amounts. The timeout for each HTLC can be at most $B - \Delta$, where $\Delta$ is the reasonable time delay (in blocks). The order holder must wait until all HTLCs have been delivered before settling any of them.
8. The order placer can use the preimage ${s_1, s_2, …, s_n}$ to settle any HTLC (or settle all of them). That is, any order taker will receive at least one preimage $s_i$. Note that a rational order placer will either claim all HTLCs or none . This is because revealing even one $s_i$ will allow order takers to withdraw funds from the investment transaction's output.

1. (In-chain) Enforcement

Any taker $i$, after knowing the preimage $s_i$, can publish a claim transaction (which has been previously signed by all takers). This atomic transaction will fairly distribute the funds of the order placer among the takers.

Even if the order placer wants to wait until the last moment before the HTLC (which is essentially from the order takers) in their Lightning Channel times out before revealing all the preimages ${s_1, s_2, …, s_n}$, meaning in the worst case, the order takers will still have a $\Delta$ block time window to publish and confirm a claim transaction .

2. (Off-chain) cooperation

Once the order placer has claimed all the HTLCs within their Lightning Channel—that is, all the preimages ${s_1, s_2, …, s_n}$ are exposed—the order placer can collaborate with the order takers to sign a new version of the claim transaction, using the 4-of-4 internal public key. This allows them to hide the hash lock spending branch in the contract, improving privacy and on-chain efficiency.

If someone does not sign this new version of the claim transaction, a taker can go back to publishing their own claim transaction , as long as it is before block height $B$ (before the timed-out transaction becomes a valid transaction).

time out

If the order placer does nothing (does not release the preimage), the HTLC from the order taker will expire at block height $B - \Delta$, thus returning the Lightning Channel balance to the order taker. Then, at block height $B$, the order placer can use a timeout transaction to clean up the funding transaction output.

If the order taker does not respond after the order placer publishes the investment transaction , the order placer does not need to do anything, but only waits for block height $B$ and then publishes the timed-out transaction.

performance

If we use $n$ traditional submarine swaps, the minimum footprint within the chain will be:

• $n$ distinct escrow outputs (which could perhaps be batched into a single investment transaction).
• $n$ distinct transactions are used to claim the above escrow output, each transaction containing at least one input and one output (cannot be processed in batches).

Ideally, our multi-swap method here can reduce the in-chain footprint of ($n$ swaps) to:

• One escrow output (which may be batched into a larger funding transaction).
• A take-out transaction with 1 input and $n$ outputs (allocating funds among the takers).

In cases where some order takers or order placers are uncooperative, the order takers need to use one of the hash lock branches to claim the funds in the chain.

Reduce harassment

While it is clearly possible to expand submarine swaps into multi-party agreements, the specific efficiency gains that could be achieved are debatable, as this largely depends on the cooperation of the parties involved. This is especially true for swaps from on-chain to off-chain, where a single non-cooperative order taker can force an order placer to pay additional fees (by publishing a series of seemingly unnecessary hashes and preimages) to claim the funds.

The same harassment attacks exist in traditional submarine swap agreements, but they have a greater impact in multi-party environments because one bad apple spoils the whole bunch (making the swap more expensive for everyone).

To curb the disruptive behavior of those who try to steal orders, those who place orders can employ the following techniques:

• Transaction fees. Order placers can include a transaction fee in the Lightning Invoice amount, requiring takers to pay it (in swaps from off-chain to on-chain); or, they can reduce the amount paid to takers in HTLCs (in swaps from on-chain to off-chain). This will incentivize order placers to provide swap services and make harassment attacks more expensive.
• Pre-deposit system. The order placer can force the order taker to pre-deposit a small percentage of the swap amount in HTLCs as a deposit (using a "HODL invoice"). If the order taker approves the swap during the process, the order placer can cancel the invoice and return the deposit. If the order taker does not cooperate, the order placer can settle the invoice and withdraw the deposit as a penalty. This deposit is not trustless—the order placer can withdraw it unconditionally; therefore, a certain degree of trust, responsibility, and reputation is required.
• An anonymous token. A person who takes a bid can purchase some ecash tokens from the person who places the bid, and later exchange them for the right to participate in a multi-party submarine swap with the person who placed the bid.
• Loyalty Bonds. This will allow anonymous order placers or takers to exchange some Bitcoin for a permanent order placer/taker identity, proving their honest participation in trading.

For the work

• Point-in-Time Locked Contracts (PTLCs) on the Lightning Network will allow for significant improvements in on-chain privacy and efficiency in multi-party submarine swaps in both directions. So, what will PTLC-based multi-party submarine swaps look like? And how much efficiency improvement will they actually provide?
• Is it possible to execute an n-to-m submarine swap, where $n$ sellers of in-chain UTXOs trade with $m$ buyers who purchase them via Lightning Payment?

(over)