This Time It's Different

2024 was a tough year for lightning, The Samourai Debacle, Phoenix leaving the US, Mutiny Wallet shutting down. DOJ overreach and what can only be described as a half-assed NFT revival hangover has had the ecosystem down for a while now. Recent events however indicate a turn around. Consider this--

The Federal court responsible for brazenly pushing money transmission charges implying a definition that goes well beyond FinCEN's intent in the Samourai case has indicated they're pulling back on crypto cases.

The Tornado Cash smart contract sanctions have been repealed by a US Federal judge, marking a move back towards sanity involving creating and serving non-custodial software.

President Trump's Treasury Secretary appointee Scott Bessent is going to head the "Most Pro-Crypto Treasury We’ve Ever Seen." Both FinCEN and OFAC are part of the treasury department, key agencies when it comes to enforcement around sanctions and the BSA. Exactly the regulatory constructs that the Tornado Cash and Samourai cases revolved around.

With Bitcoin's recent run to all time highs above $100k, the mempool is still relatively sleepy, with top next block rates ranging from 6 - 10 sats/vbyte (about $1-2 per transaction), it seems NFTs didn't make quite the comeback we thought they would, and on-chain volume is still far away from scaling limits.

2024 is behind us, and we're still here, so what's next? It's time to start building the bitcoin ecosystem we started in 2023 and never got to finish.

Why Self-Custody?

A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution.

Bitcoin was designed for self-custody. While this post is more about the how, it's worth saying that building your application around self-custody gives a few advantages

• Global Access. Self-custody tools and services are technology, not financial instruments, and not bound by the patchwork of regulations that exist for financial institutions across the world today.
• Scale. With deposit growth, a financial institution also grows risk and all the costs that come with it. Compared to bailout-able fiat, hard money deposits compound this risk substantially. Self-custody services do not hold customer funds and do not have this problem.
• Resilience. Open source code is hard to get rid of and cannot be sanctioned.

Self-Custody Lightning

Looking back at the beginning of self-custody lightning with Breez, Phoenix, Mutiny– and even with lightning wallets today, I see three issues:

