ecash mint using unidirectional payment channels: node-less lightning wallet

Author: lukechilds

Source: https://gist.github.com/lukechilds/307341239beac72c9d8cfe3198f9bfff

Overview

This proposal introduces a self-custodial credit system that can be installed in front of existing eCash Mints. User balances are held in a trustless credit contract that can be instantly (e.g. at the time of payment) exchanged for eCash Tokens on the off-chain. The custodial risk only exists during the processing of a payment, which is typically just a few seconds, and only for the amount currently being transferred. User balances are always self-custodial, and if the Mint disappears or refuses to cooperate, users can unilaterally exit and retrieve their credits on-chain.

This protocol can be implemented on the current Bitcoin, without any soft forks or new opcodes. In fact, it doesn't require any opcodes at all. The entire protocol is almost entirely off-chain, with all possible executions of this trustless credit contract resulting in a MuSig2 taproot key path spend, without needing to use Bitcoin Script.

Problem

A typical user flow is for a user to receive their salary and deposit a month's worth of spending money into an eCash Mint, then gradually initiate small payments from the Mint. This monetary flow is largely one-way, with end-users rarely receiving money other than their salary.

If a user needs to make 4 transactions of $10 per day, that's 120 transactions per month totaling $1,200. They can deposit $1,200 worth of funds into an eCash Mint at the start of the month and freely spend from there. This system makes sense as it compresses 120 economic transactions per month into a single on-chain transaction.

The downside is that this efficiency comes at a huge risk. All balances are custodied by the Mint, and users must trust them not to steal the funds. If a Mint has 1,000 users doing this, they are custodying a total of $1.2 million. This is a significant amount that the Mint operators may be tempted to abscond with. Even if the Mint operators are honest, attackers may target them.

Solution

Instead of having the Mint custody the balances, we can hold the funds in a trustless credit contract between the user and the Mint. These credits are self-custodial, and both the user and Mint can unilaterally exit the contract without the other's cooperation. The credits can be instantly delivered off-chain to the Mint in exchange for eCash Tokens. Only at the time of payment are the credits used to acquire eCash Tokens, and those eCash Tokens are immediately spent. While custodial risk still exists, it only exists during the processing of a payment (typically just a few seconds), and only for the value being used in the transaction.

This trustless credit system can be implemented using Spillman payment channels (a unidirectional payment channel). Spillman channels never gained popularity because they have two major downsides: they are unidirectional, and they expire at a predetermined time. However, these downsides are not problems for our use case. Since users are primarily spending, not receiving, the unidirectional nature is not an issue. And since users need to deposit funds into the Mint monthly anyway, having the channels only last a month is not a worse user experience.

With these downsides not being issues, the benefits of Spillman channels become very clear. For users, there is no need to run a node, no online requirements, no complex state backup needs, and no managing of receiving limits. Users simply deposit funds into a channel; send pre-signed transactions to the Mint, and can pay through the channel.

In this protocol, we propose a new variant of Spillman channels, leveraging new Bitcoin features to improve privacy and efficiency. We implement the Spillman channels such that any possible spending condition can be satisfied through a MuSig2 taproot key path spend. The downside is that payments require interaction between the parties, but since interacting with the Mint is already required to issue eCash Tokens, this doesn't add much complexity.

Protocol

The trustless credit contract is a 2-of-2 MuSig2 multisig arrangement between the user and the Mint. The user provides funding for the contract sufficient for a month's worth of spending, but does not broadcast this funding transaction yet. The user then creates a refund transaction, sending all the contract's balance back to the funding, but with an nLockTime (absolute time lock) set to one month in the future. This refund transaction must be signed by both the user and the Mint. This is the user's unilateral exit transaction. Once the refund transaction is signed, the user can safely broadcast the funding transaction. After the funding transaction is confirmed, the trustless credit contract is activated, and the user has a month's worth of spending funds in the form of credits at that Mint.

To initiate a payment through the Mint, the user must convert the trustless credits to the Mint-trusted eCash Tokens. The user creates a new transaction, spending the funding transaction, sending the Mint the requested number of credits, and returning the remaining balance to themselves. The user will create a musig fragment signature and send it to the Mint; the Mint will aggregate their own fragment signature to obtain a valid signature. The Mint will not return their fragment signature (or the valid signed transaction) to the user. This is the Mint's unilateral exit transaction, which they can use at any time to trustlessly execute the credit contract. The Mint then credits the user the same amount of eCash Tokens. These Tokens have custodial risk, but the user can immediately spend them, returning to a fully self-custodial state (with the remaining balance held in the trustless credit contract).

The next time the user wants to make a payment, they repeat the process, creating a new transaction spending the funding transaction, replacing the old one. The new transaction will pay the Mint the amount from the previous transaction plus the new amount. Since each state update forms a new unilateral exit transaction for the Mint, and the new transaction is always more valuable than the old one, the Mint only needs to keep the latest unilateral exit transaction, without needing to manage complex state.

