The Breez Release Candidate: Getting Lightning Ready for the Global Takeover
By: Roy Sheinfeld
Tags: Bitcoin, Cryptocurrency, Payments, Mobile, Lightning Network

1. Channel creation on the fly

In previous releases, Breez would automatically open a new channel with Breez mobile nodes upon initialization. The capacity was fairly large (1M sats), but that wasn’t always enough inbound liquidity for all new users. Existing users might also lack sufficient inbound liquidity if they were in the blessed position of receiving more payments than they make.

With this release, inbound liquidity becomes a problem that future generations will not understand, like debugging software by checking the order of the punch cards. Now, if Breez notices that a user lacks the inbound liquidity to process a payment, it simply opens further channels as needed. Exactly. The channels between Breez and the users adapt dynamically to their individual usage patterns. A user’s capacity automatically grows with their needs. Pretty cool, huh?

The best bits don’t just fall in your lap; you gotta catch them on the fly. For inbound capacity, search “Pelicans”. (Image: Pixy.org)

The automaticity is immediate:

When Bob wants to receive a payment but lacks inbound capacity, his Breez app recognizes the lack and issues two invoices using the same preimage: one to Alice requesting payment and a second to the Breez LSP. The amount of the second invoice equals the amount requested from Alice minus a miniscule service fee to Breez for opening the channel Bob requires. The invoice sent to Alice includes routing instructions, indicating a pseudo channel between Bob and the Breez node. When Alice pays the invoice she received from Bob, the Breez node intercepts the payment and holds it. The Breez node then opens a channel with Bob and skips funding confirmation. Then it pays Bob the second invoice and receives the preimage. Once the preimage is received from Bob, Breez settles the payment with Alice.

Importantly, the users remain virtually oblivious to all of this. The complexity stops before it ever reaches their eyes or fingertips. Inbound liquidity remains an issue, but it is now an issue for engineers and developers to worry about, not users.

