My understanding of mint auditing is that it is relatively easy to prove how much bitcoin a mint has. It is much more difficult, though, to prove how many tokens it has issued against that bitcoin.
So far, ecash mints have mostly shrugged or recommended automated bank runs (a scheme I understood to mean everybody rotating out of a mint at random intervals to force the mint to always have enough bitcoin on hand).
Here is a new proposal for a specification for proof of liabilities in a Cashu mint. This is based on the concept that @calle proposed back in 2023 (A Proof of Liabilities Scheme for Ecash Mints). There is now a specification and a working implementation.
The main elements are:
- Fixed-Size Merkle Sum Trees: Commits to the token set and total amount simultaneously.
- Epoch Chaining: Daily epochs linked by previous_epoch_hash to ensure historical immutability.
- OpenTimestamps (OTS): Anchoring the final daily hash to the Bitcoin blockchain for tamper-evident timestamps.
The mint keeps the blind signatures that attest to issued ecash tokens as well as a list of spent secrets (burned tokens).
The mint periodically and publicly releases the list of blind signatures, that we call mint proofs and the list of spent secrets called burn proofs. Therefore, these lists attest to the ecash outputs and inputs of the mint respectively. We will see how these two lists must remain balanced and how users can detect, and in some cases prove, whether the mint either refused adding legitimate entries or added fake ones.
If these reports are published somewhere that is highly available (such as on Bitcoin via OpenTimeStamps), then
In the case of an honest mint, the total amount attested for in the mint proofs will be equal to the value of all issued ecash tokens and the total amount of the burn proofs will be equal to the redeemed tokens. The difference between the two is the aggregate outstanding balance in all user wallets. The outstanding balances are the mint's liabilities to its users in the form of ecash and must be less or equal to a proof of reserves report the mint provides separately.
There are two ways that a mint might try to cheat:
The first way a mint might cheat:
A cheating mint will want to publish as few blind signatures (mint proofs) as possible in order to disinflate its liabilities. If Cashu wallets keep all blind signatures they received from the mint during that keyset epoch in their database, they can publicly prove that they obtained a blind signature from the mint that was not listed in the mint proof list. That way, a single user can call out a mint if they don't find their blind signature in the PoL reports.
If this happens, a user needs to prove that they have a valid signature from the mint: The user who contests the report provides a discrete-log equality (DLEQ) proof, which allows others to verify the signature is indeed from the mint.
The second way a mint might cheat:
The second way a mint could lie about its PoL report is to include fake burn proofs in its list of spent secrets. Essentially, a mint could spin up a wallet and spend unbacked ecash which it then reports in its burn proof list. That way, a mint can artificially increase the amount of allegedly redeemed ecash and shrink the outstanding balance that it reports.
In order for a user to catch the mint at artificially inflating its list of burn proofs, users can also check whether their spent secrets are included in this list. If the outstanding balance reported for a past keyset is less than the secrets a user or multiple users reveal, the mint must have added fake entries to the list. Essentially, a mint can only artificially inflate the burn proofs and remain undetected up to its best guess for ecash that was lost or forgotten by its owners. Any attempt to further inflate the list can be contested against by users who can prove that they either held or still hold ecash from this epoch that is unaccounted for. Importantly, a user can only prove that the mint is cheating, if they can provide a set of tokens whose sum is worth more than the outstanding balance that is reported. This is due to the fact that a user might simply claim that the mint didn't include their ecash although they never attempted to actually burn it.
I don't think this scheme is perfect (a mint could still shotgun kyc, or rug everyone) -- indeed calle points out a number of flaws in his original post, but it is an improvement and it's cool to see an implementation in the wild.