In this post, we'll explain how we used MuSig2, a protocol for aggregating public keys for the Schnorr digital signature algorithm, to enhance Lightning Loop, our non-custodial submarine swap service between on-chain bitcoin and the Lightning Network. Submarine swaps enable users to swap on-chain Bitcoin for off-chain Lightning Network Bitcoin (and vice versa) using hash time-locked contracts (HTLCs), ensuring atomicity and eliminating counterparty risk.

We are also excited to share a recent upgrade to the Loop In swap, which allows users to send on-chain bitcoin directly into a Lightning channel to replenish outbound, for Lightning Loop. The most recent Loop release allows Loop In users to fund a Loop In swap on-chain well in advance of the off-chain execution of the swap by leveraging MuSig2. From an end user perspective, this enhances the functionality of the Loop In flow by reducing the complexity of the user experience, allowing for the potential of locking in lower costs, and enabling swap retries.

Bringing MuSig2 to Loop  

Last year, we upgraded all Loop swaps to use MuSig2 signatures which reduced the cost of all swaps. MuSig2 is a multisignature scheme designed to make Bitcoin transactions more efficient, private, and secure. It allows multiple parties to collaborate on a single signature, making it indistinguishable from regular single-signer transactions on the blockchain. This reduces transaction size, lowers fees, and enhances privacy by hiding the number of participants. Compared to earlier multisig methods, MuSig2 is faster and eliminates the need for interactive communication in every step.

Further, we introduced Instant Loop Out, which enables users to instantly Loop Out without waiting for bitcoin block confirmations at the time of the swap. A Loop Out swap allows for users to replenish inbound in their Lightning channels by swapping Lightning funds in a channel for on-chain bitcoin. The Instant mode has allowed for pre-funding the swap into a non-HTLC parent and then the child HTLC is virtualized, so the swap timeout doesn't start ticking when we go to fund the exchange and we can pre-fund swaps well in advance of them being necessary. It's just like how a channel is intended to be confirmed well in advance of the user's intention to spend funds.

This change is part of our general MuSig2 and Taproot roadmap which seeks to fully leverage the advantages brought by the new capabilities. This roadmap started with simply upgrading to Schnorr signatures, which are shorter and therefore more chain efficient than legacy ECDSA. Due to Taproot's script design, however, they can actually cause more chain usage in some scenarios. So, we were aggressive about moving to MuSig2 which changes the dynamic from a script execution where the details of the swap are written to the chain to a cooperative key spend execution where we omit those details by aggregating the keys and producing a single compact signature and zero script on chain.

Lower Costs, More Developer Friendly UX

With the latest release including the new Loop In functionality, once the on-chain Loop In transaction is confirmed, end users can Loop In with no delay. This gives end users the ability to fund the address in a low fee environment to reduce the on-chain costs associated with a Loop In swap.

This is technically accomplished by changing the submarine swap from a 2-of-2 OR HTLC output into a 2-of-2 OR RELATIVE-TIMEOUT (which can solely be spent back to the user) output with a virtualized child transaction. The new relative timeout output is only spent into a virtual child transaction at swap time with the old HTLC output transaction, and even though that child transaction is used for the swap it can still be cooperatively replaced instead of going to the blockchain so that the on-chain size of the swap remains at the minimal level of just a single signature and no nested transactions.

Along the way, Loop In has been modernized with additional MuSig2 and Taproot features, allowing the service to retry or cancel the swap instead of having it only either succeed or fail. This eliminates the potential failure case where off-chain liquidity shifts faster than on-chain confirmation, which could cause a week-long timeout delay on the funds, replacing it with infinite retry opportunities over a period of months! In addition, there is no cost to cancel the swap.

Finally, for additional developer friendliness, once a swap address (i.e. the 2-of-2 + RELATIVE-TIMEOUT) is established, this address doesn't commit to any specific time or payment hash like an HTLC does so it can be used indefinitely, and even sent to without interacting with the server. The server will just detect that funds are there via the blockchain once the Loop In user initiates a swap. This can be useful if developers don't want to load up the Loop client, want to withdraw to their LN balance from an exchange that doesn't support LN, want to limit the amount of funds in their hot wallet in live channels without compromising their ability to pay on LN, or just want the option to use LN for whatever reason before the relative timeout. This increased flexibility exists because the option to instantly swap is available for months after confirmation via that relative timeout.

Future Enhancements 

As discussed above, the initial implementation of this feature provides end users with a better user experience with regard to fees, swap retries, and swap timing. In addition to those improvements, we're excited about enhancing this feature with even more flexibility for our users. We're already working on enhancements that, once the on-chain Loop In transaction is confirmed, would allow users to:

1. Directly open channels

2. Hold these established funds in cold storage even though they could be brought online and added to your channels instantly

3. Deposit directly onto an exchange or cold wallet

Conceptually, with this upgrade, funding a Loop In could no longer cost end users anything, since the funding can also be used as regular on-chain funds with zero additional fees. Thanks to MuSig2 and Taproot, a Loop In UTXO will be upgraded to do anything a normal UTXO can do as well at an identical cost. Ultimately, in the next few months, we plan to make these new flows the default for all Loops.

Further, in the future, the Loop In swap address can be preloaded with enough bitcoin for several swaps. So, instead of a one-time swap, the virtual transaction becomes a uni-directional channel, and signatures are used for a new update that gives us more funds in the channel.

Conclusion 

In summary, the new mode of Loop In swap addresses can be re-used and those re-used addresses don't need server interaction to add funding, both of which significantly simplify the user experience. Additionally, users can fund swaps months in advance from when they actually need to execute the swaps, which when used correctly can reduce the chain fee costs for swaps. Last, Loop In swaps can be retried if they fail, which increases the ultimate success rate of attempted swaps over time. In the near future, end users will be able to use the UTXOs in the funded addresses to fund any on-chain operation with no additional penalty, providing users maximal flexibility with their funds.

Going forward there are many new features we plan to add using this new parent/child dynamic, and we could even add a grandparent or other branching setups for more flexibility. The main obvious target for our improvement in the future is to collapse the funding of swaps so that instead of each individual requiring their own individual output per swap, we have individuals share their outputs across swaps and then we have sharing of the funding UTXOs across individuals. Simply put, if two users Loop In, instead of each of them funding a 2-of-2 with us, we would migrate to a single 3-of-3 with everyone, and so the swap would reduce the UTXOs count there from 2 to 1, a big jump that can then be generalized to N:N, so a fixed number of outputs per swaps, meaning at scale we would basically completely eliminate the output cost to a marginal zero.

Chain efficiency is just one knob to adjust for Loops. We look at many other aspects that also matter a lot such as off-chain liquidity considerations, accounting, chain fee optimization, operational security, automation, and more. Our goal is to improve the experience for those who are actually using Loop to do commerce in the real world and solve any liquidity problems they might encounter with the decentralized Lightning Network. Further, we're actively looking for feedback on everything to prioritize those problems.

To learn more and start using the new Loop In swaps, read our Loop In documentation. We look forward to collaborating with the community to iterate on this feature, and we'd love to hear from you on Github or Slack.