Técnico › RingCT

Debilidades de RingCT

Dónde la privacidad de Monero es imperfecta hoy, y por qué eso es justo lo que corrige FCMP++

En resumen

En RingCT los importes y los destinatarios están protegidos por criptografía. El remitente, solo por estadística: «1 de 16». Casi todos los ataques conocidos funcionan igual: excluyen señuelos del anillo o ponderan los candidatos por probabilidad. Abajo están los principales, del más conocido al más sutil.

El modelo: tamaño efectivo del anillo

Un anillo de 16 da 16 opciones solo si todas son igual de plausibles. Cada pizca de información externa reduce el tamaño efectivo del anillo. Si un observador puede tachar 10 señuelos, queda «1 de 6». Si además puede ponderar el resto: «probablemente este».

16 candidatos → 10 excluidos → 6 → + estadística → ~2

1. Reacción en cadena (histórica)

Antes de 2016 se permitían transacciones sin señuelos (anillo de 1). Una entrada así revela exactamente qué salida se gastó. Y si esa salida se usó como señuelo en el anillo de otra persona, allí se puede tachar. Eso puede dejar otro anillo sin ambigüedad, y así sucesivamente: una reacción en cadena. Estudios de 2017 mostraron que una gran parte de las primeras entradas se desanonimizaba de este modo.

Estado: cerrado al prohibir los anillos sin señuelos y pasar a RingCT (las salidas RingCT solo se mezclan con salidas RingCT). Pero las salidas antiguas conservan su historial.

2. Antigüedad de las entradas

Si la distribución de antigüedad de los señuelos no coincide con cómo gasta realmente la gente, la entrada real destaca. La heurística clásica «la más reciente es la real» funcionaba muy bien con las primeras transacciones. Detalles en selección de señuelos.

Estado: mitigado con la distribución gamma, pero no se puede corregir del todo mientras haya que elegir señuelos.

3. El ataque EAE (Eve–Alice–Eve)

Eve (por ejemplo, un exchange) envía dinero a Alice, y Alice más tarde envía dinero de vuelta a Eve (el mismo exchange, quizá a través de unas cuantas transacciones intermedias). Eve conoce su salida al principio de la cadena y su salida al final. Si ve «su» salida en los anillos de las transacciones intermedias y los tiempos son plausibles, puede vincular el envío y la recepción con alta probabilidad.

Eve (exchange) Alice tx … Eve otra vez Eve conoce ambos extremos y busca su salida en los anillos

Estado: uno de los ataques más prácticos para los servicios centralizados. Se mitiga con churning (enviarse a uno mismo con pausas), pero solo FCMP++ lo corrige de forma fiable.

4. Inundación (black marble)

Un atacante produce en masa transacciones con salidas propias. Por las reglas de selección de señuelos, estas empiezan a aparecer en los anillos de otros usuarios. El atacante sabe que son «vacías» y las tacha. Cuanto mayor es su proporción de salidas en un periodo, menor es el anillo efectivo de todos los demás. Se observaron episodios de spam así en 2021 y 2024; las estimaciones mostraron una caída notable del tamaño efectivo del anillo durante esos episodios.

Estado: limitado por el coste (comisiones) y por el tamaño de bloque dinámico. FCMP++ lo elimina: cuando el «anillo» es toda la blockchain, la proporción del atacante es despreciable.

5. Fusión de entradas

Si una transacción gasta 5 entradas, son 5 anillos, y se sabe que los miembros reales de los cinco pertenecen a la misma persona. Si un observador ve que estos anillos contienen salidas de una misma transacción anterior, es una señal fuerte de que esas son las entradas reales (es poco probable que la selección aleatoria de señuelos produzca semejante coincidencia).

Estado: inherente a los anillos. FCMP++ lo debilita mucho (cada entrada es «una de todas»), pero el número de entradas sigue siendo visible.

6. Metadatos de la transacción

  • Número de entradas y salidas: 1→2 es habitual; 15→1 destaca (consolidación).
  • Comisión: una comisión no estándar delata un monedero no estándar.
  • Momento: las transacciones hechas justo después de recibir fondos revelan la antigüedad de la entrada real.
  • tx_extra: campos no estándar, el orden, las claves adicionales: una «huella del monedero».
  • Unlock time: los valores no estándar destacaban (eliminado en las reglas más recientes).

Estado: FCMP++ apenas toca esto; es tarea de los monederos: comportamiento uniforme, formatos uniformes.

7. Capa de red

El nodo que retransmitió primero una transacción probablemente es su autor. Monero usa Dandelion++: una transacción primero pasa discretamente por una cadena de nodos aleatorios (el «tallo») y solo después se difunde a todos (la «pelusa»). Además admite Tor/I2P. Si usas el nodo remoto de otra persona, ve tu IP y el momento del envío.

Estado: está fuera de la cadena, así que FCMP++ no ayuda. Usa tu propio nodo o Tor.

Resumen: qué corrige FCMP++

DebilidadRingCTFCMP++
Reacción en cadenahistóricano aplica
Antigüedad de los señuelosmitigadaeliminada
EAEfuncionaeliminado (en la cadena)
Inundaciónfuncionaprácticamente eliminada
Fusión de entradasfuncionamuy debilitada
Metadatos (n.º de entradas/salidas, comisión, momento)visiblesvisibles
Red (IP)Dandelion++/Torsin cambios

Siguiente: cómo funciona FCMP++.