The FROST basis for this new design enables composability across the ecosystem, with @bitcoindevkit to power onchain, and Bark (@secondhq) to power the Lightning! @callebtc @btcplusplus

Why multiple implementations make sense for security beyond a certain point:

/goal git.cashu.dev/thesimplekid/a…

/goal git.cashu.dev/thesimplekid/a…

Calling on fellow cypherpunks to build alternative Fedimint implementations. The Liquid hack shows once again that single points of failure are what will break our systems and that includes the code we write. Security is an asymmetric game: an attacker has to find one weakness, while defenders have to find all. AI has permanently changed the attacker-defender balance for the worse. This is a fundamental problem for the entire freedom tech space and only mitigatable by aggressively reducing single points of failure. Federations are meant to do exactly that, but just like Liquid, Fedimint shares the “single implementation” problem. If we still want to bring privacy and freedom to the world we need to work together more than ever to reduce these single points of failure. For me that means seeking help to bootstrap independent Fedimint implementations. We are still early, but I've started extracting a specification that others could build off and would love to collaborate with any fellow cypherpunks who want to join us in that mission. In particular, I’d love to work with @callebtc and the @CashuBTC team, who have much more experience with a multi-implementation ecash protocol while the Fedimint team brings federation experience to the table. While AI exposes existing vulnerabilities and wreaks havoc in our ecosystem, it is also an opportunity for talented engineers to be far more productive than ever before. I’ve been talking with @fedibtc and there is funding for a small, crack team to pull this off. If this sounds interesting as a funder, please reach out! The idea is for the teams to be purposefully disconnected from the existing Fedimint implementation and to work autonomously, communicating mainly through the spec process. If you too believe that privacy and freedom are needed more than ever, please join us!

A topic this critical deserves my first long-form post. The real question is not trusted vs trustless. It's how many independent things have to go wrong before you lose money. @TheBlueMatt said it in one sentence. Run the same software, suffer the same bugs. ⬇️ Think about what actually happened. Liquid was an 11-of-15 multisig. Fifteen independent signers. No keys were compromised. Nevertheless, eleven honest signers approved a withdrawal that emptied 95% of the reserves, because every one of them was running the same code, and the code had the same bug. A few weeks before that, one firmware flaw swept thousands of Coldcard cold wallets. Different product, same lesson from the other side.
 Before anything else, none of this is abstract. Coldcard victims lost savings they stacked over years. LBTC holders woke up to frozen funds through no fault of their own. And anyone who has ever shipped code that holds other people's money can and should empathise with the engineers at Blockstream. I do. But we have to be honest with ourselves here. The world has changed. AI tooling is surfacing bugs that sat dormant for years, a point Matt also made after Coldcard. Five year old vulnerabilities are getting weaponised. Supply chains are getting attacked. "Secure so far" doesn't mean much anymore. So let's also retire a comforting fiction. There is no such thing as “trustless.” There never was. It was always shorthand for trust-minimised. Every system puts trust somewhere: in code, in firmware, in the people who write, ship, and run both. Liquid users trusted Elements. Coldcard users trusted a random number generator they never saw. Don't get me wrong. We should keep doing everything possible to make our code, our systems and the people behind them as trustworthy as we can. Audits, reviews, security culture, all of it. But trustworthiness is not the same thing as fault tolerance, and we need both. Fault tolerance only comes from having independent failure domains. In other words, no single point of failure. So what does this look like in practice: 1. Multiple implementations of every protocol that holds funds, with the power to reject and not just observe. 2. Multiple wallet implementations. We mostly have this already. 3. Keys generated on hardware from different vendors. 4. Multiple independent, trustworthy humans behind every system that holds money. 5. Geographic and jurisdictional distribution as one jurisdiction's rules can change overnight.  And to be clear, Matt's sentence currently applies to @Fedimint too. Fedimint was designed to remove single humans and single institutions as points of failure. That's the whole point of a constellation of federations. But today there is only one implementation of the protocol: every guardian runs the same software. Federated humans, monoculture code, and it's not good enough. So I'm calling on the Fedimint community to lead by example and fix this as quickly as we can. And to everyone else, tell me where I'm wrong. If I am, propose something better. If I'm not, then let's stop debating trusted vs trustless and start demanding independence at every layer. Software, hardware, humans, jurisdictions. All the way down. That's how Bitcoin stays worth the highest confidence as we enter this new age.

Fedimint v0.12.0 "Second Nature" is here! 🚀 The highlights: * v2 modules (lnv2, mintv2, walletv2) now the default for new federations ✨ * Much lower Lightning payment latency ⚡️ * @iroh_n0 1.0 networking 🌐 * Wallet recovery without downtime 🔄 github.com/fedimint/fedimint…