FCMP++: The Hopeless Last Ditch Attempt To Cover Up Monero's Obsoleteness That Breaks It Completely

In their developers' own words.

In my previous articles I’ve explained how Monero today is completely traceable via a process known as key image analysis. The crux of the vulnerability is that in every Monero transaction new key images (equal to the number of inputs being spent) are published onchain, and at least 2 new TXOs are created on the output side. These can then be analyzed for patterns to expose the flow of the money without having to break encryption. In Monero each key image appears onchain with a ring of 16 TXOs attached to it. Among these, the TXO being spent is hidden. Via RingCT the network can verify that inputs are valid and that each key image effectively belongs to one of the 16 TXOs in the respective ring, without revealing which. In many cases, however, pattern analysis reveals the real spends and therefore maps TXOs to the respective key image, by bypassing RingCT.

To prove that the amounts in the newly created outputs (TXOs) are also valid (ie, there are no negative amounts), another type of proof known as bulletproofs is used. Bulletproofs make sure there are no outputs with negative amounts, which would otherwise enable the creation of new coins. This is why they are also known as range proofs, because they prove the value in the TXOs belongs to a specific range (greater than 0, less than Monero’s max supply).

Full Membership Chain Proofs

Monero’s developers are currently working on a new type of proof, Full Chain Membership Proofs, that will get rid of rings. Theoretically, this should at least mitigate key image analysis because there will no longer be decoys. If you have read my previous articles, however, you should know that the real vulnerability aren’t rings, but key images and TXOs.

By introducing FCMP++ and eliminating rings, it is believed that at least future transactions will be private (FCMP++ does not add privacy to past transactions). Contrary to RingCT which proves that the specific input, to which the key image tied to the ring of TXOs belongs, is indeed part of the ring, FCMP is a proof of inclusion. In other words, it proves that the key image included in a specific transaction does indeed belong to one of the existing TXOs. This kind of new proof however doesn’t come without trade-offs. In the next paragraph I will explain how FCMP++ not only doesn’t fix Monero, but actually breaks it completely by making it unusable and increasing further the reliance on public nodes. Public nodes compromise privacy because they collect offchain metadata about transactions.

Performance Versus Bulletproofs

The root cause is FCMP’s performance. We have to ask ourselves, how much space do FCMPs take and how much computation power do they require from nodes? How does that scale with an increasing number of inputs? Because FCMPs do not get rid of key images, and since in a UTXO blockchain users and merchants must combine different TXOs/inputs, in multi input transactions we will have to verify inclusion for more than one key image. The performance benchmark today is set by bulletproofs because as the amount of outputs grows the size of bulletproof proofs scales logarithmically. This makes them good for scaling because as the number of outputs increases the size of the proof increases less and less. The size of FCMP proofs on the other hand grows linearly with the number of inputs. FCMPs are 9x bigger than Bulletproofs for 1 input at minimum computational load (at maximum inclusiveness among nodes with low computation power). The ratio only gets worse as the number of inputs grows. For an estimate we can refer to this github by Kayaba.

By increasing the computational load on nodes and wallets, we can require them to generate smaller proofs in order to save space. By opting for a compute factor of 4 we could have smaller proofs, attracting lighter nodes. But at the same time this would probably still cause them to fall off the network for not being able to handle the additional computational load. In any case, this is how the size of FCMP proofs is reduced if we opt for compute factor 4:

The difference is ~50% for 1 input transactions and only 13% for FCMP proofs of transactions with 16 inputs. Kayaba in his proposal recommends a compute factor of 4. In a way this is already an admission of defeat, because it pushes the node infrastructure towards more centralization. Centralisation introduces additional offchain metadata that make tracing Monero even more easy. Fewer, and more powerful nodes also allow deeper chain corruption. We have seen this in Kaspa where missing chunks in the ledger went undetected for a long time because, as result of the high cost of running a node, there were no full nodes in the network. So any unsigned transactions by miners have forever gone undetected. In addition to more offchain metadata and weaker security, the extra workload will also lead to an increase in Monero transaction fees.

Degraded UX and more Trusted Set ups

Because of the inefficiency of FCMP proofs, a limit for the maximum number of inputs in a transaction will have to be introduced with the (hypothetical) FCMP hardfork. What this limit will be is unclear. Currently the consensus among Monero researchers seems to be to set it at 8. This introduces more attack vectors onchain. If I can trace a user because post-FCMP users are extremely likely to not run their own node, now I can also spot merchants onchain because they consolidate in multiple 8-input transactions. The real cost, however, is going to be the deprecation in UX for Monero merchants. This will create more headwinds for Monero’s adoption as cash. Any merchant who receives hundreds of transactions per day will have to spend at least ~1 hour per day consolidating their TXOs. For 500 incoming transactions, if each transaction can have only 8 inputs, to consolidate TXOs one would need to proceed as follows:

