Unidirectional payment channels revisited - Ecash edition

Unidirectional payment channels revisited

Nodeless lightning - Reduce ecash mints custodial risk

Sats N Facts

The Sats n Facts (npub1yrn…k5cx) unconference has just wrapped up. And what a blast it was. In the heart of northern Thailand, developers, researchers, content creators and more, came together to share ideas on how Bitcoin, Nostr and other free protocols are being used everyday to liberate people.

Not only were stories shared from different community leaders on how embracing bitcoin has empowered them and their communities, but a big goal of the unconference was to bring bitcoin engineers and developers from various domains together in one room, unstructured, chaotic, and let them do their thing.

At first, I thought not having a schedule might be boring, but oh boy was I wrong. There was so much stuff going on, it was hard to choose which session I would have to miss!

Luke’s Spillman channel proposal

One of the sessions I definitely did not want to miss, was lukechilds (npub1htn…3qac) s proposal

Ecash mints funded with Spillman channels: The ultimate nodeless Lightning wallet

In true unconference fashion, he announced in the main room that the session was about to start, and that the people that are interested should meet him in the whiteboard corner in 10 minutes. The corner was packed, and Luke explained his proposal.

What’s a “Spillman channel”?

Essentially when we are talking about Spillman channels, what is meant are unidirectional payment channels (or CLTV-style channels). An unidirectional payment channel means, only one party can send payments, but not receive, and the other party can only receive, but not send. They also expire after a predetermined amount of time, and must be closed.

At first glance, this might look kinda stupid. After all, we have Poon-Dryja channels that are powering the lightning network. They are bi-directional, do not expire, and can be used to shuffle coins back and forth theorethically an unlimited amount of times.

So, why bother with this stupid one-way channel?

Simplicity is king

People that have worked with lightning channels can sing you a song about complexity, state handling and risks about the current state of bidirectional payment channels. Essentially, There are a lot of requirements on both channel parties when it comes to Liveness (being online) and also state handling (continuous backups). In some cases, especially when in the context of end-users wanting to perform payments on their mobile phone, they would appreciate it if there was not so much complexity and overhead involved.

The gist of the idea is to combine unidirectional channels and ecash mints to achieve the following:

A self custodial unidirectional payment channel to an ecash mint, massively reducing the senders liveness and state handling requirements when compared to a lightning channel. Sending payments through the mint will be done through swapping some of the channel balance for ecash tokens. At this point, the user is trusting the mint to honor the redemption of these tokens, while the remaining channel balance remains in self custody. This gives them better controll over their funds than just holding their entire balance custodied in the mint. The ecash tokens can then be redeemed to pay a lightning invoice, just the same as it is done now with normal cashu mints.

So this channel, that has no liveness or state management requirements for the sender, and must have a pre-defined close time, seems to be a perfect fit for the following usecase:

A sender receives his salary once a month. He opens a channel that is valid for one month.
The sender then can do his daily spending over this channel. He only trusts the mint with the amount for the current outgoing payment while it is swapped for ecash, waiting for redemption.
If the sender must receive funds (a refund for example), he can do so into the mints custody, by receiving ecash. He can spend his ecash funds first when doing his next payment, to reduce his custodial exposure.
When the channel expires, or runs out of funds, the mint closes the channel.

From a consumer perspective, that just want to receive his salary and make frequent payments afterwards, this usecase seems to make a lot of sense. Obviously from a merchants perspective on the other hand, such a channel doesn’t really work. But that’s fine, it’s not the problem we’re trying to solve here.

What do you think of this idea? Be sure to let me know in the comments!

In the next article, we will dive into how such a system can be implemented today, using Bitcoin, Cashu and Lightning. We will also discover how the system can be improved, to make channels non-expiring (A collaborative idea between stevenroose (npub148j…xhgp) and lukechilds (npub1htn…3qac) born at Sats n Facts (npub1yrn…k5cx) ).

So stay tuned!