The operator can always turn the mint off, making reserves inaccessible.
Potential solution:@lukechilds proposed an elegant emergency exit mechanism. Reserve UTXOs contain a secondary spend path that activates after a period of mint inactivity. A third party (e.g. a multisig) holding a copy of the mint database could continue honoring withdrawals.
During normal operation the mint periodically rolls reserves forward, extending the timeout. If it stops, the emergency path activates.
A more ambitious direction is committing the spend book as a Merkle/nullifier tree. With the right scripts, users may be able to withdraw unilaterally by proving their ecash has not been spent. This could largely solve risks 1-3 simultaneously.
We haven't cracked this nut completely yet, but the progress over the last few weeks has been remarkable. The mere existence of plausible solutions is incredibly exciting.
Imagine if we could pull this off. David Chaum invented ecash in the 1980s, and researchers spent decades trying to make it trustless. Then Satoshi invented Bitcoin, and the world largely moved to the blockchain paradigm.
It would be an enormous achievement if we could finally solve the trust problem of Chaumian ecash by rebuilding it on Bitcoin and its more expressive L2s, combining the best of both worlds: a scarce, immutable base layer with trust-minimized ecash on top, offering strong privacy, instant payments, near-zero fees, offline transactions, and amazing UX.
Here's the text of the post in case you don't want to click through:
Thoughts on unruggable Cashu mints in trusted execution environments (TEEs). Sharing current research and looking for feedback.
Idea: Generate Bitcoin reserve keys and Cashu signing keys inside a TEE so operators never access them.
Goals:
Risk 1: Malicious mint updatesRisk 1: Malicious mint updates
Users can verify the software running inside a TEE, but operators could later deploy a malicious fork.
Potential mitigations:
Risk 2: Rollback attacks ("time travel")Risk 2: Rollback attacks ("time travel")
An operator could restore an old database snapshot, allowing previously spent ecash to be spent again and inflating supply.
Possible mitigations:
Risk 3: Mint shutdownRisk 3: Mint shutdown
The operator can always turn the mint off, making reserves inaccessible.
Potential solution:@lukechilds proposed an elegant emergency exit mechanism. Reserve UTXOs contain a secondary spend path that activates after a period of mint inactivity. A third party (e.g. a multisig) holding a copy of the mint database could continue honoring withdrawals.
During normal operation the mint periodically rolls reserves forward, extending the timeout. If it stops, the emergency path activates.
A more ambitious direction is committing the spend book as a Merkle/nullifier tree. With the right scripts, users may be able to withdraw unilaterally by proving their ecash has not been spent. This could largely solve risks 1-3 simultaneously.
ConclusionConclusion
We haven't cracked this nut completely yet, but the progress over the last few weeks has been remarkable. The mere existence of plausible solutions is incredibly exciting.
Imagine if we could pull this off. David Chaum invented ecash in the 1980s, and researchers spent decades trying to make it trustless. Then Satoshi invented Bitcoin, and the world largely moved to the blockchain paradigm.
It would be an enormous achievement if we could finally solve the trust problem of Chaumian ecash by rebuilding it on Bitcoin and its more expressive L2s, combining the best of both worlds: a scarce, immutable base layer with trust-minimized ecash on top, offering strong privacy, instant payments, near-zero fees, offline transactions, and amazing UX.