At the end of the month, this trustless credit contract can be extended for the next month, with additional credits deposited. The user and Mint jointly sign a transaction spending the funding transaction, paying the Mint for the credits used in the previous month, and depositing the remaining balance into a new contract for the next month. The user can add new inputs to this transaction to deposit additional credits into the new contract. Ultimately, there is only one on-chain transaction per month, which both deposits new credits for the next month and pays the Mint for the credits used in the previous month.

All executions of this trustless credit contract - unilateral exit, cooperative exit, cooperative extension - are just MuSig key path spends, leaving a very minimal on-chain footprint. No script paths are used for any form of contract execution, so on-chain observers won't see anything about the contract.

Leave this trustless credit contract

The parties can also cooperatively exit this contract at any time. The Mint can unilaterally exit at any time with the latest state. Users can only unilaterally exit after the contract fails. Importantly, if the contract is not cooperatively closed, the Mint must unilaterally exit before the contract fails, otherwise users can unilaterally exit and take back all the funds in the contract.

Further Thoughts

Privacy Impact

One of the best things about eCash is the near-perfect privacy it provides. Part of the reason for this privacy is the silent time you spend in the Mint. If you use this protocol to pay other users within the same Mint, you can maintain privacy. However, if you use this protocol to pay a Lightning invoice outside of the Mint, you will not inherit the privacy properties of eCash. You will still get good on-chain privacy and sender privacy in the Lightning network. However, it is easy for the Mint operator to analyze the timing and amounts of the credit-token swaps into the Mint and the token-Lightning payment swaps out of the Mint. From the Mint operator's perspective, you have no privacy.

However, this can be solved by holding a small custodial eCash token balance in the Mint. For example, holding around 95% of the balance in the trustless credit contract, and 5% of the balance in the form of eCash tokens, can obfuscate the relationship between the amounts and break the timing/amount correlation of the in/out Mint flows. You can regain the excellent privacy of eCash, only exposing 5% of the balance to custodial risk. Interestingly, this is configurable by the user. Users can adjust this ratio based on their own preferences for privacy/custodial risk.

No Trustless Receiving

This protocol enables a trustless payment experience, but does not bring a trustless receiving experience. As mentioned in the standard usage flow earlier, receiving may not be something many users do frequently, so it may not be a problem. Users can directly receive the custodial eCash tokens and then prioritize spending them (delaying the use of credits).

For example, if a user needs to make 4 transactions of $10 per day, they would need a maximum of $1200 per month for spending. If one of their payments is refunded, only $10 would be exposed to custodial risk (0.8% of their total balance), and only for 1/4 of a day (they will soon have the opportunity to spend the money).

Extending to Trustless Receiving

The protocol can be replicated in the reverse direction to enable a trustless receiving experience, but I believe this is overly complex and, for the reasons already explained, unnecessary. It may be meaningful for merchants who want to receive payments through eCash Mints. In this case, the Mint would become a fast, micro, minimally trusted payment hub between users and merchants.

You could set up a reverse trustless credit channel from the Mint to the merchant. In this reverse construction, the Mint must pre-provision liquidity to the merchant and charge the merchant. The merchant needs to trust that the Mint will not steal the payments in-flight, but once the payment arrives, the balance is self-custodied; and if the Mint does not cooperate, the merchant can unilaterally exit the contract and take the funds. If the merchant forgets to close or delays the contract before it expires, the Mint can steal the payments received in the last month.

Due to the additional complexity of this reverse construction, I don't think it has a clear advantage over merchants directly using Lightning channels.

Liquidity

This protocol does not impose additional liquidity requirements on the Mint. If a Mint already has many custodial users and non-custodial users, as these users intermittently add and spend credits, the Mint is unlikely to encounter liquidity issues. However, if a large number of non-custodial users suddenly arrive and all try to make large payments through the Lightning network, the Mint's Lightning payment capacity could be depleted.

Note that in this case, the Mint cannot use a fractional reserve scheme, it must have sufficient funds to handle user withdrawal demands, it just has a portion of its funds locked in the credit contracts. If funds leave the Mint, the Mint may need to close some credit contracts to pay out other users' withdrawals. Since closing contracts with users is cumbersome, the Mint can avoid this by maintaining additional flexible funds, or outsource the Lightning payments to a third party and settle monthly.

Contract Expiration

The duration of a contract can be arbitrary. We propose one month, just to align with the typical accounting pattern of monthly payroll. However, this means that a on-chain transaction is needed every month to keep the credit contract open, even if there is a large balance in the credit contract. The expiration time could be extended to one year, so the contract remains open for the entire year. However, this has a downside, if the Mint is unwilling to cooperate, the user's funds will be locked for up to a year. This may be a reasonable trade-off, as in the current custodial model, if the Mint does not cooperate, all funds would be lost. Locking for a year is still a significant improvement.

Acknowledgements

Thanks to @tiero and the @ArkLabsHQ team for their research on the role of Spillman channels in Ark, which guided me to the ideas in this protocol.

Thanks to @moonsettler and his research on using credit-based eCash to solve the same problem, which helped me connect all the pieces.