By Daniel Granhão
Self-custody is a foundational principle of Bitcoin. It means taking full control of your Bitcoin holdings, ensuring no third party can access or manipulate your funds. This crucial concept grants individual sovereignty over one’s financial assets.
An essential aspect of self-custody is eliminating the need to trust third parties. The idea is simple: if you hold the keys to your bitcoin, you’re not relying on any external entity to safeguard your wealth. However, as straightforward as this sounds, achieving complete independence from third parties can be complex in practice. Even with the best intentions, when self-custody is practiced, some trust is still required. After all, and contrary to popular belief, self-custody does not strictly equate to trustlessness. Additionally, minimizing trust is often at odds with maximizing ease of use, so the question arises: what is the ideal wallet for you?
This article explores the trust models of different Lightning wallets, and compares how they fit on the spectrum of trust. Specifically, we will look at the lipa wallet and see how it navigates the delicate balance between user experience and third-party reliance. We will explore the two primary categories of Lightning wallets: custodial wallets, where a third party manages your keys, and non-custodial or self-custodial wallets, where you retain control of your keys. By examining these models, we aim to shed light on the nuanced degrees of trust inherent in each type and help you make informed decisions about managing your bitcoin on the Lightning Network.
Custodial Lightning Wallets
We can broadly categorize custodial wallets into standard and trust-minimized ones. Here, trust-minimized doesn’t mean the amount of trust is small; it just means the wallet provider doesn’t need to be trusted as much as in standard custody.
Standard custody
Standard custodial wallets require users to trust the wallet service in all possible aspects. While they offer ease of use and convenience, they have considerable downsides when it comes to trust and security. Popular examples include Wallet of Satoshi and Blink, but exchanges with support for Lightning (e.g. Kraken) can also be included here.
With these wallets, as a user, you fully trust their providers with:
- Complete control over “your” funds: the wallet provider is entrusted with the full custody of the funds, meaning the user is entirely dependent on their security measures and integrity. If at any point the custodian becomes compromised, the funds are gone.
- Your private data: the wallet provider is trusted not to leak any information it possesses about you, including amounts, payees, and payment frequency. When the wallet requires a know-your-customer (KYC) process, this information is even strongly linked to real-world identities.
These two trust dimensions represent significant risks. Not only is there the risk that funds and private data are compromised due to bad security practices or integrity, but regulatory risk should also be considered. Oversight from the wallet provider’s government can lead to censorship of payments or even outright confiscation of funds, and there’s precedent for such behavior in history: Executive Order 6102 effectively forbade private individuals from holding gold in the US.
Trust-minimized custody
The concept of trust-minimized custody seems paradoxical, but here, the focus is on the term minimized, which does not mean the amount of trust is low. These types of wallets are still custodial, meaning that someone else still holds “your” funds. The difference is that some strategies are used to reduce the amount of trust. Namely, here we’ll cover two strategies that are based on the issuance of bitcoin IOUs that can be transacted freely and provide interesting privacy benefits. Lightning wallets can be constructed using these IOUs by internally swapping between the IOU and bitcoin on the Lightning network.
One example of this is Chaumian Ecash. This idea for digital cash was first proposed in 1983 but has mostly been dormant until very recently. Now, multiple solutions relying on this technology are under active development. The general idea is that a custodial third party can issue Ecash in exchange for bitcoin. The Ecash can then be traded between users of the same custodial service and later given back in exchange for bitcoin again. Ecash payments are anonymous, giving great privacy assurances to users of these systems. It’s because of this that we consider Ecash-based wallets to be minimizing trust when compared with other custodial solutions. The wallet provider still has to be fully trusted not to lose or misappropriate funds, but at least it doesn’t have to be trusted with private information.
There are currently two Ecash implementations in development for Bitcoin: Cashu and Fedimint. The main difference between these two, at least in regards to the trust required to use them, is that Cashu uses a single custodian to hold the deposited Bitcoin, while Fedimint instead uses a federation of custodians called “guardians”. Both generally offer great privacy benefits when compared with standard custody. With Cashu, you trust a single custodian to reliably hold your funds, while with Fedimint, no single compromised guardian could steal your funds. This makes Fedimint solutions arguably superior, but it does add complexity. Also, there’s an argument to be made against federation-based custody: if it’s hard to find a single trustworthy custodian, it should be even harder to find e.g. 5 trustworthy custodians.
Another strategy for trust-minimized custody is utilizing the Liquid Network. The Liquid Network is an UTXO-based, bitcoin-denominated sidechain governed by a federation of distributed members. It implements confidential transactions, which is why we also consider it a form of trust-minimized custody. The trust profile of these wallets is similar to that of Fedimint, as both rely on a federation to manage the funds, but Liquid might have an advantage in its audibility: anyone can run a Liquid network node. An example of a Liquid-based wallet is AQUA.
Non-custodial Lightning Wallets
Now, this is where analyzing trust starts to get tricky. With non-custodial Lightning wallets, the user owns the keys that can move their funds, which remarkably decreases the trust required to use the wallet. In practice, some trust is always required. Also, the aspects of trust that are still required become more complex to understand and compare.
Here, we’ll analyze different non-custodial solutions, but we’ll do so by looking separately at each dimension on which trust might be required. We’ll reference the choices made by some popular non-custodial wallets and point out the direction we took while developing the lipa wallet.
Cloud Hosting
Some components of a Lightning node can be hosted on the cloud, which can provide benefits like safe, concurrent, multi-device access to the node. This topic was already briefly explored in our last blog post, in which we introduced the concepts of client-heavy and cloud-heavy Lightning node solutions. Here, we are only considering non-custodial solutions, so keys, and thus signing, must be under user control.
What impact does cloud hosting have on required trust? Generally, a cloud-heavy solution requires more trust, but it’s hard to tell without going into the details of a specific implementation and which recovery options it provides in case the cloud provider is compromised. Given that the user controls the keys, the funds cannot simply be appropriated, but access to them can still be restricted. Something as simple as an outage of the cloud provider causes the user to be unable to make payments.
For lipa wallet, we use cloud hosting of nodes using Greenlight by Blockstream. When using Greenlight, the client runs a validating signer (VLS) that only signs approved actions, ensuring the user is in control of his funds. Despite this, if Greenlight’s servers are unavailable, users cannot access their funds. This could happen by mistake, it could be the outcome of an attack, or could even be the result of censorship attempts towards certain users. Does this mean Greenlight users simply have to trust Blockstream? Not quite. Users can use static channel backups (SCBs) to recover their funds. Still, this procedure isn’t trustless: it requires that users trust their channel peers to have kept channel states and will not try to publish an old state, even though they are highly motivated not to do so due to the Lightning punishment mechanism. We deemed this amount of required trust worthwhile in order for users to have safe multi-device access to the Lightning node.
Additionally, Greenlight must be trusted not to collude with channel peers. If a peer publishes an old channel state in an attempt to steal funds, usually, that would be met with a punishment of losing all funds, but if they collude with Greenlight, they can make sure that the punishment transaction is not broadcast. You could observe the network for published old channel states yourself, in a self-sovereign way, but that requires running a piece of software 24/7, which isn’t feasible for the average user. The solution here is to use independent watchtowers that can punish the cheating channel peers, but even the watchtower needs to be trusted to do its job. There is no way of configuring custom watchtowers in lipa wallet for now, but we intend to have it soon.
LSP
If a wallet relies on a Lightning Service Provider (LSP), its users also have to place some trust in this provider. An LSP is responsible for connecting the user to the rest of the Lightning network, making sure it can efficiently receive and send payments. This usually means opening channels with the user’s node.
Users trust LSPs to continue serving them. If a single LSP is used, which is currently the case with most LSP-based wallets, then the user trusts that single LSP to continue allowing him to send and receive payments. The solution to a compromised LSP that stops serving a user is to force-close channels, which does allow the user to regain control of his funds but implies a cost due to the need to open new ones.
Additionally, when an LSP is used in conjunction with a cloud-heavy wallet, the LSP is trusted not to collude with the node hosting provider, as explained in the previous section. This is the case with lipa wallet, but we are working hard to address this attack vector. The path forward is twofold: first, we want to allow multiple LSP providers, thus allowing the user to choose whom they want to trust; second, we intend to support configurable watchtowers in order to limit the required trust towards LSPs.
The alternative to using an LSP is having users manage their own Lightning channels. This means choosing which peers to open channels with, how many channels to open, and their size. This isn’t an easy task: it requires knowledge of several technical aspects that average users don’t have. Additionally, making the wrong choices affects the user’s ability to transact. It’s because of this that using an LSP has become a de facto-standard for any wallet targeting non-technical users, and is the choice we made with lipa wallet.
The most common wallets that don’t use a LSP are based on the user deploying and running his own Lightning node server at home. This is usually done using solutions like Umbrel or Raspiblitz and then using a “remote control” wallet app like Zeus to access and use the node. This requires a financial and time investment that cannot be expected of regular users.
Bitcoin Blockchain Access
Lightning wallets don’t live completely separated from the Bitcoin blockchain. They still need to interact with it to open and close channels. This means that to minimize trust, users would need to run their own Bitcoin nodes, which isn’t feasible for the average user.
Different types of interfaces can be used to access the blockchain. Direct access to a Bitcoin Core node is a possibility, but it’s common to use an Electrum server implementation like electrs or use BIP 157. What matters most regarding trust is who runs and controls this access point, because tampering with it can be used to perform attacks where funds are lost. The details of how such attacks would take place are beyond the scope of this article, but they can largely be prevented through the use of a watchtower. Once again, however, when a watchtower is used, the user needs to trust it to do its job.
With lipa wallet, access to the blockchain is managed within Greenlight. No additional trust is required other than that already explained in the context of having a cloud-heavy node.
For wallets that use client-heavy node solutions, blockchain access does impact trust. That’s why many such wallets allow the user to configure this access. For example, in Phoenix, the user can choose which Electrum server he wants to use, which could potentially be under his control. The Breez wallet also allows configuring which BIP 157 server is used.
Pathfinding
Pathfinding is a necessary step in sending payments on the Lightning Network. It consists of figuring out which paths should be used to route payments from the sender to the receiver. For that, the sender needs to have an updated “map” of the network, known as the network graph. It’s important to keep in mind that this graph is always changing because the network is constantly evolving.
How pathfinding is implemented can also imply some additional required trust. If it’s done by a third party, then this party needs to know the recipient of the payment, which is information that ideally would be kept confidential. Besides having to trust the pathfinding provider not to share recipient data, it also needs to be trusted not to provide unnecessarily expensive paths, potentially paths that route through nodes collecting fees for the same entity.
Keeping pathfinding under user control has its disadvantages. The first is that a centralized third party will always be able to have more knowledge about the network and, thus be able to find paths more efficiently. Both because it’s used by other clients, and also because it can use probing to preemptively learn which paths will work. Another disadvantage is the need to have an updated network graph available. The trust-minimized way of doing so is by learning it from network peers, but that takes time, meaning that mobile nodes would be unable to send payments for the first minutes after starting. An alternative is to use rapid gossip sync (RGS), which allows getting compressed graph updates, but requires trusting the RGS server not to provide outdated or tampered data.
With lipa wallet, pathfinding is also handled by Greenlight, meaning that Blockstream needs to be trusted not to share all payment recipient data. We think this is an acceptable compromise due to the higher payment reliability it can provide. However, in the future, the importance of this might be lower due to the use of trampoline payments and blinded paths.
Other wallets have implemented local pathfinding, Mutiny being a great example.
LNURL
The LNURL standard is a widely adopted set of protocols that add functionality on top of the base Lightning specification. Commonly used LNURL forms are:
- LNURL-pay: to pay a node by automatically requesting an invoice for an agreed amount
- LNURL-withdraw: to request the payment of an invoice with an agreed amount
- LNURL-auth: to authenticate a user in some web application
Despite its widespread use, LNURL doesn’t work well with non-custodial mobile wallets. To receive LNURL-pay payments in a trustless way, the only way is for the receiver to run an HTTP server himself, which isn’t feasible for average users. Because of this, most non-custodial wallets, which usually strive for trust minimization, have kept away from LNURL, only supporting the client part of its interactions: they’re only able to pay using LNURL-pay, but can’t receive payments.
With lipa wallet, we have implemented a trust-minimized way of receiving using a Lightning Address, a form of LNURL-pay. It keeps the funds non-custodial at all times, but it does require some trust for transacting. It works by having lipa run an LNURL-pay server that routes requests to the user’s device, where the keys reside. This is possible through the use of a waking mechanism that can generate an invoice even when the app is closed. But why does it require trust? Well, it turns out our server could simply return an invoice of our own, taking the payment to us, instead of the user. It’s for this reason we introduced Lightning Address as an optional way to receive payments within the wallet.
Fiat Exchange
Exchanging between bitcoin and fiat currencies isn’t necessarily a component of a Lightning wallet. Despite that, all new Bitcoin users need it, so we have integrated it directly into lipa wallet, as some other wallet developers have done with theirs. For this reason we also want to cover the trust involved with such a feature.
Here, there simply is no way of reducing trust. The trust involved with simply holding fiat is already substantial (i.e. trusting a central bank not to severely debase a currency). When exchanging between fiat and bitcoin, the exchange provider also needs to be trusted as it always temporarily holds users’ funds. There is no trustless swap mechanism with fiat. In lipa wallet, our partner Pocket provides the exchange service.
Final Thoughts
As we’ve explored here, there are a multitude of different kinds of trust that can be required to use Bitcoin, even more so when doing it through the Lightning Network. There are trade-offs everywhere, and many of those trade-offs have a trust aspect to them. With lipa wallet, we are doing our very best to get to a point where user experience is great, keeping trust to a minimum. That’s why we stand by a non-custodial model, but striving for great user experience has also forced us to make some decisions that imply increased trust from our users. Nonetheless, we want to be transparent about such decisions, and we hope this post shows our commitment to transparency and, above all, helps our users make informed decisions.
In practice, all solutions require some degree of trust. Even if a user builds and runs all the software himself, it isn’t feasible to verify all of the code or to verify all of the hardware the code runs on. We have to live with some trust, but we should always have in mind the goal of reducing trust, and verifying instead.
