Punti deboli di RingCT
Dove la privacy di Monero oggi è imperfetta, ed è proprio ciò che FCMP++ corregge
In RingCT importi e destinatari sono protetti dalla crittografia. Il mittente, invece, solo dalla statistica: "1 di 16". Quasi tutti gli attacchi noti funzionano allo stesso modo: escludono esche dal ring o pesano i candidati in base alla probabilità. Qui sotto i principali, dal più noto al più sottile.
Il modello: dimensione effettiva del ring
Un ring di 16 offre 16 possibilità solo se sono tutte ugualmente plausibili. Ogni briciola di informazione esterna riduce la dimensione effettiva del ring. Se un osservatore può cancellare 10 esche, resta "1 di 6". Se può pesare le restanti: "probabilmente è questo".
1. Reazione a catena (storico)
Prima del 2016 erano consentite transazioni senza esche (ring di 1). Un input del genere rivela esattamente quale output è stato speso. E se quell'output era stato usato come esca nel ring di qualcun altro, lì può essere cancellato. Questo può rendere univoco un altro ring, e così via: una reazione a catena. Studi del 2017 hanno mostrato che una grande quota dei primi input è stata deanonimizzata in questo modo.
Stato: chiuso vietando i ring senza esche e passando a RingCT (gli output RingCT si mescolano solo con output RingCT). Ma i vecchi output si portano dietro la loro storia.
2. Età degli input
Se la distribuzione dell'età delle esche non corrisponde a come le persone spendono davvero, l'input reale spicca. La classica euristica "il più recente è quello reale" funzionava molto bene sulle prime transazioni. Dettagli in selezione delle esche.
Stato: attenuato dalla distribuzione gamma, ma non del tutto risolvibile finché le esche vengono scelte.
3. L'attacco EAE (Eve–Alice–Eve)
Eve (per esempio un exchange) invia denaro ad Alice, e più tardi Alice rimanda denaro a Eve (lo stesso exchange, magari attraverso alcune transazioni intermedie). Eve conosce il proprio output all'inizio della catena e il proprio output alla fine. Se vede il "suo" output nei ring delle transazioni intermedie e i tempi sono plausibili, può collegare invio e ricezione con alta probabilità.
Stato: uno degli attacchi più concreti per i servizi centralizzati. Attenuato dal churning (inviare a sé stessi con delle pause), ma risolto in modo affidabile solo da FCMP++.
4. Flooding (black marble)
Un attaccante produce in massa transazioni con i propri output. Per le regole di selezione delle esche, questi iniziano a finire nei ring degli altri utenti. L'attaccante sa che sono "vuoti" e li cancella. Più grande è la sua quota di output in un periodo, più piccolo diventa il ring effettivo di tutti gli altri. Episodi di spam di questo tipo si sono visti nel 2021 e nel 2024; le stime hanno mostrato un calo sensibile della dimensione effettiva dei ring durante quei periodi.
Stato: limitato dal costo (commissioni) e dalla dimensione dinamica dei blocchi. Eliminato da FCMP++: quando il "ring" è l'intera blockchain, la quota dell'attaccante è trascurabile.
5. Unione degli input
Se una transazione spende 5 input, sono 5 ring, e si sa che i membri reali di tutti e cinque appartengono alla stessa persona. Se un osservatore vede che questi ring contengono output della stessa transazione passata, è un forte segnale che quelli sono gli input reali (è improbabile che una selezione casuale delle esche produca una tale coincidenza).
Stato: intrinseco ai ring. FCMP++ lo indebolisce molto (ogni input è "uno di tutti"), ma il numero di input resta visibile.
6. Metadati delle transazioni
- Numero di input e output: 1→2 è comune, 15→1 spicca (consolidamento).
- Commissione: una commissione non standard rivela un wallet non standard.
- Tempi: le transazioni fatte subito dopo aver ricevuto fondi rivelano l'età dell'input reale.
- tx_extra: campi non standard, ordinamento, chiavi aggiuntive: un'"impronta del wallet".
- Unlock time: i valori non standard spiccavano (rimosso nelle regole più recenti).
Stato: FCMP++ lo tocca appena: è compito dei wallet, con comportamento uniforme e formati uniformi.
7. Livello di rete
Il nodo che per primo ha inoltrato una transazione ne è probabilmente l'autore. Monero usa Dandelion++: una transazione passa prima in silenzio lungo una catena di nodi casuali (lo "stelo") e solo dopo viene diffusa a tutti (il "soffione"). In più c'è il supporto a Tor/I2P. Se usi il nodo remoto di qualcun altro, questo vede il tuo IP e l'ora di invio.
Stato: fuori dalla catena, FCMP++ non aiuta. Usa il tuo nodo o Tor.
Riepilogo: cosa corregge FCMP++
| Punto debole | RingCT | FCMP++ |
|---|---|---|
| Reazione a catena | storico | non applicabile |
| Età delle esche | attenuato | eliminato |
| EAE | funziona | eliminato (sulla catena) |
| Flooding | funziona | praticamente eliminato |
| Unione degli input | funziona | molto indebolito |
| Metadati (numero in/out, commissione, tempo) | visibili | visibili |
| Rete (IP) | Dandelion++/Tor | invariato |
Prossimo passo: come funziona FCMP++.