Author: Alex Bosworth
Source: https://lightning.engineering/posts/2025-02-13-loop-musig2/
This article will explain how we are using "MuSig2" (the aggregated public key protocol for the Schnorr digital signature algorithm) to strengthen Lightning Loop - our non-custodial submarine swap service. Submarine swaps allow users to exchange on-chain BTC for BTC on the Lightning Network (and vice versa) using Hash Time Locked Contracts (HTLCs), which guarantee atomicity and eliminate counterparty risk.
We are also excited to share our technical progress on Loop In, where users can now directly send on-chain BTC to a Lightning channel to top up their outbound capacity for Lightning Loop. The recent update allows Loop In users to leverage MuSig2 to pre-fund the on-chain portion of a swap before the off-chain part is executed. From the end-user's perspective, this reduces the complexity of the user experience, allows locking in potentially lower fees, and supports retries, thus enhancing the functionality of Loop In.
Integrating MuSig2 into Loop
Last year, we upgraded all of our Loop swaps to use MuSig2 signatures, reducing the cost of all swaps. MuSig2 is a multi-signature scheme designed to make BTC transactions more efficient, private, and secure. It allows multiple parties to cooperatively generate a single signature that is indistinguishable from a regular single-signature transaction (from the blockchain's perspective). It reduces transaction size, thereby lowering fees, and also enhances privacy by hiding the number of participants. Compared to earlier multi-signature schemes, MuSig2 is faster and eliminates the need for interactive communication at each step.
Additionally, we have introduced Instant Loop Out, which allows users to instantly swap channel funds for on-chain funds without waiting for block confirmations. The purpose of a Loop Out swap is to top up the inbound capacity of a channel. This instant mode allows users to pre-fund a non-HTLC parent output, with a virtualized child HTLC, so the timeout mechanism (at the time of this pre-funding) has not yet started ticking; thus, we can pre-fund without having to wait until the last minute. This is akin to a payment channel getting pre-confirmed, far ahead of when the user intends to make a payment.
This change is part of our MuSig2 and Taproot roadmap, where we aim to fully leverage the benefits brought by these new capabilities. The first step is a simple upgrade to Schnorr signatures, which are smaller in size and thus more space-efficient compared to ECDSA signatures. However, due to Taproot's script design, this may incur more space costs in some scenarios. So, we are proactively migrating to MuSig2, transitioning the swap mechanism from script execution (which would write all the swap details on-chain) to collaborative key spending, where the swap details are omitted, and due to the use of the aggregated public key, only a single signature will remain on-chain, without any script execution.
Lower costs, more developer-friendly user experience
With the introduction of the new Loop In feature in the latest release, end-users can now initiate a Loop In as soon as the Loop In transaction is confirmed on-chain, without having to wait. This allows users to capitalize on low-fee windows to inject funds, reducing the fee overhead associated with the Loop In service.
This is achieved by transitioning the submarine swap implementation from a "2-of-2 OR HTLC (multi-sig spend or HTLC spend)" output to a "2-of-2 OR RELATIVE-TIMEOUT (multi-sig spend or relative-timelock expiry, allowing single-party refund)" output (and a virtualized child transaction). This new relative-timelock output is only spent into a virtualized child transaction with an HTLC output during the swap; even if that child transaction is ultimately used for the swap, the cooperative branch can still be used, rather than fully exposing the HTLC on-chain, keeping the on-chain swap footprint to a minimum - a single signature, with no nested transactions.
This way, Loop In gains the additional MuSig2 and Taproot features, allowing the service provider to retry or cancel swaps, rather than just succeed or fail. This eliminates the potential failure mode of the off-chain liquidity transfer being faster than the on-chain confirmation, where funds could get stuck for up to a week; instead, you can retry indefinitely within a timeframe! Incidentally, canceling a swap is free of charge.
Finally, it is more developer-friendly: once a swap address (the 2-of-2 OR RELATIVE-TIMEOUT output) is established, this address does not commit to any specific time or payment hash, so it can be reused indefinitely; you can even receive payments to it without interacting with the service provider. The service provider will only notice the funds when the Loop In user initiates a swap. This is very useful when developers don't want to load the Loop client, want to withdraw their balance from exchanges that don't support Lightning payments, or want to limit the funds in their active (hot wallet) channels without sacrificing their Lightning payment capabilities. Before the relative-timelock on the swap address expires, you can move those funds into Lightning channels at any time. This increases flexibility, as you can initiate instant swaps months after the funds were deposited.
Future Enhancements
As mentioned, these initial implementations provide end-users with better experiences in terms of fees, retry opportunities, and timing of transactions. Beyond these improvements, we also look forward to further enhancing these features, giving users even more flexibility. We are already working on these enhancements, where, once a Loop In transaction is confirmed on-chain, users will be able to:
- Directly open channels
- Control these funds using cold storage private keys, though they can still be added to your channels at any time
- Directly deposit into an exchange or cold wallet
Conceptually, with these upgrades, funding a Loop In address will not require the end-user to sacrifice anything, as the deposited funds can be used for regular on-chain payments (without incurring additional fees). Thanks to MuSig2 and Taproot, the Loop In UTXO will be upgraded to be able to do everything a regular UTXO can do, at the same cost. Ultimately, we plan to make this new flow the default option for all Loop transactions in the coming months.
Additionally, in the future, Loop In swap addresses can be pre-funded with sufficient funds to allow for multiple swaps. So, the virtualized transactions will become unidirectional payment channels (rather than one-time swaps), where the user's signature is just reallocating more funds to the service provider within the channel.
Conclusion
In summary, the new Loop In swap address model allows for reusability and the ability to fund these addresses without service provider interaction, both of which greatly simplify the user experience. Additionally, users can pre-fund the addresses months in advance to be used for future swaps; when used responsibly, this will reduce the on-chain fee cost for users' swap operations. Finally, the new model allows users to retry failed swaps, improving the overall success rate of swap operations over a given timeframe. In the near future, end-users will be able to use the UTXOs in their swap addresses for any on-chain operations without incurring higher costs (compared to regular on-chain funds), thereby gaining maximum flexibility.
In the future, we also plan to add many new features using this parent-child transaction mechanism, and we can even add a grandfather transaction or other branch initiation steps to make it more flexible. Our main goal is to melt the funding of swap operations, so that it is no longer the case that each user has their own output for each swap request, but rather that users share their outputs in the swaps, and then we divide this funded output. In simple terms, if two users use Loop IN, it will no longer be that they each form a 2-of-2 output with the service provider, but a 3-of-3 output merged by the three parties, so the number of UTXOs can be reduced from 2 to 1. With such progress, we can extend it to the case of N users, so that each swap will only form a fixed number of outputs, meaning that as long as the scale is large enough, we can reduce the cost of forming outputs to almost zero.
On-chain efficiency is just one consideration of Loop. We also care about other equally important aspects, such as off-chain liquidity considerations, auditing, fee optimization, operational security, automation, and so on. Our goal is to optimize the experience for users who use or will use Loop for real-world business, and to solve any liquidity problems that the decentralized Lightning network may encounter. In addition, we are also actively seeking feedback to accelerate all of this.
For more information on the new Loop In swap, please read our Loop In documentation. We hope to work closely with the community to iterate on these features, and welcome feedback on Github or Slack.
(End)
