How the Voltage LSP Enhances Privacy for Mutiny Wallet Users

Introduction

The Lightning Network's privacy features offer substantial anonymity to senders in transactions. This obscurity layer ensures that identifying a payment's initiator becomes challenging for the recipient and routers. This level of privacy arises from a process similar to the one used by Tor - onion routing.

Just as Tor applies onion routing to your data, Lightning uses this technique to secure payments and their associated data. This technique extends to general data with Bolt 12's onion messaging capability. Because of this, senders on the Lightning Network can enjoy a high degree of privacy when making transactions.

At Mutiny, we care about privacy for all users. We're a self-custodial Lightning wallet that operates within a web browser. You can access our wallet now by visiting https://app.mutinywallet.com. Our mission is to streamline the onboarding process without relying on custodians and to prioritize user privacy at every step.

In this article, we describe the privacy dilemma for receiving lightning payments and how the Voltage Flow 2.0 LSP helps solve that for all of us.

Receiver Privacy: The Current State and the Path Forward

While the Lightning Network provides senders with a good level of privacy, it is a different story for the receivers.

Today, the receiver's privacy in the Lightning Network isn't at the same level as that of the sender. This discrepancy has been a known tradeoff and is well-documented in various resources, including the comprehensive 2021 primer on Lightning Network Privacy.

When someone makes a payment to a recipient on the Lightning Network, they figure out the route for the payment using the network's gossip data. Once a path to the receiver's public key is found, the sender constructs the onion payment and sends it. In this case, the sender retains some anonymity, although it's imperfect. However, since the receiver's public key is known to the sender for constructing the route, the receiver's privacy in the transaction is somewhat compromised.

The sender can access important information about the recipient. For instance, they can view the coins or UTXOs (Unspent Transaction Outputs) shared between the two parties in the payment channel. With intelligent analysis, assumptions about coin ownership will be made with high accuracy. Consequently, the privacy concerns with the Lightning Network, particularly for receivers, closely mirror those of base-layer Bitcoin.

Other than coin information, further data leaks can occur. Self-selected node aliases can reveal user identities, often set as screen or company names. Nodes not operating exclusively on Tor could leak their IP addresses. In most cases, a fair amount of metadata is available on nodes that open public channels. Moreover, the node's public key, which doesn't change, is always accessible to the payers or service providers paying on the users' behalf.

Despite these challenges, there's been significant progress toward enhancing receiver privacy. Route Blinding, a privacy-enhancing solution, aims to resolve the issue of public key visibility and coin ownership detection. This enhancement could be a game-changer for receiver privacy. While the specifications for Route Blinding have merged, we're waiting for Lightning implementations to roll out this feature in production. Learn more about it at lightningprivacy.com.

About Voltage

So, where do Mutiny and Voltage come into the picture?

Voltage is a specialized Lightning Service Provider (LSP) with a wide array of offerings in the Lightning Network stack. Among its services, Voltage allows users to host their node on its platform, ensuring efficient management and high availability. It also offers various liquidity services, including a new one we've collaborated on called Flow 2.0.

Flow 2.0 is designed to provide recipients with Lightning channels precisely when needed. Typical Lightning Network usage necessitates opening a Lightning channel and requires inbound liquidity to receive funds. For many users, acquiring inbound liquidity can be a complex process. When users open a Lightning channel, they have 100% outgoing and 0% incoming liquidity because they open the channel with all their funds. If someone opens a channel to you, it reverses the scenario – you now have 0% outgoing liquidity and 100% inbound liquidity. A straightforward way to start receiving Lightning payments today is for someone to open a channel for you, which usually requires a request for permission or purchase from a liquidity service. While the dual funding protocol enhancement does exist to allow both parties to contribute funds to each side of a channel, it is not used much today.

Enhancing Privacy: Our Strategy

How do we ensure privacy for receivers?