1. Create 63 transactions to consolidate these 500 inputs into 63 new TXOs.

2. Wait 20 minutes

3. Create 8 new transactions consolidating the 63 TXOs into 8 new TXOs.

4. Wait 20 minutes

5. Create a new transaction consolidating the last 8 TXOs into a new single TXO.

Because of this deprecation in UX for merchants, some have even suggested to give up pursuing the FCMP++ hardfork completely:

if the coin is very troublesome to accept as medium of exchange (impossible to spend or consolidate many received inputs into an output) then the privacy gains are all for naught. If merchants decide it's too much of a pain to deal with then that is no bueno.

It’s important to bear in mind the reason why Monero developers are pushing towards FCMP++: because rings in Monero offer no privacy. Thanks to onchain and offchain metadata (such as by all transactions of users that don’t use nodes or CEX transactions), we can map some TXOs to their key images and get the key images of other TXOs from centralized entities that report their transactions quarterly. And since each TXO can be spent only once, mapping TXOs to their key images allows filtering them out as decoys in all other transactions where they appear among inputs. A Chainalysis video leaked in September 2024 shows how Chainalysis is already capable of filtering out decoys en masse. Past transactions will forever be traceable, but to save Monero’s face as the king of privacy coins among less tech savvy users, FCMP++ is needed ASAP before the masses catch up with Monero’s obsoleteness. This brings us to Luke Parker’s reply to the above comment. He says, quote:

I have mixed feelings. I completely agree with you in that Monero has to be usable. I also just believe there's risks to the protocol itself without this and we can't risk protocol stability for usability. (Luke Parker on FCMP++, Nov 2024)

When you compare this to his previous public statements, it’s impossible to not notice the difference in tone and confidence. For example:

Also, please don’t slander my word. There’s no expected UX degradation (it should be entirely in the background) and there is no trusted setup (Luke Parker on FCMP++ May 2024)

Isn’t it a trusted set up to use someone else’s Monero node? Considering the computation and space tax that FCMPs bear, their introduction would push more users towards using public nodes and therefore would undermine the privacy of the entire network by making it easier to trace where their TXOs are spent via offchain metadata collected by public nodes.

The Impact of FCMPs on Good OpSec

A recurring narative in the Monero community is the importance of good user OpSec. For example, users are encouraged to run their own node. Running your own node serves to limit the amount of offchain metadata (such as user IP, wallet version etc.) but it does not mitigate onchain metadata (such as burnt TXOs whose key images have already been identified). For this reason, running your own node provides little defence against key image analysis because of the abundant amount of onchain metadata today.

Considering that after the FCMP hardfork there will be less onchain metadata, some might try to argue that with the introduction of FCMP good user opsec will become more effective. However, the effectiveness of good OpSec diminishes when fewer and fewer people adopt it. And fewer and fewer people will inevitably adopt good OpSec if good OpSec becomes more expensive. Since FCMPs make trustless set ups more computationally expensive, that means the cost of good OpSec will go up.

In the case of user nodes this translates in less user run nodes and more nodes run by centralized entities. What good is running my own node, if I’m the only user node in the network? Because if user nodes are a small minority, it means users are extremely likely to be connected only to other Chainalysis/centralized nodes and if so then centralized parties will be able to tell whenever a transaction is generated from my node and tie my node metadata to my transaction, despite my good OpSec. So after the FCMP hardfork, good OpSec becomes more expensive and less effective at the same time. Because users with good OpSec practices, such as those running their own nodes, are more likely to stick out like sore thumbs, which would make detection and collection of their offchain metadata even easier.

Why not FCMP++

Today we can compile huge databases of spent TXO and their key images by combining offchain metadata with onchain ones. Post-FCMP we will have less onchain metadata (no decoys), but also a lot more offchain metadata because of a much more centralized node infrastructure as result of blockchain bloating and the considerably higher computational load imposed on nodes by FCMP proofs. UX deprecation makes Monero in its naked/cypherpunk form so unusable that users are pushed towards centralized services or public nodes. And UX deprecation for merchants, as result of the limit of 8 inputs per transaction, means there will also be fewer centralized services. Or at least a lot more friction for merchant adoption and retention. This increase in offchain metadata, and their defragmentation in the hands of fewer centralized services, not only doesn’t fix Monero but breaks it completely.