Nodeless Lightning*
Cashu open source contributor
2025, Chiang Mai
Offloading client-side liveness and state handling burden by utilising unidirectional payment channels and ecash mints
Topics
Unidirectional payment channels
Pros and cons
Ecash mints
The idea
Unidirectional Payment channel
- Funds can only move in one direction
- Channel closure time is fixed at channel opening (?)
Unidirectional Payment channel
+ Ecash mint
Unidirectional Payment channel
+ Ecash mint
Open channel
1
Unidirectional Payment channel
+ Ecash mint
Open channel
1
Swap channel balance for ecash
2
Unidirectional Payment channel
+ Ecash mint
Open channel
1
Swap channel balance for ecash
2
Use ecash to pay lightning invoice through mint
3
Unidirectional Payment channel
+ Ecash mint
Open channel
1
Swap channel balance for ecash
2
Use ecash to pay lightning invoice through mint
3
Mint handles lightning complexities
4
Unidirectional Payment channel
+ Ecash mint
Open channel
1
Swap channel balance for ecash
2
Use ecash to pay lightning invoice through mint
3
Mint handles lightning complexities
4
- User gets onboarded to lightning without being exposed to its complexities and requirements
- Ecash is NOT trustless, therfore balances held in ecash are trusted/custodial
- Channels must be closed if they expire or run out of sender funds
Building unidirectional channels
Spillman/CLTV style channel
- S needs to backup the refund tx as insurance if R goes offline (Not needed for simplified version)
- R needs to keep latest update tx for closing the channel
- The channel will expire at Locktime of refund tx, and must be closed by R before the expiry
- S cannot close the channel. Only refund after expiry.
- Neither party has to watch the chain
Building unidirectional channels
S = Sender
R = Receiver
TL = Timelock
Building unidirectional channels
| Funding TX | |
|---|---|
| Inputs | Outputs |
| S utxo txid:index [5 ₿] |
S + R [5 ₿] |
S = Sender
R = Receiver
TL = Timelock
S creates Funding TX, but does not boradcast
1
Building unidirectional channels
| Funding TX | |
|---|---|
| Inputs | Outputs |
| S utxo txid:index [5 ₿] |
S + R [5 ₿] |
S = Sender
R = Receiver
| Refund TX Locktime (+1Month) | |
|---|---|
| Inputs | Outputs |
| Funding txid:index [5 ₿] S + R sig |
S [5 ₿] |
S creates Funding TX, but does not boradcast
1
S + R collaboratively sign refund TX
2
Building unidirectional channels
| Funding TX | |
|---|---|
| Inputs | Outputs |
| S utxo txid:index [5 ₿] S sig |
S + R [5 ₿] |
S = Sender
R = Receiver
| Refund TX Locktime (+1Month) | |
|---|---|
| Inputs | Outputs |
| Funding txid:index [5 ₿] S + R sig |
S [5 ₿] |
S creates Funding TX, but does not boradcast
1
S + R collaboratively sign refund TX
2
Once the refund TX is signed, the funding TX can be broadcast
3
Building unidirectional channels
| Funding TX | |
|---|---|
| Inputs | Outputs |
| S utxo txid:index [5 ₿] S sig |
S + R [5 ₿] |
S = Sender
R = Receiver
| Refund TX Locktime (+1Month) | |
|---|---|
| Inputs | Outputs |
| Funding txid:index [5 ₿] S + R sig |
S [5 ₿] |
| Update TX | |
|---|---|
| Inputs | Outputs |
| Funding txid:index [5 ₿] S + R sig |
S [4 ₿] R [1 ₿] |
S creates Funding TX, but does not boradcast
1
S + R collaboratively sign refund TX
2
Once the refund TX is signed, the funding TX can be broadcast
3
Now S can pre-sign and send TX updates to R. R holds on to latest state.
4
Building unidirectional channels
| Funding TX | |
|---|---|
| Inputs | Outputs |
| S utxo txid:index [5 ₿] S sig |
S + R [5 ₿] |
S = Sender
R = Receiver
| Refund TX Locktime (+1Month) | |
|---|---|
| Inputs | Outputs |
| Funding txid:index [5 ₿] S + R sig |
S [5 ₿] |
| Update TX | |
|---|---|
| Inputs | Outputs |
| Funding txid:index [5 ₿] S + R sig |
S [4 ₿] R [1 ₿] |
S creates Funding TX, but does not boradcast
1
S + R collaboratively sign refund TX
2
Once the refund TX is signed, the funding TX can be broadcast
3
Now S can pre-sign and send TX updates to R. R holds on to latest state.
4
If R wants to close the channel, he signs and broadcasts the latest state. R must close the channel before the channel expires.
5
Building unidirectional channels
| Funding TX | |
|---|---|
| Inputs | Outputs |
| S utxo txid:index [5 ₿] S sig |
S + R [5 ₿] |
S = Sender
R = Receiver
| Refund TX Locktime (+1Month) | |
|---|---|
| Inputs | Outputs |
| Funding txid:index [5 ₿] S + R sig |
S [5 ₿] |
| Update TX | |
|---|---|
| Inputs | Outputs |
| Funding txid:index [5 ₿] S + R sig |
S [4 ₿] R [1 ₿] |
S creates Funding TX, but does not boradcast
1
S + R collaboratively sign refund TX
2
Once the refund TX is signed, the funding TX can be broadcast
3
Now S can pre-sign and send TX updates to R. R holds on to latest state.
4
If R wants to close the channel, he signs and broadcasts the latest state. R must close the channel before the channel expires.
5
S cannot close the channel until the refund TX time lock expires. If R does not close the channel at that point, S reclaims entire balance.
6
Building unidirectional channels
| Funding TX | |
|---|---|
| Inputs | Outputs |
| S utxo txid:index [5 ₿] S sig |
S + R [5 ₿] |
S = Sender
R = Receiver
| Refund TX Locktime (+1Month) | |
|---|---|
| Inputs | Outputs |
| Funding txid:index [5 ₿] S + R sig |
S [5 ₿] |
| Update TX | |
|---|---|
| Inputs | Outputs |
| Funding txid:index [5 ₿] S + R sig |
S [4 ₿] R [1 ₿] |
S creates Funding TX, but does not boradcast
1
S + R collaboratively sign refund TX
2
Once the refund TX is signed, the funding TX can be broadcast
3
Now S can pre-sign and send TX updates to R. R holds on to latest state.
4
If R wants to close the channel, he signs and broadcasts the latest state. R must close the channel before the channel expires.
5
S cannot close the channel until the refund TX time lock expires. If R does not close the channel at that point, S reclaims entire balance.
6
To ensure S cannot broadcast an earlier update state, R will NOT sign and return updates to S. R only signs and broadcasts the final state.
!
Building unidirectional channels
(Simplified version)
S = Sender
R = Receiver
TL = Relative timelock 1 month
Building unidirectional channels
(Simplified version)
| Funding/Refund TX | |
|---|---|
| Inputs | Outputs |
| S utxo txid:index [5 ₿] S sig |
S + R || S + TL [5 ₿] |
S = Sender
R = Receiver
TL = Relative timelock 1 month
S creates and broadcasts Funding/Refund TX to open the channel
1
Building unidirectional channels
(Simplified version)
| Funding/Refund TX | |
|---|---|
| Inputs | Outputs |
| S utxo txid:index [5 ₿] S sig |
S + R || S + TL [5 ₿] |
S = Sender
R = Receiver
TL = Relative timelock 1 month
| Update TX | |
|---|---|
| Inputs | Outputs |
| Funding [5 ₿] S sig |
S [4 ₿] R [1 ₿] |
S creates and broadcasts Funding/Refund TX to open the channel
1
Now S can pre-sign and send TX updates to R. R holds on to latest state.
2
Building unidirectional channels
(Simplified version)
| Funding/Refund TX | |
|---|---|
| Inputs | Outputs |
| S utxo txid:index [5 ₿] S sig |
S + R || S + TL [5 ₿] |
S = Sender
R = Receiver
TL = Relative timelock 1 month
| Update TX | |
|---|---|
| Inputs | Outputs |
| Funding [5 ₿] S + R sig |
S [4 ₿] R [1 ₿] |
S creates and broadcasts Funding/Refund TX to open the channel
1
Now S can pre-sign and send TX updates to R. R holds on to latest state.
2
If R wants to close the channel, he signs and broadcasts the latest state. R must close the channel before the channel expires.
3
Building unidirectional channels
(Simplified version)
| Funding/Refund TX | |
|---|---|
| Inputs | Outputs |
| S utxo txid:index [5 ₿] S sig |
S + R || S + TL [5 ₿] |
S = Sender
R = Receiver
TL = Relative timelock 1 month
| Update TX | |
|---|---|
| Inputs | Outputs |
| Funding [5 ₿] S + R sig |
S [4 ₿] R [1 ₿] |
S creates and broadcasts Funding/Refund TX to open the channel
1
Now S can pre-sign and send TX updates to R. R holds on to latest state.
2
If R wants to close the channel, he signs and broadcasts the latest state. R must close the channel before the channel expires.
3
To ensure S cannot broadcast an earlier update state, R will NOT sign and return updates to S. R only signs and broadcasts the final state.
!
S cannot close the channel until the refund TX time lock expires. If R does not close the channel at that point, S reclaims entire balance.
4
| Update TX | |
|---|---|
| Inputs | Outputs |
| Funding [5 ₿] S sig + TL exp |
S [5 ₿] |
Unidirectional Payment channel
Pros and cons of Spillman channel
- Sender has no state/backup requirements
- Sender has no liveness requirements (keys can be in cold storage)
- Receiver only keeps latest state
- Receiver must only be live before channel expires to close channel
- Channel updates can be done in a single message
- Sender can only send
- Receiver can only receive
- Channel expires after given time and must be closed by receiver
- Channel cannot be closed by sender until channel expires
Building unidirectional channels
Roose-Childs triggered channel
- Is also unidirectional
- Does NOT expire
- Both parties can close the channel at any time
- Closing the channel needs 1 on-chain TX (cooperative) or 2 on-chain TX (uncooperative)
- Splicing funds can be done cooperatively
- Receiver has to watch the chain for trigger transactions
Building unidirectional channels
S = Sender
R = Receiver
TL = 144 Block relative timelock
Building unidirectional channels
| Funding TX | |
|---|---|
| Inputs | Outputs |
| S utxo [5 ₿] |
S + R [5 ₿] |
S creates Funding TX,
but does not boradcast
1
S = Sender
R = Receiver
TL = 144 Block relative timelock
Building unidirectional channels
| Funding TX | |
|---|---|
| Inputs | Outputs |
| S utxo [5 ₿] |
S + R [5 ₿] |
S creates Funding TX,
but does not boradcast
1
| Trigger TX | |
|---|---|
| Inputs | Outputs |
| Funding utxo [5 ₿] S + R sig |
S + R || S+TL [5 ₿] |
S and R co-sign the trigger TX
2
S = Sender
R = Receiver
TL = 144 Block relative timelock
Building unidirectional channels
| Funding TX | |
|---|---|
| Inputs | Outputs |
| S utxo [5 ₿] S sig |
S + R [5 ₿] |
S creates Funding TX,
but does not boradcast
1
| Trigger TX | |
|---|---|
| Inputs | Outputs |
| Funding utxo [5 ₿] S + R sig |
S + R || S+TL [5 ₿] |
S and R co-sign the trigger TX
2
S = Sender
R = Receiver
TL = 144 Block relative timelock
After receiving the signed trigger TX, S can broadcast the funding transaction and open the channel
3
Building unidirectional channels
| Funding TX | |
|---|---|
| Inputs | Outputs |
| S utxo [5 ₿] S sig |
S + R [5 ₿] |
S creates Funding TX,
but does not boradcast
1
| Trigger TX | |
|---|---|
| Inputs | Outputs |
| Funding utxo [5 ₿] S + R sig |
S + R || S+TL [5 ₿] |
S and R co-sign the trigger TX
2
S = Sender
R = Receiver
TL = 144 Block relative timelock
After receiving the signed trigger TX, S can broadcast the funding transaction and open the channel
3
| Update TX | |
|---|---|
| Inputs | Outputs |
| Trigger utxo [5 ₿] S sig |
S [4 ₿] R [1 ₿] |
S can now send pre signed update transactions to R, spending the trigger utxo outputs
4
Building unidirectional channels
| Funding TX | |
|---|---|
| Inputs | Outputs |
| S utxo [5 ₿] S sig |
S + R [5 ₿] |
S creates Funding TX,
but does not boradcast
1
| Trigger TX | |
|---|---|
| Inputs | Outputs |
| Funding utxo [5 ₿] S + R sig |
S + R || S+TL [5 ₿] |
S and R co-sign the trigger TX
2
S = Sender
R = Receiver
TL = 144 Block relative timelock
After receiving the signed trigger TX, S can broadcast the funding transaction and open the channel
3
| Update TX | |
|---|---|
| Inputs | Outputs |
| Trigger utxo [5 ₿] S + R sig |
S [4 ₿] R [1 ₿] |
S can now send pre signed update transactions to R, spending the trigger utxo outputs
4
If R wants to close the channel, they can do so by broadcasting the trigger TX, and the latest update TX
5
Building unidirectional channels
| Funding TX | |
|---|---|
| Inputs | Outputs |
| S utxo [5 ₿] S sig |
S + R [5 ₿] |
S creates Funding TX,
but does not boradcast
1
| Trigger TX | |
|---|---|
| Inputs | Outputs |
| Funding utxo [5 ₿] S + R sig |
S + R || S+TL [5 ₿] |
S and R co-sign the trigger TX
2
S = Sender
R = Receiver
TL = 144 Block relative timelock
After receiving the signed trigger TX, S can broadcast the funding transaction and open the channel
3
| Update TX | |
|---|---|
| Inputs | Outputs |
| Trigger utxo [5 ₿] S + R sig |
S [4 ₿] R [1 ₿] |
S can now send pre signed update transactions to R, spending the trigger utxo outputs
4
If R wants to close the channel, they can do so by broadcasting the trigger TX, and the latest update TX
5
| Update TX | |
|---|---|
| Inputs | Outputs |
| Trigger utxo [5 ₿] S sig + TL exp |
S [5 ₿] |
If S wants to close the channel, they can broadcast the trigger TX, and force R to close with the latest state. If R doesn't cooperate, S can claim entire channel balance when TL expires
6
Roose-Childs triggered channel: Splicing
| Funding TX | |
|---|---|
| Inputs | Outputs |
| S utxo [5 ₿] S sig |
S + R [5 ₿] |
| Trigger TX | |
|---|---|
| Inputs | Outputs |
| Funding utxo [5 ₿] S + R sig |
S + R || S+TL [5 ₿] |
| Update TX | |
|---|---|
| Inputs | Outputs |
| Trigger utxo [5 ₿] S sig |
S [4 ₿] R [1 ₿] |
Roose-Childs triggered channel: Splicing
| Funding TX | |
|---|---|
| Inputs | Outputs |
| S utxo [5 ₿] S sig |
S + R [5 ₿] |
| Trigger TX | |
|---|---|
| Inputs | Outputs |
| Funding utxo [5 ₿] S + R sig |
S + R || S+TL [5 ₿] |
| Update TX | |
|---|---|
| Inputs | Outputs |
| Trigger utxo [5 ₿] S sig |
S [4 ₿] R [1 ₿] |
| Splice TX | |
|---|---|
| Inputs | Outputs |
| S utxo [3 ₿] S sig Funding utxo [5 ₿] S+R sig |
S + R [7 ₿] R [1 ₿] |
S creates splice TX
1
Roose-Childs triggered channel: Splicing
| Funding TX | |
|---|---|
| Inputs | Outputs |
| S utxo [5 ₿] S sig |
S + R [5 ₿] |
| Trigger TX | |
|---|---|
| Inputs | Outputs |
| Funding utxo [5 ₿] S + R sig |
S + R || S+TL [5 ₿] |
| Update TX | |
|---|---|
| Inputs | Outputs |
| Trigger utxo [5 ₿] S sig |
S [4 ₿] R [1 ₿] |
| Splice TX | |
|---|---|
| Inputs | Outputs |
| S utxo [3 ₿] S sig Funding utxo [5 ₿] S+R sig |
S + R [7 ₿] R [1 ₿] |
| Trigger2 TX | |
|---|---|
| Inputs | Outputs |
| Splice utxo [7 ₿] S + R sig |
S + R || S+TL [7 ₿] |
S creates splice TX
1
S + R sign trigger2 TX
2
Roose-Childs triggered channel: Splicing
| Funding TX | |
|---|---|
| Inputs | Outputs |
| S utxo [5 ₿] S sig |
S + R [5 ₿] |
| Splice TX | |
|---|---|
| Inputs | Outputs |
| S utxo [3 ₿] S sig Funding utxo [5 ₿] S+R sig |
S + R [7 ₿] R [1 ₿] |
| Trigger2 TX | |
|---|---|
| Inputs | Outputs |
| Splice utxo [7 ₿] S + R sig |
S + R || S+TL [7 ₿] |
S creates splice TX
1
S + R sign trigger2 TX
2
S + R sign and Broadcast Splice TX
3
Roose-Childs triggered channel: Splicing
| Funding TX | |
|---|---|
| Inputs | Outputs |
| S utxo [5 ₿] S sig |
S + R [5 ₿] |
| Splice TX | |
|---|---|
| Inputs | Outputs |
| S utxo [3 ₿] S sig Funding utxo [5 ₿] S+R sig |
S + R [7 ₿] R [1 ₿] |
| Trigger2 TX | |
|---|---|
| Inputs | Outputs |
| Splice utxo [7 ₿] S + R sig |
S + R || S+TL [7 ₿] |
| Update TX | |
|---|---|
| Inputs | Outputs |
| Trigger2 utxo [7 ₿] S sig |
S [6 ₿] R [1 ₿] |
S creates splice TX
1
S + R sign trigger2 TX
2
S + R sign and Broadcast Splice TX
3
Once splice is complete, updates can be done as usual spending the utxo of trigger2
4
Roose-Childs triggered channel: Splicing
| Funding TX | |
|---|---|
| Inputs | Outputs |
| S utxo [5 ₿] S sig |
S + R [5 ₿] |
| Splice TX | |
|---|---|
| Inputs | Outputs |
| S utxo [3 ₿] S sig Funding utxo [5 ₿] S+R sig |
S + R [7 ₿] R [1 ₿] |
| Trigger2 TX | |
|---|---|
| Inputs | Outputs |
| Splice utxo [7 ₿] S + R sig |
S + R || S+TL [7 ₿] |
| Update TX | |
|---|---|
| Inputs | Outputs |
| Trigger2 utxo [7 ₿] S sig |
S [6 ₿] R [1 ₿] |
S creates splice TX
1
S + R sign trigger2 TX
2
S + R sign and Broadcast Splice TX
3
Once splice is complete, updates can be done as usual spending the utxo of trigger2
4
| Update TX | |
|---|---|
| Inputs | Outputs |
| Trigger utxo [5 ₿] S sig |
S [4 ₿] R [1 ₿] |
In this example, S is splicing-in 3 ₿ and R is splicing-out the 1 ₿ R owned from the old channel state. Splices are cooperative, and require both peers to be online.
!
Roose-Childs triggered channel: Reducing R exit cost
| Funding TX | |
|---|---|
| Inputs | Outputs |
| S utxo [5 ₿] S sig |
S + R [5 ₿] |
| Splice TX | |
|---|---|
| Inputs | Outputs |
| S utxo [3 ₿] S sig Funding utxo [5 ₿] S+R sig |
S + R [7 ₿] R [1 ₿] |
| Trigger2 TX | |
|---|---|
| Inputs | Outputs |
| Splice utxo [7 ₿] S + R sig |
S + R || S+TL [7 ₿] |
| Update TX | |
|---|---|
| Inputs | Outputs |
| Trigger2 utxo [7 ₿] S sig |
S [6 ₿] R [1 ₿] |
Roose-Childs triggered channel: Reducing R exit cost
| Funding TX | |
|---|---|
| Inputs | Outputs |
| S utxo [5 ₿] S sig |
S + R [5 ₿] |
| Splice TX | |
|---|---|
| Inputs | Outputs |
| S utxo [3 ₿] S sig Funding utxo [5 ₿] S+R sig |
S + R [7 ₿] R [1 ₿] |
| Trigger2 TX | |
|---|---|
| Inputs | Outputs |
| Splice utxo [7 ₿] S + R sig |
S + R || S+TL [7 ₿] |
| Update TX | |
|---|---|
| Inputs | Outputs |
| Trigger2 utxo [7 ₿] S sig |
S [6 ₿] R [1 ₿] |
| R Exit TX | |
|---|---|
| Inputs | Outputs |
| Splice utxo [7 ₿] S sig |
S [6 ₿] R [1 ₿] |
S can pre-sign an additional R exit TX, for each update, that allows R to exit at any time, using only one TX instead of two
1
R needs to keep the Update TX, in case S uses the trigger TX to exit
!
Unidirectional Payment channel
Pros and cons of Roose-Childs channel
- Receiver only keeps latest state
- Both parties can exit channel at any time unilaterally
- Cooperative splicing is possible
- Channel updates can be done in a single message
- Sender has to backup trigger transaction (only at channel creation & splice)
- Sender can only send
- Receiver can only receive
- Receiver must watch the chain for trigger transactions
Conclusion about unidirectional payment channels
- Very simple, and have especially low risk and requirements for the sender
- Limited in functionality (Sender can only send, receiver can only receive)
- Could be a great on-boarding tool, if we fill in the gaps with ecash/trust
Ecash: Filling in the gaps
Scenario: Sender (S) receives a large payment onchain (monthly salary) and wants to now continuously spend his salary in the following month.
- S uses UTXO to create a one-way channel to mint (R)
- After channel is opened S can swap some of his channel balance for ecash from R
- S uses ecash to make payments on the lightning network through R's mint service
- S can receive payments into the mints custody, as ecash
- If S has too much ecash, he can ask the mint to create a new channel for him, to move the funds into self-custody
Understanding the Cashu ecash mint:
Receiving a payment
Ecash user
Lightning user
Mint
Understanding the Cashu ecash mint:
Receiving a payment
Ecash user
Lightning user
Mint
Ecash user ask mint to create lightning invoice
1
Understanding the Cashu ecash mint:
Receiving a payment
Ecash user
Lightning user
Mint
Ecash user ask mint to create lightning invoice
1
Mint creates invoice and sends it to ecash user
2
Understanding the Cashu ecash mint:
Receiving a payment
Ecash user
Lightning user
Mint
Ecash user ask mint to create lightning invoice
1
Mint creates invoice and sends it to ecash user
2
Understanding the Cashu ecash mint:
Receiving a payment
Ecash user
Lightning user
Mint
Ecash user ask mint to create lightning invoice
1
Mint creates invoice and sends it to ecash user
2
Ecash user sends lightning invoice to lightning user
3
Understanding the Cashu ecash mint:
Receiving a payment
Ecash user
Lightning user
Mint
Ecash user ask mint to create lightning invoice
1
Mint creates invoice and sends it to ecash user
2
Ecash user sends lightning invoice to lightning user
3
Lightning user pays invoice through the lightning network
4
Understanding the Cashu ecash mint:
Receiving a payment
Ecash user
Lightning user
Mint
Ecash user ask mint to create lightning invoice
1
Mint creates invoice and sends it to ecash user
2
Ecash user sends lightning invoice to lightning user
3
Lightning user pays invoice through the lightning network
4
Understanding the Cashu ecash mint:
Receiving a payment
Ecash user
Lightning user
Mint
Ecash user ask mint to create lightning invoice
1
Mint creates invoice and sends it to ecash user
2
Ecash user sends lightning invoice to lightning user
3
Lightning user pays invoice through the lightning network
4
Understanding the Cashu ecash mint:
Receiving a payment
Ecash user
Lightning user
Mint
Ecash user ask mint to create lightning invoice
1
Mint creates invoice and sends it to ecash user
2
Ecash user sends lightning invoice to lightning user
3
Lightning user pays invoice through the lightning network
4
Ecash user creates blinded tokens locally and sends them to the mint for signing
5
Understanding the Cashu ecash mint:
Receiving a payment
Ecash user
Lightning user
Mint
Ecash user ask mint to create lightning invoice
1
Mint creates invoice and sends it to ecash user
2
Ecash user sends lightning invoice to lightning user
3
Lightning user pays invoice through the lightning network
4
Ecash user creates blinded tokens locally and sends them to the mint for signing
5
Understanding the Cashu ecash mint:
Receiving a payment
Ecash user
Lightning user
Mint
Ecash user ask mint to create lightning invoice
1
Mint creates invoice and sends it to ecash user
2
Ecash user sends lightning invoice to lightning user
3
Lightning user pays invoice through the lightning network
4
Ecash user creates blinded tokens locally and sends them to the mint for signing
5
Mint checks if lightning payment completed. If yes, issues signatures on blinded tokens
6
Understanding the Cashu ecash mint:
Receiving a payment
Ecash user
Lightning user
Mint
Ecash user ask mint to create lightning invoice
1
Mint creates invoice and sends it to ecash user
2
Ecash user sends lightning invoice to lightning user
3
Lightning user pays invoice through the lightning network
4
Ecash user creates blinded tokens locally and sends them to the mint for signing
5
Mint checks if lightning payment completed. If yes, issues signatures on blinded tokens
6
Understanding the Cashu ecash mint:
Receiving a payment
Ecash user
Lightning user
Mint
Ecash user ask mint to create lightning invoice
1
Mint creates invoice and sends it to ecash user
2
Ecash user sends lightning invoice to lightning user
3
Lightning user pays invoice through the lightning network
4
Ecash user creates blinded tokens locally and sends them to the mint for signing
5
Mint checks if lightning payment completed. If yes, issues signatures on blinded tokens
6
Ecash user unblinds the signed blinded tokens locally, and creates the ecash
7
Understanding the Cashu ecash mint:
Receiving a payment
Ecash user
Lightning user
Mint
Ecash user ask mint to create lightning invoice
1
Mint creates invoice and sends it to ecash user
2
Ecash user sends lightning invoice to lightning user
3
Lightning user pays invoice through the lightning network
4
Ecash user creates blinded tokens locally and sends them to the mint for signing
5
Mint checks if lightning payment completed. If yes, issues signatures on blinded tokens
6
Ecash user unblinds the signed blinded tokens locally, and creates the ecash
7
The receive process is completed for the mint once the mint has issued the signatures and for the ecash user once he has unblinded the signed tokens
!
Understanding the Cashu ecash mint:
Sending a payment
Ecash user
Lightning user
Mint
Understanding the Cashu ecash mint:
Sending a payment
Ecash user
Lightning user
Mint
Lightning user creates invoice
1
Understanding the Cashu ecash mint:
Sending a payment
Ecash user
Lightning user
Mint
Lightning user creates invoice
1
Lightning user sends invoice to ecash user
2
Understanding the Cashu ecash mint:
Sending a payment
Ecash user
Lightning user
Mint
Lightning user creates invoice
1
Lightning user sends invoice to ecash user
2
Ask mint to pay invoice, and invalidating ecash for the same amount
3
Understanding the Cashu ecash mint:
Sending a payment
Ecash user
Lightning user
Mint
Lightning user creates invoice
1
Lightning user sends invoice to ecash user
2
Ask mint to pay invoice, and invalidating ecash for the same amount
3
Mint sends payment through the lightning network to the lightning user
4
Understanding the Cashu ecash mint:
Sending a payment
Ecash user
Lightning user
Mint
Lightning user creates invoice
1
Lightning user sends invoice to ecash user
2
Ask mint to pay invoice, and invalidating ecash for the same amount
3
Mint sends payment through the lightning network to the lightning user
4
Understanding the Cashu ecash mint:
Sending a payment
Ecash user
Lightning user
Mint
Lightning user creates invoice
1
Lightning user sends invoice to ecash user
2
Ask mint to pay invoice, and invalidating ecash for the same amount
3
Mint sends payment through the lightning network to the lightning user
4
Understanding the Cashu ecash mint:
Sending a payment
Ecash user
Lightning user
Mint
Lightning user creates invoice
1
Lightning user sends invoice to ecash user
2
Ask mint to pay invoice, and invalidating ecash for the same amount
3
Mint sends payment through the lightning network to the lightning user
4
If payment succeeded, invalidate ecash
5
Understanding the Cashu ecash mint
Understanding the Cashu ecash mint
Receiving a payment as ecash, is what we call a "swap-in", as we are swapping sats from lightning into ecash
Understanding the Cashu ecash mint
Receiving a payment as ecash, is what we call a "swap-in", as we are swapping sats from lightning into ecash
Sending a payment is considered a "swap-out", as we are swapping ecash for sats on lightning
Understanding the Cashu ecash mint
Swaps can be done with what we call "methods". The examples before, use the "Bolt 11" method (lightning invoices)
Understanding the Cashu ecash mint
Swaps can be done with what we call "methods". The examples before, use the "Bolt 11" method (lightning invoices)
We can add other "swap methods", adding more ways to create and redeem ecash
Understanding the Cashu ecash mint
Opening an unidirectional channel with a mint, would open up a new method for easy "swap-ins" from on-chain sats
Understanding the Cashu ecash mint
Opening an unidirectional channel with a mint, would open up a new method for easy "swap-ins" from on-chain sats
On-chain "Swap-outs" will be more costly, since each swap requires an on-chain transaction
Mint and one-way channel
One way channel swaps
Ecash user
Lightning user
Mint
Mint and one-way channel
One way channel swaps
Ecash user
Lightning user
Mint
Ecash user uses onchain utxo to open new one-way channel
1
Mint and one-way channel
One way channel swaps
Ecash user
Lightning user
Mint
Ecash user uses onchain utxo to open new one-way channel
1
Ecash user swaps some of the channel balance for custodial ecash
2
Mint and one-way channel
One way channel swaps
Ecash user
Lightning user
Mint
Ecash user uses onchain utxo to open new one-way channel
1
Ecash user swaps some of the channel balance for custodial ecash
2
Mint and one-way channel
One way channel swaps
Ecash user
Lightning user
Mint
Ecash user uses onchain utxo to open new one-way channel
1
Ecash user swaps some of the channel balance for custodial ecash
2
Ecash user can use ecash to pay lightning invoices
3
Mint and one-way channel
One way channel swaps
Ecash user
Lightning user
Mint
Ecash user uses onchain utxo to open new one-way channel
1
Ecash user swaps some of the channel balance for custodial ecash
2
Ecash user can use ecash to pay lightning invoices
3
Receiving via lightning works in reverse, receiving funds as custodial ecash
4
Mint and one-way channel
One way channel swaps
Ecash user
Lightning user
Mint
Ecash user uses onchain utxo to open new one-way channel
1
Ecash user swaps some of the channel balance for custodial ecash
2
Ecash user can use ecash to pay lightning invoices
3
Receiving via lightning works in reverse, receiving funds as custodial ecash
4
Ecash's privacy properties break down if swaps are immediately followed by a payment of the same amount. To have better privacy, users can hold a small balance in ecash so that they don't need to do a swap when making a payment
!
Mint and one-way channel
Splicing
Ecash user
Mint and one-way channel
Splicing
Ecash user
If user runs out of channel funds, he can do a cooperative splice with the mint
1
Mint and one-way channel
Splicing
Ecash user
If user runs out of channel funds, he can do a cooperative splice with the mint
1
| Splice TX | |
|---|---|
| Inputs | Outputs |
| S utxo [3 ₿] S sig Funding utxo [4 ₿] S+R sig |
S + R [3 ₿] R [4 ₿] |
In this example, the user splices in 3 ₿ from his utxo, and the mint splices out 4 ₿ to his address
2
Mint and one-way channel
Splicing
Ecash user
If user runs out of channel funds, he can do a cooperative splice with the mint
1
In this example, the user splices in 3 ₿ from his utxo, and the mint splices out 4 ₿ to his address
2
| Splice TX | |
|---|---|
| Inputs | Outputs |
| S utxo [3 ₿] S sig Funding utxo [4 ₿] S+R sig R utxo [2 ₿] R sig |
S + R [5 ₿] R [4 ₿] |
To return ecash into self custody, the mint can commit the funds to the channel splice in return for invalidating the ecash
4
Unidirectional channel swap-ins
Using Roose-Childs channel
- Sender does not need to be part of the lightning network to interact with the network
- Sender can commit as much sats into custody as comfortable
- Funds held in channel are always safe for sender (no liveness or state handling required)
- Sender (still) relies on mint to redeem ecash
- Receiving is (still) fully custodial
- Ecash Swap-outs require always an on-chain transaction
Keep in mind...
- This is not meant to replace self custodial lightning
- It is a tool to fill the gap where self custodial lightning is not feasible
- Each system has its own trade-offs
Thank you!
Zap me on nostr