When a Mutiny Wallet user configures a Lightning Service Provider (LSP), which by default is the Voltage LSP, all invoices created by the user will have Voltage's pubkey. From the sender's perspective, they are making payments to the Voltage LSP. The arrangement is akin to a VPN, where your interaction with websites originates from the VPN's IP address, not your home IP.

However, Voltage is NOT the actual payment recipient, nor do they have custody of the funds. The secret (preimage) needed to unlock the funds is only known to the user. Consequently, Voltage cannot claim the funds upon receiving the payment. To successfully process the payment, Voltage has to pay the user's invoice, known only by Voltage. Both invoices lock to the same preimage. Only after the user claims their funds can Voltage redeem the payment. This process mirrors how Lightning onion routing works today, where each router in the path can't claim the funds routed to them unless their payment has been redeemed by the next node in line.

This methodology is similar to how some existing lightning wallets function. It needs to be more widely recognized as a privacy enhancement.

A significant feature of this approach is that Voltage will open a channel to a user when needed, as the payment is in progress. Users no longer need an existing channel or manual channel management to optimize for future payments. Voltage charges a fee for this service, which covers providing liquidity and processing the on-chain transaction. While this involves a certain degree of trust with 0 confirmation channels, the experience is much smoother for the user. Confirmation settings can be adjusted by the user in Mutiny, although this feature is not yet available.

The privacy advantage doesn't stop here. As Voltage opens a channel to the user, they lock up their Unspent Transaction Outputs (UTXOs) in the private channel. Thus, users only expose their UTXOs when receiving or spending Lightning if they manually open a channel. The private channels also take advantage of the Short Channel ID Alias (SCID Alias) privacy feature, ensuring that neither the user's nor Voltage's UTXOs are revealed in the payment channel, even if someone could inspect the private channel details (which is highly unlikely).

Flow 2.0 integrates with Mutiny Wallet and any LND, CLN, or LDK-based node. For more details, check out their documentation.

Consider the Tradeoffs

Like a VPN, a tradeoff with using Voltage as an LSP is that Voltage is aware you're the recipient of these payments. Theoretically, you could string a series of LSPs to create a semblance of LSP onions. Nevertheless, Voltage's knowledge about you is limited to a node pubkey and specific payments they are routing to you.

In the Mutiny Wallet, you can turn off the Voltage LSP and still benefit from Short Channel ID Aliases (SCID Aliases). However, your public key information will be visible in your generated invoices until Route Blinding is available.

Additionally, as Voltage is currently the sole LSP provider, certain assumptions can be made when one Mutiny user pays another, and both use the same LSP. Voltage will know the public keys of both the sender and the receiver, as well as the payment amount and timing. To avoid this scenario, turn off the LSP setting in Mutiny Wallet. Please note that you will be responsible for opening channels, acquiring inbound, and protecting your public key. Furthermore, as the LSP specification matures and more implementations become available, we can offer users the option to select their own LSP.

Wrapping Up

There's a wealth of information covered here. If your curiosity is piqued, I suggest diving into my blog post from a few years back for a deeper understanding. Admittedly, aside from the advent of SCID aliases, only a little has changed since then.

Navigating the labyrinth of Lightning privacy, with its subtle nuances and edge cases, can be challenging. That's why we're committed to offering as much information and privacy-enhancing features as possible. We take pride in our capability to enable users to self-host the entire stack without needing an LSP if you choose. This possibility provides the ultimate privacy and control within today's lightning limitations.

One of the distinct characteristics the Mutiny Wallet offers: you can quickly spin up multiple wallet instances on various browsers, using them as needed and discarding them once done. This ability to effortlessly create and manage single or multiple nodes is a feature we're extremely proud of. You can even transfer the state from one browser or computer to another but do not run multiple instances at once. That feature is for another day!

We'd be thrilled if you'd try out Mutiny Wallet. Your feedback is invaluable, as are your questions. So, let's hear what you think and what you're looking for in a wallet.