calle's avatar
calle
calle@cashu.me
npub12rv5...85vg
DM @callebtc:matrix.org
calle's avatar
calle 5 days ago
iโ€™m just sitting in my car and waiting for my girl
calle's avatar
calle 5 days ago
nostr is. stop panicking.
calle's avatar
calle 5 days ago
How about fully-private Hermes and OpenClaw agents in TEEs with end-to-end encrypted AI inference? When used with a secure messenger (not Telegram), this could enable agents with incredible security and full-stack privacy.
calle's avatar
calle 6 days ago
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: - Minimize rug risk (ideally to ~0) - Push operators toward non-custodial status # Risk 1: Malicious mint updates Users can verify the software running inside a TEE, but operators could later deploy a malicious fork. Potential mitigations: - Infrastructure provider enforces which software may be deployed. - Separate KMS with policies from the TEE allowing only audited/signed software to access keys. - Immutable mint: disable updates entirely. Upgrades require deploying a new mint and users migrating funds, similar to smart contracts. # 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: - Append-only storage enforced by the TEE/provider so spent notes can never be erased. - Seal the database inside the enclave and prevent external access. Combined with update protection, this appears to eliminate rollback attacks. # Risk 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. # Conclusion 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.
calle's avatar
calle 6 days ago
LNbits doesn't let you set the max fee for Lightning payments and is therefore inherently unsafe to build applications on top of it, so we're going to end support for it. If you're using nutshell with LNbits, connect your mint to your Lightning node directly.
calle's avatar
calle 6 days ago
gm, stfu and build something better ๐ŸŒž
calle's avatar
calle 6 days ago
Opinions in Bitcoin are expressed by running software, not by voting.
calle's avatar
calle 1 week ago
hahahahahahahahaah ๐Ÿคฃ
calle's avatar
calle 1 week ago
let's imagine the mint would publish a merkle root of their spend book and anyone who can produce a non-inclusion proof of their ecash can withdraw unilaterally. ordinary ecash tx's would have to slow down to the speed of the merkle root updates, or else they would race against the unilateral withdrawal request? not great. maybe instead, the withdrawal could be slowed down and give the mint time to cancel the request in case the same token gets spend as normal ecash?
calle's avatar
calle 1 week ago
If we had Merkle trees in Bitcoin script, we could publish the Merkel root of a mint's spend book on-chain and give users who can prove non-inclusion a way to withdraw unilaterally.
calle's avatar
calle 1 week ago
bitcoin is open source money
calle's avatar
calle 1 week ago
@routstr you should check out cashu payment channels, I think you might like it
โ†‘