2026-04-06T08:35:11Zhttps://njump.meNostr notes by techleaks24techleaks24https://njump.me/npub1dnrfq2gva4hzxsj92quywygxp9sl2a5ezfnt034hagm3ap3j9dmq6ker2hhttps://blossom.primal.net/42b2d0d1c31cfec92d70cfb660281810761d924370c7c963a379d5873f39747d.pnghttps://blossom.primal.net/42b2d0d1c31cfec92d70cfb660281810761d924370c7c963a379d5873f39747d.pnghttps://njump.me/nevent1qqspyuz6gy6gzuzu74alun0js2995xznwp29dvtn6s0p3c3vck0mqygzypkvdypfpnkkug6zg4grs3c3qcykratknyfxdd7xkl4rw85xxg4hvqeeghcDue to their complexity, no review is rigorous enough for SNARKs ...
In reply to <a href='/nevent1qqsv2nnu2d0gfxjrd4k9fnqs2fmhqx0npxwhe3k4unsmqyzfhxyen0ghcda8w'>nevent1q…da8w</a><br/>_________________________<br/><br/>Due to their complexity, no review is rigorous enough for SNARKs and FCMPs. Think of it this way:<br/><br/>1) Local witnessing phase: you show your wallet the actual outputs you're spending and the public meta-address where you want to send the money. Your wallet's local FCMP (or SNARK) circuit generates a proof, after checking everything, saying everything adds up. From the public meta address it generates the new outputs that will belong to the receiver.<br/><br/>2) You broadcast this FCMP receipt generated by your wallet to the network with the new outputs: The other nodes verify the FCMP is valid and accept the outputs<br/><br/>3) The trust problem: A proof generated this way, requires blind trust in the binary circuit which happens to have highly abstract math that compresses multiple proofs at once. As a node you're not verifying the inputs of any transaction (like homomorphic math on Pedersen Commitments today). You're blindly trusting the FCMP or SNARK receipt. <br/><br/>The attack vector: these systems can be attacked by finding and exploiting weaknesses in the ZK proof (FCMP or SNARK). With Zcash it happened already twice: once in 2018 with Ariel Gabizon, and another time in July 2025 with ZkSecurity. <br/><br/>The optional privacy solution: By concentrating liquidity on the transparent UTXOs, you create an audit of last resort in the exiting stage of any inflation exploit that went undetected due to the highly complex math involved. <br/><br/>This is not a "scare", it's a reality, the risk profile changes completely and make no mistake, MRL devs are well aware of it but they're counting on most people having no clue where the new trust bottlenecks and privacy vulnerabilities are. <br/><br/>The reason why Monero is taking this immense risk is because people have caught up with the fact that there is no privacy in RingCT because it's extremely easy to filter out decoys. They're trying to flip to another model that sounds good due to complexity but in reality would be the same, or much weaker. Because trading off verifiability for "better privacy" also requires concentrating liquidity on a transparent pool. This transparent pool in Monero will be built by compiling a database of all outputs whose full view keys (that will be introduced by CARROT, which is bundled together with FCMP) have been leaked. <br/><br/>These could be simply exchange addresses, but also open source wallets with non reproducible code that have a line hidden somewhere that leaks the public view keys of its users' outputs.
2026-04-26T05:30:49Z