Replies (111)
That's nuts! Great work 💪
How does it look like from client perspective?
Will mint client be able to tell easily if he's using legacy or TEE mint?
Keys within TEE's are relatively trivial to extract, using sidechannels.
What if the TEE dies? How does one recover it?
Is it interoperable with inflatable versions?
Seu lindo.
👀
you gotta threat model this better or else it looks like fud.
is it better/more secure than the previous implementation?
this has officially piqued my interest in running a cashu mint.
Eish 🔥 Legendary 🙌 and keep it up 💪
You can use multiple mints in a wallet if you mean that
Impressive step forward for Cashu—hardware-backed trust minimization could be a game-changer for ecash adoption. Reminds me of how Gulf states are exploring crypto/blockchain to diversify from dollar dependency, though with heavier institutional involvement. Just read a piece on this dynamic.
The Board
Cryptocurrencies in Gulf States: Beyond the Dollar?
Explore how Gulf states are using cryptocurrencies like Bitcoin to diversify beyond the dollar, navigating regulation and risks. Is this the future?
Can't, it's a one-way street. Hyper scaler TEE's don't die though
no u
tell us how you do that with Google cloud or Amazon nitro
eventually, that's the goal. it's doable
🥜
👀
!
🥜🥜🥜
we march on!
🤘
This is extremely exciting. A big move to help reduce blind trust in the mint.
Does this setup open up the possibility for remote attestation?
Fixed and auditable code in these enclaves would be huge. If the wallet can verify the code in the enclave then that reduces opportunities for malicious mint modifications.
Well done ser 🫡
One day local community mints 👌
the trust model of TEE based ecash is jeff bezos won't unplug the computer. not cypherpunk at all my man
yes wallets will be able to verify attestations
Hell yeah. That is a big deal. Less concerns about mint fuckry is definitely directionally good
manifesting such a balenciaga in my wolenje
View quoted note →
" So one solution that came up to that was, let's introduce key epochs. A very simple solution is that we have one set of private keys for the mint that is valid for one year, let's say, and then after one year, we make a cut, and then we rotate the keys to a new set of private keys. And then we slowly rotate all the ecashu from the old epoch to the new epoch. And then once all the ecashu is redeemed from the old epoch, we can just prune it from the database and keep going on with the new key epoch basically. So for scalability reasons we've come up with this rotation of keys initially. Now it turns out that you can use this same mechanism to build a proof of liability system and the way it could work is that the Mint now publishes these two lists that it has. So there is a list of all the blind signatures it gave out and then there is a list of all the secrets that it redeemed. These are two different lists and usually they are kept inside the Mint. No one is interested in them. But now in this new scheme, the Mint could publish these reports, let's say once a month. It would publish a whole list of money I gave out to everyone and the whole list of money I redeemed by everyone. And you could tally it all up. And the end result would be how much money is in all the wallets out there. So if you have all the issued money minus all the redeemed money, that is the open balance of this mint basically. So you would publicly open these, publish these lists and now here comes the kicker, a user that has a wallet now could basically, once these lists, these reports are published, could go back and check whether the money that I ever owned is included in this list or not. "
13 April, 2023
Cashu & Fedimint: ecash, Bitcoin's layer 3 & scalability
There was a time when you considered this as a solution. I liked it. (What led you to abandon it again?)
🤖 Tracking strings detected and removed!
🔗 Clean URL(s):
Cashu & Fedimint: ecash, Bitcoin's layer 3 & scalability
❌ Removed parts:
?utm_source=openai
⚡🤘😎🥳
"i'm running inside a TEE" isn't verification. you have to publish audited, reproducible builds, that generate the key material, and somehow attest that the key was generated inside a process launched from a reproducible build on a TEE, in order to close the loop
and nitro doesn't even provide a means of key attestation. so you can run outside the TEE and just tell people you're running inside one 🤷🏻♂️
TEE's aren't magic. they're a very specific capability, and one that's only valuable to the operator. this is the same problem that lexe and maple ai face
h/t
@semisolI have.
You're moving from 'the mint can rug you' to 'the mint can rug you'.
If you could recommnend one video or document explaining how to use this, what would it be?
The signed attestation document can include custom data and a public key, in Nitro.
But the problem is what happens if the Cashu TEE restarts, where are the keys?
Google / Amazon are in your trust model?
Lol.
will nitro sign that the document originated in the TEE?
but also... right: ecash.
*sigh* the probability of redeeming an ecash token always trends toward zero
can an AWS HSM do the necessary math? you're still bound to the life of a specific HSM, though
yes nitro signs it
no an HSM cannot do the required math for cashu. even if it does, it exposes itself to the risk that it is lied to about the success/failure of payments from the outside LN node, so it must operate as a closed system. also the HSM can just be smashed
an attacker can also just deny access to the mint. they could say that you can get 50% of your ecash back, but only by sending your tokens to them. the user can either do nothing (and lose it) or try (and probably get it back, but also net the attacker money). the second case is the only one that is good for the user
calle
Can't, it's a one-way street. Hyper scaler TEE's don't die though
View quoted note →
or just ghost everyone. my solution to this in bitcoinsdeposits.net is to have public ledgers and funds controlled by someone other than the operator, so if they disappear another node just takes over
couldn't figure out how to do this with blinded payments. i'm not sure it's possible
I wish I was knowledgeable enough on the subject to understand how it works. Maybe some day. Congratulations tho! 🙌
when you're in ecash you have to assume mints last forever or confront the fact that rugging, even in the most honest case, is inevitable
That’s incredible!! Excited to see all the work.
Garbled circuits + BitVM + Dynamic state scrambling
... but the complexity negates trustability.
The only way to have some sort of exit mechanism is full-fledged smart contracts (even then I don't think it is really viable), with *state* that is shared across all transactions that interact with it. And a very efficient execution so that your $30 exit does not cost $200 in fees.
I guess it's all mainly about micro-payments.
Definitely not about store of value.
there is a huge market for this, I would think.
Cypherpunks are flexible ;)
huge movement
don't exit 🤷🏻♂️ build a self healing network that doesn't die
Nut disrespectors just got deez nutz in their mouths
Ark - even covenantsless - is fantastic.
Looking forward to a good implementation of it.
@/dev/fd0 now tell us why this is ruggable
Read about TEE and the security trade-offs.
what happens when the host is restarted?
Hello 👋 I'm a photographer currently working towards upgrading to a Canon EOS R7 so I can capture wildlife and nature in even better 4K quality 📸🌿
If you enjoy my work and would like to support my journey, I'll truly appreciate it. Even sharing my page or engaging with my posts means a lot. Thank you for the support 🤍
wdym they don’t die? all hardware dies eventually
nice but if it can be unplug by others it will
this is awesome!
You accepting ecash?!
Thank you so much for asking 😊 You can send it to lilliannature@minibits.cash I truly appreciate your support for my photography journey 📸🌿
I'll send you some zaps too 🧡
Sent directly to your minibits
Cashu achieves unruggable mints after three years of work using Trusted Execution Environments to generate mint keys that the operator can never access or use to inflate the ecash supply. it matters because this transforms Cashu from a trust-based system to one with hardware-enforced cryptographic guarantees solving one of ecash's fundamental security challenges. Credit to the Cashu developers for the breakthrough.
calle
Huge milestone for Cashu.
After 3 years of work, we finally have unruggable mints.
I'm testing the first on-chain Cashu mint running inside a Trusted Execution Environment (TEE), where the mint keys are generated entirely within the enclave and remain unknown to the operator.
That means the operator cannot inflate the ecash supply and cannot access the Bitcoin reserves backing it.
We've moved from trusting operators to relying on hardware-enforced cryptographic guarantees.
There's still work to do, but the path forward is clear. This is an incredibly exciting step toward trust-minimized ecash.
Thank you for helping grow our privacy infrastructure and innovation in Cashu!
When the mint shuts down, who gets the sats?
This guy is unstoppable
Exactly 💯
Don't worry - he's gonna wear the gimp costume when he signs up for google cloud
Would be awesome learning/testing this live during OFF
Great job. Let's get a full tutorial on this, so that we can test it and red team the new infrastructure. These payment rails will be used by the next generation if successful.
Gwarn G
That sounds great! Well done.
Btw, is that these onchain Zaps I heard people talk about? Just curious
I liked ecash before I knew this breakthrough was possible. Getting rid of its worst trade-off is insane. Congrats to everybody involved!
Shouldn’t you have redundant TEEs that, using remote attestation, copy the keys so that you have a backup?
🫡
from one tee to another?
Weren't you complaining about on chain zaps last week? 👀
Congrats on the milestone!
How does the Lightning channel management work? Is the Bitcoin node within the TEE or external?
🙏🏼
🤯
This is a meaningful step — moving from "trust the operator" to "verify the hardware." The TEE skeptics in this thread are right that it's not fully unruggable (key persistence, hardware lifecycle, hyperscaler dependency all remain), but "trust-minimized" is the honest frame and trust-minimized is real progress.
The throughline here is the same as self-custody: you're always relocating trust, never eliminating it entirely. The goal is to push it toward things that can't easily lie to you.
For my own personal definition of rugging, the attacker need not receive the funds. For example, if a darknet market is shutdown by cops, all the users with funds on it are rugged.
The operator of the market doesn't need to be the recipient of the funds.
Sure if you’re using something that can do remote attestation you know the other TEE is running the same software and you can copy it. Tho I guess maybe replay is an issue?
I don't quite get what your suggestion was.
study history (rpow)
so you have nothing to say?
yes we're doing all that, no idea what you're rambling about
KMS
it has no unilateral exit, you're like 3 years too late
you seem to be an intelligent person, I wonder why you chose to become a reply guy. waste of your intellect.
export the keys... how / why?
u doing Bitcoin development evolution all by yourself basically 😅 keep building Calle! You are an inspiration ✌️
There's no point debating on Nostr, because relays (particularly Primal) are manipulating chat history.
unilateral exit is misguided. maybe try doing the math
don't trust: verify
To support failover you can copy the keys from one TEE to another in a secure manner such that they still cannot leave an equivalent TEE running the same software. The issue of course is if the operator can replay withdraws across the TEEs.
Have a look here
nostr:
View article →Does it mean trust shift from the operator to the cloud provider or his HW supplier?
I would trust more to the local community leader than to AWS or Intel.
What happens when the hardware breaks?
Cashu makes me happy
So cool 🔥
What about the resiliency of the mint? Something goes wrong and you lose everything? Is there a way to backup and restore or have a disaster recovery solution for when things go south without being able to touch people's funds or extract/obtain the keys? I mean we are talking about money here, not some random self host project. Not criticizing here, just being really curious.
I have bad news for you. For one, TEEs are not that good. Two, you are walking on a thin ice when it comes to hardware attestation adoption. Don't. Unless you want to leave a world of digial slavery to your children. Hardware owner has the full right to access data processing in full. Period.
Me too, but I'm having a hard time teaching people about it.
Awesome stuff, thank you 🫡
as opposed to ... building lightning acceptance at square? a bitcoin layer 2? an operating system that's easier to defend than attack?
you think i'm a reply guy because you like talking more than listening, but inconvenient replies catch your attention
Patience and discipline. Cashu will win.
"Unruggable mints via TEEs are a solid step forward—hardware-backed trust is way better than hoping operators won’t misbehave. But I’m still skeptical about how this scales when most ecash use cases still depend on centralized liquidity. Reminds me of how Gulf States are pushing crypto as a dollar alternative while wrestling with similar trust/control tradeoffs.
https://theboard.world/articles/cryptocurrencies-gulf-states-beyond-the-dollar"
(279 chars)
#7
Nostr’s Value4Value (V4V) model is all about plebs directly rewarding creators for the value they receive, no middlemen fees, no ads, just pure community-driven support using sats via the Bitcoin Lightning Network.
Thanks to
ZAPLIFE.LOL
A decentralized Craigslist running on Nostr
by
@PABLOF7z for providing this data.
Here are the Top Zapped/Top Zappers from last week, showcasing the creators who received/sent the most engagement:
🔥 Top 3: Most Zapped
1. Name:
@Fountain Boost Bot
- Zaps Received: 307
- Sats Earned: 513k
2. Name:
@calle
- Zaps Received: 305
- Sats Earned: 55k
3. Name:
@FLASH
- Zaps Received: 255
- Sats Earned: 84k
🔥 Top 3: Most Zappers
1. Name:
@AQSTR
- Zaps Sent: 2733
- Sats Spent: 121k
2. Name:
@FL Justin
- Zaps Sent: 168
- Sats Spent: 50k
3. Name: noderunner
- Zaps Sent: 144
- Sats Spent: 8k
💰 Top 3: Most Sats Received
1. Name:
@Fountain Boost Bot
- Sats Earned: 514k
- Zaps Received: 309
2. Name:
@Anix
- Sats Earned: “Not mentioned correctly”
- Zaps Received: 1
3. Name:
@CapScabio
- Sats Earned: 250k
- Zaps Received: 1
💰 Top 3: Most Sats Sent
1. Name:
@El Gorila 🇦🇷
- Sats Spent: 1M
- Zaps Sent: 6
2. Name:
@Sattrio
- Sats Spent: 180k
- Zaps Sent: 3
3. Name:
@Keith Meola
- Sats Spent: 124k
- Zaps Sent: 38
Here are the Top Zapped from last week, showcasing notes that received the most engagement:
🔥 Top 3: Most Zapped
1.
View quoted note →
- Zaps Received: 80
- Sats Earned: 18k
2.
View quoted note →
- Zaps Received: 47
- Sats Earned: 8k
3.
View quoted note →
- Zaps Received: 46
- Sats Earned: 5k
🔥 Top 3: Most Sats
1.
View quoted note →
- Sats Earned: 211k
- Zaps Received: 17
2.
View quoted note →
- Sats Earned: 130k
- Zaps Received: 3
3.
View quoted note →
- Sats Earned: 121k
- Zaps Received: 4
#most-zapped_nostr_recap
Congratulations for the hard work. Sounds like we could maybe use Blossom to distribute uptime securely and privately and hardware runners charge a fee? Just spit balling.
