Nice writeup, I especially like the “Issuing new ecash” part. We had thought of implementing something similar in Cashu in the issuing process but decided against implementing it for now because it would require more interaction with the user’s lightning wallet (they need to obtain the preimage in their Lightning wallet, then use it in their ecash wallet).
However, good news: we already have a ZKP implemented as a proof of knowledge of m as a DLEQ proof, which you can find here: nuts/12.md at 94a621d1014a8687269f58ecadc5ef167dce546f · cashubtc/nuts · GitHub
As far as I can see, your construction is missing a crucial part though: the transferrability of these tokens from user to user without the mint being able to link the transfer to the Lightning invoice (i.e., keeping the ecash privacy intact). Since the mint does not know the K the user requests a signature on, it’s hard to make sure that the claim of a token remains intact when passed form user to user (and all sorts of other issues arise, such as Alice being able to re-mint a token committing to the same invoice again using a different r after having sent it to another user Carol).
This has been the main challenge for my research in the past months. Good news though, I think I’ve found a way to do it and will write it up once I have the code to show it’s viable. The rest is almost exactly as you propose it here.
I really enjoyed reading this, cheers!