Raw JSON

{
  "kind": 1,
  "id": "8c69883e978a0558d5ccaa23c966a2b4070e7556b9d90a4da24e0db3fe4af98c",
  "pubkey": "50d94fc2d8580c682b071a542f8b1e31a200b0508bab95a33bef0855df281d63",
  "created_at": 1780769897,
  "tags": [
    [
      "alt",
      "A short note: Thoughts on unruggable Cashu mints in trusted exec..."
    ]
  ],
  "content": "Thoughts on unruggable Cashu mints in trusted execution environments (TEEs). Sharing current research and looking for feedback.\n\nIdea: Generate Bitcoin reserve keys and Cashu signing keys inside a TEE so operators never access them.\n\nGoals:\n- Minimize rug risk (ideally to ~0)\n- Push operators toward non-custodial status\n\n# Risk 1: Malicious mint updates\n\nUsers can verify the software running inside a TEE, but operators could later deploy a malicious fork.\n\nPotential mitigations:\n- Infrastructure provider enforces which software may be deployed.\n- Separate KMS with policies from the TEE allowing only audited/signed software to access keys.\n- Immutable mint: disable updates entirely. Upgrades require deploying a new mint and users migrating funds, similar to smart contracts.\n\n# Risk 2: Rollback attacks (\"time travel\")\n\nAn operator could restore an old database snapshot, allowing previously spent ecash to be spent again and inflating supply.\n\nPossible mitigations:\n- Append-only storage enforced by the TEE/provider so spent notes can never be erased.\n- Seal the database inside the enclave and prevent external access. Combined with update protection, this appears to eliminate rollback attacks.\n\n# Risk 3: Mint shutdown\n\nThe operator can always turn the mint off, making reserves inaccessible.\n\nPotential solution:\n@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.\n\nDuring normal operation the mint periodically rolls reserves forward, extending the timeout. If it stops, the emergency path activates.\n\nA 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.\n\n# Conclusion\n\nWe 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.\n\nImagine 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.\n\nIt 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.",
  "sig": "b621e365fa89d9aa0d1bbc53af12be62bb63dd24f317f6e8f74c3715affd412ea9a51c094644919b484d30ef1954d3c8e86c04c176da8cf3ad49d48356d33d9b"
}