• We went 100% lightning from Day 1
• In doing so, we found the limits of all-lightning (it wasn't ready yet)
• Everyone underestimates liquidity

Force closes, high fees, wasted liquidity, and now a sentiment among the industry that Bitcoin's leading payments solution is only good for banks and exchanges–  we are still early.

I've said time and time again, Bitcoin's uptake is not a tech problem. We have the primitives and protocols that can make for a great experience. Bitcoin's uptake is a lack of more high level abstraction, development, and focus on real people.

Don't get me wrong, this work is hard. Look at the timeline from turning on multisig addresses technically to a consumer facing application that can feasibly be used by a beginner without hand holding.

April 5, 2012: Gavin Andresen's commit to enable multisig on mainnet is merged (BIP 11)

March 2, 2015: Electrum wallet releases version 2.0 with multisig support (For advanced Bitcoiners)

March 13, 2024: Bitkey ships the most user-friendly self-serve multisig collaborative custody wallet to date.

Nearly 12 years from Bitcoin merge to "my grandma can use it" UX. We are not Bitcoin tech limited, we are application developer limited. We knew what the technology could be used for, but actually using it, making tooling for it (PSBTs weren't a thing until 2018!), and making it usable for the everyday person took years. Lightning is no different.

So here's how I'd develop the next self-custody lightning wallet.

1. Use Lightning Realistically
2. Blend the lines between on-chain and off-chain
3. Think differently about liquidity

Using Lightning Realistically

Every Lightning wallet up to this point has taken the lightning knob and turned it to 11. Full lightning all the time, completely off-chain. The idealized experience is all lightning all the time, but I think that doesn't become necessary until we truly do see limited on-chain blockspace.

Instead of trying to shove a user's entire life into a lightning channel, let's try something different.

Getting Started

Before we get into how the wallet could work, a bit about getting started with Bitcoin and lightning.

If you want to hold your own Bitcoin, there are a couple lower limits to how much you can actually control. Moving Bitcoin incurs a fee, so if you own less Bitcoin than it costs to move it, you will not be able to move that Bitcoin until you get more.

The lower limit for this is defined in Bitcoin core as the dust limit. The dust limit for native segwit addresses (bc1q…) is 294 satoshis or $0.29 at a Bitcoin price of $100k. For taproot native (bc1p…), the limit is 330 satoshis or $0.33. If your bitcoin balance is below these numbers, it is impossible for you to self-custody.

If you hold these sats in a lightning channel, the limit increases somewhat to account for the larger size of a commitment transaction, which you will need to close out your channel. Lightning implementations currently require a reserve of 1% of the value of the channel. For a 300k sat channel, your limit would be 3k sats or ~ $3.

Some lightning applications like nostr zaps for V4V micropayments assume that a new wallet holder will start their self-custody journey with a bunch of 5 or 21 sat payments. Clearly, these wallet holders will not be able to start with self-custody.

Hosted Channels

Hosted channels were first thought up by Andre Neves, Fiatjaf (before he made nostr) and the ZBD team. Hosted channels allow you to build a lightning wallet that does lightning things but does not care much about whether there is an actual underlying UTXO for the channel. This allows for a custodial experience that can be upgrade to self-custody later.

I think Andre and co intended for a hosted channel LSP to be mostly custodial, I’m not sure if they’re still using the concept today or have gone to simpler custodial setups.

This idea proves very useful for those people who are below lightning dust and reserve limits, or who don’t have enough balance to pay for a channel open, if your LSP wants up front payment.

An ideal experience that supports the “start with nothing” case is to start wallets off with hosted channels. This also can look like phoenixd’s implementation to an extent. An example:

For wallets that use the LSP spec, implementing this graduated hosted channel setup is relatively easy, just don’t broadcast the open transaction until later. How the wallet holder pays for the channel open fee is up to the LSP and wallet, but phoenixd’s method (accumulating credit to pay for eventual channel open) is a decent starting point. 

Blurring the Lines between On-Chain and Off-Chain

After we get the channel opened, hosted or not, the operation of the wallet will be a bit different. First, we'll only ever present the user with one Bitcoin balance. A user should know they're holding Bitcoin, but should not need to deal with the underlying thinking around lightning and on-chain. To achieve this, we'll of course have lightning channels and an on-chain wallet in the background, but at a deeper level, we'll be making extensive use of Swap in Potentiam originally proposed by Jesse Posner and ZmnSCPxj.

Swap in Potentiam, or SIP, is a way to create on-chain addresses in conjunction with a Lightning Service Provider or LSP. Our customer's wallet and our LSP collaborate to generate on-chain addresses that have the following conditions:

• A 2 of 2 spending path, requiring both the LSP and customer to sign to spend the UTXO
• A timeout path, after which only the customer can spend the UTXO

Swap in potentiam addresses are powerful. Since the LSP knows that bitcoin in a SIP address is unspendable without its signature until the timeout, the LSP is able to cosign and trust 0-conf HTLCs, channel opens, and splices from such addresses, allowing for instant lightning spends and liquidity re-ups from on-chain.

By using swap in potentiam, we can keep most wallet holders within a fixed, reasonable sized lightning channel, and push excess funds into SIP addresses on chain. This way, a wallet holder’s lightning liquidity and on-chain usage can be tuned based on their needs. Let’s look at an example of how this could work.

The DCA’er

This is the current lightning wallet torture case. This wallet holder buys $5 of Bitcoin daily and wants to keep custody of their funds. They occasionally buy something on the lightning store, but generally hodl.

• $5 / day deposit
• $30 / month spend
• Hodl the rest

The DCA’er starts with a wallet with a hosted channel. As they deposit, they quickly graduate to a self-custody channel. The LSP opens a 350k satoshi channel to their wallet at the LSP’s desired threshold.

The DCA’er continues depositing Bitcoin into their wallet. When they’ve deposited 330k satoshis, their wallet instantly swaps out 300k satoshis to an on-chain SIP address with a 1 month expiry. The user can continue receiving deposits over lightning that fill the channel until another swap.

When the DCA’er wants to spend, if they have enough balance in their lightning channel, the wallet can simply spend as normal. If they need to spend more than what they have in their channel, the wallet can call up Bitcoin from a previous SIP address to be swapped into the channel instantly. Alternatively, the SIP Bitcoin can create a new channel or even be spliced into the existing one to increase channel capacity.

SIP addresses eventually become on-chain UTXOs. 300k is chosen here as a relatively safe UTXO size to keep long term. The expiry path of the SIP address could be a multisig, allowing these on-chain UTXOs to become more “cold” over time.

The LSP can monitor SIP usage and splice in more capacity if the DCA’er becomes more of a spender over time.

Thinking Differently about Liquidity

Using these tools, a smart wallet and LSP can optimize liquidity, on-chain fees, and user experience.

• Hosted channel threshold
• Channel size
• SIP swap threshold
• SIP / LSP Splicing

The rest is left as an exercise to the savvy wallet or LSP developer :) Having the right tools and general approach is the first step.

If you’re interested in this sort of thing, feel free to subscribe or reach out at me@nickslaney.com.