Is it possible to link ecash mints to the lightning network without losing ecash’s anonymity or adding any additional trust? I believe it is. (This is an expansion of a tweet)
Background
Lightning uses HTLCs to make atomic payments: that is you have a tuple (H, T, A) of a hash, timeout and amount, that is atomically resolved by revealing a preimage P where H is the result of running sha256 over P.
Ecash used a blind mint, where the mint issues coins that are backed by its holding of bitcoin, and payments are authorised by revealing a pair (K, S) where S is a blind signature of K calculated as m\cdot H2C(K) with m being the mint’s private key.
The mint is trusted in three ways:
- it’s trusted not to lose/spend/steal all the funds backing the coins it issues;
- it’s trusted to correctly use its private key when doing blind signatures; and
- it’s trusted to accept coins it issues either to replace them for new coins when ecash is being transferred to a new owner, or to redeem it for the bitcoin it’s backed by.
What we’d like is to be able to both pay the mint over lightning for issuing new tokens, and to redeem existing tokens for bitcoin to be received over the lightning network.
Model
Because ecash transactions naturally require the mint to be involved, either to validate the coin has not already been spent or to mint a new coin, we only consider a random bitcoin user interacting with the mint over lightning.
Because different cryptography schemes are involved (hashing for lightning, blind signatures for ecash) we use a zero-knowledge contingent payment.
Issuing new ecash
First, we’ll consider sending bitcoin over lightning and receiving ecash. For this, the user will first need to calculate a random blinded challenge for the mint as normal (ie, A = H2C(K) + rG). This should be sent to the mint out of band, who will calculate:
- B = mA
- H=SHA256(B)
- Z a ZKP that it knows a value m such that H=SHA256(mA) and M=mG where M,A,H are public parameters and m is private.
Z is provided back to the user, along with a lightning invoice to pay the HTLC (H,T,A). If the user pays the invoice, they obtain the preimage B=mA and can unblind the signature (calculating C=B-rM), giving them ecash, and the mint’s bitcoin balance increases by A.
Because the mint is trusted anyway, it is probably fine for the mint to perform a trusted setup for the zero-knowledge proofs here. After all, if the mint wants to steal funds, it can just spend the bitcoin, and shut all its servers down – no fancy cryptography required. However, if the zero-knowledge system did not require a trusted setup, I think this would remove the second element of trust in the mint (“it’s trusted to correctly use its private key when doing blind signatures”) – that is, the mint would not be able to do an invalid blind signature, resulting in an invalid token being held by the user.
Redeeming ecash
In order to redeem ecash, you provide C,K and the mint checks that C is a signature for K (ie that C=m\cdot H2C(K)), and then logs K as having been spent. In order to do use this to atomically release funds over lightning, the following protocol should work:
- user sends an invoice for redeeming the coin denominated by K
- mint calculates the correct signature C=m\cdot H2C(K) and the hash H=SHA256(C)
- mint sends an HTLC of (H,T,A) to the user, paying the invoice provided the user does have the correct blinded signature C
- user claims funds A by revealing preimage C
- once the HTLC resolves, the mint marks K as having been spent (NB: while the HTLC is unresolved, K must be marked as reserved, otherwise there is a risk of a doublespend)
(No ZKP seems to be required for this direction)