@ gandlaf21
2025-02-12 12:23:40
### Unidirectional payment channels revisited
#### Nodeless lightning - Reduce ecash mints custodial risk
---
### Sats N Facts
The nostr:npub1yrnuj56rnen08zp2h9h7p74ghgjx6ma39spmpj6w9hzxywutevsst7k5cx 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 nostr:npub1htnhsay5dmq3r72tukdw72pduzfdcja0yylcajuvnc2uklkhxp8qnz3qac s [proposal](https://gist.github.com/lukechilds/307341239beac72c9d8cfe3198f9bfff)
> 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](https://en.bitcoin.it/wiki/Payment_channels#Spillman-style_payment_channels)"?
Essentially when we are talking about Spillman channels, what is meant are unidirectional payment channels (or [CLTV-style channels](https://en.bitcoin.it/wiki/Payment_channels#CLTV-style_payment_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](https://en.bitcoin.it/wiki/Payment_channels#Poon-Dryja_payment_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:
1. A `sender` receives his salary once a month. He opens a channel that is valid for one month.
2. 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.
3. 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.
4. 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 nostr:npub148jz5r9xujcjpqygk69yl4jqwjqmzgrqly26plktfjy8g4t7xaysj9xhgp and nostr:npub1htnhsay5dmq3r72tukdw72pduzfdcja0yylcajuvnc2uklkhxp8qnz3qac born at nostr:npub1yrnuj56rnen08zp2h9h7p74ghgjx6ma39spmpj6w9hzxywutevsst7k5cx ).
So stay tuned!