”lnd nodes can now intercept HTLC forward events to override the default routing behavior”: a sneak peek at the sausage factory (https://bit.ly/355XHmr)

The catch here is the cost. For every channel Breez opens, we have to pay mining fees, and we’re committing sweet, valuable, delicious capital to the channel. How much? Breez adds 100K sats to every channel. So if a user receives 50K sats, the channel Breez creates will contain 150K sats. To cushion that blow, we now charge 0.1% (yes, a mere one thousandth) of the amount received per channel created. Miniscule means miniscule.

2. Zero-conf(irmation) channels

We’ve discussed zero-conf channels and their trade-offs before. In effect, they allow users to start using Lightning payment channels before those channels have been confirmed on-chain. It’s like placing your order in a restaurant and letting the kitchen get started before you’ve paid your bill. We’ve now gone ahead with our own implementation on top of lnd.

When the Breez node creates channels on the fly in response to user demand, they’re actually zero-conf channels. These are not standard channels because they can function before they’ve been confirmed on the chain. Instead of making users wait until blocks are mined, these channels become active instantly, allowing users to spend their funds immediately after they receive them. Onboarding just went from a matter of minutes to seconds.

Yes, zero-conf channels do involve a quantum of trust. Until the channel is confirmed, users have to trust Breez with the funds on the new channel. They can verify that a funding transaction has been initiated, but without confirmation from the chain, they can’t be certain that Breez hasn’t tried to double-spend. Using, spending, and paying those funds outwards will reduce the trust users temporarily extend. After about an hour (at average mining pace), there’s nothing to worry about anyway because Breez uses a target confirmation time of six blocks. Once confirmed, zero-conf channels become standard, trust-free Lightning channels.

3. Sending Multi-Path Payments (MPPs)

Attentive readers will already have guessed that, thanks to channels being created on the fly, most users will soon have multiple channels open with Breez under the hood. As we’ve mentioned before, MPPs give users access to the sum of their local balances, letting them use all the bitcoin in their Lightning wallets for any given transaction, regardless of how those funds are distributed among their channels. In other words, MPPs let Breez automate how a user’s multiple channels interact and keep that complexity out of sight.

While receiving multipath payments was already possible with Breez, we’ve now enabled users to send via MPP. Distributing a payment among different channels is now as obtrusive and cumbersome as routing an email through the net to its destination. Exactly. It’s invisible and automatic.

In fact, Breez has developed its own optimization protocol to improve how MPPs work on mobile clients. Instead of trying to find the right combination of channels to use by halving the payment amount successively until the pieces are small enough to send with the local balances available, the Breez client is smarter. The first division automatically takes the largest local channel balance as its starting point and works from there. The result is less computation and less channel fragmentation (i.e. fewer channels with tiny, barely usable balances left).

4. 4M sat limit

Until now, Breez has capped the default channel at 1M sats. With the new multi-channel architecture and after having routed hundreds of thousands of transactions over thousands of channels, our system has proven itself. The rewards of testing before trusting are more freedom and fewer limits. Instead of limiting a single channel to 1M sats, Breez now limits the sum of all a user’s local balances to 4M sats.

The new limit of 4M sats is a quantitative change that brings a qualitative difference in use cases. Users’ micro-transactions need not be so micro any longer. Instead of being able to purchase, say, a pizza or a game over a single channel, they’ll now be able to purchase things like a new phone or even a flight.

5. Zero channel reserve

Lightning’s standard specs included a channel reserve set at 1% of the funds stored at both ends of a channel. The idea is like inserting a coin into a shopping cart’s coin lock: the coin is worth far less than the cart, but it’s just enough of an incentive for the user not to abuse the cart. Breez had set the channel reserve at just 600 sats to be less of a nuisance.

But it would be contradictory to say that channel creation happens under the hood while simultaneously keeping a 600-sat channel reserve on each of a user’s 2?, 5?, 47? channels, especially when those additional channels are created automatically on the fly. In order to eliminate the inconvenience of proliferating channel reserves, we eliminated the concept. Breez channels now have no reserve. 0 reserve = 0 inconvenience.

6. Connecting to multiple nodes

This isn’t a new feature, but it’s important to mention that users can still use Breez to connect to other LSPs and even to their own home-based nodes. Although we’ve added support for zero-conf channels via the Breez LSP, opening Lightning channels with other nodes is, of course, still possible — and encouraged!

Why? For us, decentralization is non-negotiable. There’s more to the Lightning UX than what users see in the app. It’s also important to consider the shape of the network where they store and send their money. Are they subject to censorship? Is the network prone to failure or is it robust? Is the liquidity concentrated or diffuse? The ability to create channels and interact with multiple nodes, remains the backbone of a decentralized Lightning network.

For example, Breez users can open their own channels and connect to other nodes using LNURL-channel. The choice of a non-Breez LSP, like LNBig or Bitrefill’s Thor, is theirs. We’re trying to succeed in this ecosystem, not to monopolize it. Letting our users connect with other LSPs demonstrates our commitment to a decentralized, P2P payment network.

A combination of invisible and visible improvements by and for all of us

Of course, such an extensive update with so many new features would not be complete without giving the homepage UI a facelift to make the experience even smoother. It also stands on a massive foundation of changes that we’ve made to the Breez library, to our underlying LND implementation, and to the mobile app. We couldn’t ask for — nor create — a better footing on which to further improve our consumer and merchant solutions.

Ooohhh! Aaaahhh!

I’d like to thank all you Breezers out there. Sure, we coded these improvements, but in a very real sense you’re our quality assurance department. Our users even inspire ideas about how to improve Breez with new features, like the POS mode. They give us plenty of very sharp and useful feedback about what they would like to see and how we can improve. We don’t compromise because you won’t let us, and that’s awesome. So thank you. You rock 🤘.

But that thank you is not meant to imply that our mission is accomplished. We’re introducing many new features here, including our big lnd 0.11 upgrade. Like everything in life, it’s a test. We need you to continue telling us what works, what doesn’t, what could be improved, and what new innovations you’d like to see that we may not even have imagined yet.

Our users help us to improve, we help Lightning to improve, Lightning helps Bitcoin to improve, and all together we might just help the world to improve. Let’s keep it up.

PS: Ian, another Breez user, suggested including a map in the app indicating the locations of merchants who accept Lightning. That’s exactly the kind of idea we love to hear. We don’t yet have that map, but next time you’re in Hafeezpet, check out the Royal Foods Paan Shop. We’re pretty sure they take it: