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

/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!