Prevención de fusiones: técnicas para mejorar la Privacidad en el protocolo Bitcoin

Mike Hearn Es un desarrollador de software que trabaja en el equipo de desarrollo de Bitcoin CORE y también en Google. En este artículo, Mike analiza algunas filtraciones de Privacidad de Bitcoin y una nueva técnica que aún no tiene nombre, pero a la que llamaprevención de fusiones.

Introducción a la Privacidad de Bitcoin

Es un hecho lamentable que, a pesar de la reputación de Bitcoin en la prensa, sus usuarios actualmente filtran grandes cantidades de información personal.

Es inquietantemente fácil que alguien Aprende tu saldo, tu historial de operaciones y más. Proteger esta información es fundamental en cualquier sistema financiero útil.

A continuación se muestran algunas fugas que surgen durante el uso diario.

Reutilización de direcciones

Muchos problemas de Privacidad en Bitcoin se deben a que un adversario descubre qué salidas pertenecen a la misma billetera. Si logras calcular esto, puedes descubrir el saldo de la billetera y posiblemente con quién se realizó la transacción.

La forma más común de que esto ocurra es cuando se reutilizan direcciones. Esto se entiende fácilmente porque sitios populares como blockchain.info indexan los resultados y las transacciones por dirección, lo que permite consultar rápidamente todas las transacciones que hacen referencia a una dirección determinada.

La reutilización de direcciones tiene diversas causas. A continuación, se presentan algunos ejemplos:

1. Problemas con la billetera del usuario final

La biblioteca bitcoinj siempre reutiliza direcciones según la Regulación, lo que filtra mucha información privada. Esto se debe a dos razones. Una es que, antes del desarrollo de las billeteras HD, el uso constante de claves invalidaba las copias de seguridad de las billeteras antiguas.

Bitcoin-Qt cuenta con un "fondo de claves" para intentar solucionar esto, pero solo aplaza el problema: el fondo de claves puede agotarse silenciosamente, lo que genera el mismo problema. Invalidar las copias de seguridad puede causar pérdidas económicas.

Una vez implementadas las billeteras HD (lo cual está en proceso), este problema desaparecerá, dejando solo el segundo problema de la presión de memoria en los teléfonos de gama baja. Es posible que la reutilización de direcciones siga siendo necesaria en estos dispositivos, pero los teléfonos y ordenadores de escritorio/portátiles de gama alta no deberían presentar problemas.

2. Problemas con la billetera del servidor

No existen implementaciones públicas de billeteras de código abierto que escalen a billeteras con un gran número de claves. Hasta donde sé, las plataformas de intercambio y los principales procesadores de pagos han tenido que implementar mucho código personalizado para solucionar la falta de escalabilidad de Bitcoin-Qt (y bitcoinj).

Esto presiona a los receptores para que reutilicen las direcciones.

3. Convenciones sociales

Personas que colocan direcciones estáticas en las firmas del foro, códigos QR, ETC

Con el tiempo, necesitaremos avanzar en todos estos aspectos para reducir la reutilización de direcciones. Las billeteras HD y el protocolo de pago son herramientas importantes para lograrlo.

Cambiar salidas

Una de las filtraciones de Privacidad más irritantes en Bitcoin es que la gente se entera de los límites inferiores de su saldo.

Cómo funciona esto se puede entender intuitivamente con la analogía del efectivo. Con el papel moneda, si entregas un billete de 500 CHF para pagar una bebida que cuesta solo 5 CHF, el camarero descubre que tu saldo es de al menos 495 CHF. Puede que sea mayor, claro, pero al menos no menor. Bitcoin tiene el mismo problema.

La causa principal de este problema es una falta de coincidencia entre el tamaño del pago que desea realizar y las monedas (salidas) disponibles para usted.

Si el desajuste está en una dirección, tienes muchas salidas pequeñas y hacer pagos por cantidades que no sean pequeñas empieza a costar mucho en tarifas, porque las transacciones que generas son enormes.

Si el desajuste está en la otra dirección, entonces para pagar una cosa pequeña se requiere el uso de una moneda grande, y el cambio resultante filtra datos valiosos acerca de cuán rico es usted.

Tráfico de red

Las conexiones P2P de Bitcoin no están cifradas. Una razón es que la mayoría de los datos que circulan por la red P2P son públicos, por lo que cifrarlos parece inútil.

Otra razón es que, por su propia naturaleza, cuando te conectas a una red P2P tus pares podrían ser absolutamente cualquiera y hacer absolutamente cualquier cosa; por ejemplo, podrían ser nodos administrados por la NSA.

¡Y eso ni siquiera es malo! ¿Por qué la NSA no debería gestionar nodos? Si alguien les dijera que no lo hicieran, implicaría que una autoridad central dictaría quién puede gestionar Bitcoin y quién no. No queremos eso.

Así que cifrar datos es útil cuando se tiene una idea clara de quién puede verlos y quién no. Cifrar datos públicos para personas al azar de las que no se sabe nada no es tan útil.

A pesar de todo esto, todavía hay cuatro razones por las que sería útil cifrar las conexiones.

El primera razónes paraFiltros Bloom.

Estas son representaciones compactas de lo relevante para tu billetera: típicamente, las direcciones/claves que contiene. Un filtro es ONE y puede ser ruidoso; es decir, no puedes leer las direcciones directamente de un filtro; solo puedes aplicarlo a la cadena de bloques y ver qué coincide.

Los filtros pueden tener falsos positivos, por lo que un nodo nunca puede estar seguro de si una dirección es realmente tuya o no. Esto es bastante bueno, pero incluso con una alta tasa de falsos positivos, reduce considerablemente la cantidad de monedas que podrías poseer.

Los filtros Bloom no son información pública, simplemente se comparten entre un cliente y el nodo al que se conecta. Por lo tanto, sería conveniente ocultarlos de intrusos pasivos, como quienes comparten tu punto de acceso wifi.

El segunda razón es que aunque las transacciones son públicas, su dirección IP de origen no lo es (o no se supone que lo sea).

Pero un adversario que puede observar muchos enlaces de Internet podría decidir con bastante fiabilidad dónde se inició una transacción registrando con precisión los momentos en que se vio por primera vez una transacción y examinando el primer momento en que transitó un LINK de fibra.

Parece que algunas agencias de inteligencia podrían realizar este tipo de análisis. Cifrar enlaces no garantiza una solución, ya que el análisis de tiempo aún podría ser posible, pero sin duda lo dificulta.

El tercera razón es que si el cifrado se combinara con la autenticación de “confianza en el primer uso” (TOFU), sería más difícil incluso para los MITM activos realizar ataques sybil a las billeteras y alimentarlas con datos erróneos.

Esto es más importante para los clientes SPV que para los nodos completos, pero ambos podrían beneficiarse.

El razón finalSi se implementa correctamente, el uso de SSL para conexiones P2P haría más difícil identificarlas y bloquearlas mediante dispositivos de inspección profunda de paquetes.

CoinJoin

De todos los problemas mencionados anteriormente, la solución a la filtración de datos a través de cambios en los resultados es ONE de los más debatidos (aunque muchas personas no se dan cuenta de que lo están debatiendo).

El Propuesta de CoinJoin Ha recibido mucha atención y se han implementado algunas medidas iniciales. Algunos lo ven principalmente como una herramienta de Privacidad , mientras que otros lo ven como una forma de intentar descifrar el rastreo de monedas.

Cuando se utiliza para Privacidad, se puede describir mejor como una forma de intentar eliminar información que ya se ha filtrado.

Sin embargo, CoinJoin tiene una serie de problemas graves que hacen que sea deseable encontrar una alternativa.

Es profundamente complejo de implementar bien, vulnerable a ataques sybil/DoS (a menudo son lo mismo en este contexto), legalmente cuestionable y no está claro que la ofuscación funcione.

El Robo en el mercado de ovejas Se ha visto a alguien afirmar rastrear monedas mediante mezcladores y volteadores, aparentemente con cierto éxito. Una de las herramientas del rastreador eran los ataques Sybil/DoS contra servicios de mezcla, así que no son un problema teórico.

Si bien las implementaciones de juguetes no son demasiado difíciles de armar, las implementaciones robustas en el mundo real con un manejo adecuado del tiempo de espera, controles de seguridad, buena integración de la interfaz de usuario de la billetera , ETC, requieren mucho más esfuerzo.

Hasta ahora, solo blockchain.info ha logrado crear ONE (en sharedcoin.com), y solo hay que confiar en que no KEEP registros. De lo contrario, cualquiera que tenga los registros podría descomponerlos.

Quizás el tema menos discutido es la experiencia del usuario.

Una transacción de CoinJoin requiere la participación de otras personas. Cuantas más participen, mejor. Sin embargo, Bitcoin actualmente solo alcanza un máximo de aproximadamente una transacción por segundo.

Incluso si todas las transacciones se combinaran mediante CoinJoin y se reunieran en un único punto (¡ay, centralización!), todavía habría que esperar entre 10 y 15 segundos para conseguir un buen conjunto de participantes con los que mezclarse.

Eso es solo para iniciar el protocolo. Luego, todos los participantes tendrían que recuperar la transacción candidata y firmarla. Si se agota el tiempo, todo debe comenzar de nuevo.

En condiciones adversas, este proceso podría tardar fácilmente un minuto o más, especialmente si algunos participantes tienen redes inestables (por ejemplo, teléfonos) y usan Tor. Dado que intentamos mejorar el rendimiento en lugar de reducirlo, esto en sí mismo parece un gran problema.

Si bien aumentar el tráfico y el uso ayudaría a reducir este problema, incluso si el tráfico se duplicara, dividir el único punto de encuentro central haría que los tiempos de espera volvieran inmediatamente al ONE de partida.

Puedes resolver este problema haciendo CoinJoins en segundo plano, sin relación con un gasto real que se esté produciendo.

Eso resuelve el problema de tener que hacer cola en la cafetería, pero luego hay que pagar comisiones por esas transacciones y puede ser difícil explicar a la gente por qué su saldo cayó repentinamente de la noche a la mañana debido a un impuesto a la Privacidad inesperado.

Ese tipo de sorpresa desagradable haría que Bitcoin resultara poco atractivo para el usuario común. Además, plantea la pregunta de cuándo y con qué frecuencia se realiza.

Evitar fusiones

Como una causa común de las filtraciones de Privacidad es un desajuste entre los tamaños de las monedas disponibles y las que se requieren, parece que podríamos abordar el problema desde otro ángulo: evitando crear filtraciones de información que deban borrarse en primer lugar.

Consideremos el caso de ALICE, una trabajadora de una cafetería que recibe un salario.

ALICE hace un gran trabajo y su jefe lo reconoce con un salario más alto de lo normal.

Su compañero de trabajo Bob sospecha que no le pagan tanto como a ALICE y quiere saberlo, así que convence a ALICE de hacerle un pequeño pago justo después del día de pago (tal vez hagan una apuesta y Bob gane).

Con Bitcoin regular, la billetera de Alice probablemente usará su salario y el cambio revelará su pago. Incluso si ya realizó varios pagos, Bob puede Síguenos la cadena de transacciones hacia atrás hasta encontrar una cifra razonablemente redonda en la fecha correcta y concluir que probablemente sea su salario.

CoinJoin simple T le sirve. Introduciría una gran cantidad de entrada en la mezcla y obtendría una gran cantidad de salida.

Podría Request muchas salidas más pequeñas, pero la entrada seguirá siendo equivalente a un salario y en la fecha correcta. A menos que muchas personas con salarios decentes compartan la misma transacción de CoinJoin, la fuga no se ha solucionado.

Lo que realmente necesita es evitar tener una salida única tan grande en primer lugar. Llamemos a esto evitar la fusión.

Cuando ella la presentaRequest de pago BIP 70A su empleador le pide una buena combinación de denominaciones, como si estuviera comprando efectivo en una casa de cambio.

La Request también especifica una dirección única para cada salida. El protocolo de pago no especifica cómo una billetera debe satisfacer esta Request, pero permite que la billetera del remitente envíe múltiples transacciones independientes para satisfacer las salidas deseadas.

[cita posterior]

Si su empleador usa una billetera antigua que no entiende la prevención de fusiones, generará y le enviará una única transacción gigante que tiene muchas entradas (de todos los cafés) y todas las salidas solicitadas.

Se parecerá mucho a una transacción de CoinJoin, pero solo tiene un participante. Sin embargo, no hay forma de saberlo simplemente observando la cadena de bloques.

Si su empleador usa una billetera más nueva que sí entiende la prevención de fusiones, entonces sucede algo mejor: recibirá una cantidad de transacciones diferentes, más pequeñas, cada una de las cuales crea una o dos de las salidas que solicitó.

No hay nada que los LINK . Como confía en que su empleador no gastará dos veces, puede distribuir la transmisión para que ni siquiera el tiempo los delate.

Si la selección de resultados se realiza con inteligencia, nunca se encontrará en una situación en la que tenga resultados excesivamente grandes o pequeños para un pago en particular. Bob simplemente verá una pequeña transacción que genere un resultado de cambio pequeño, y por mucho que busque en el pasado, nunca encontrará un resultado equivalente al salario. ¡ALICE gana!

Las salidas de cambio pueden filtrar datos de otra manera. Bob fracasó en su intento de Aprende el salario de Alice rastreando hacia atrás en la cadena de bloques, pero aún puede observar la salida de cambio del pago que recibió para ver qué sucede.

Si luego el cambio se combina con muchos otros para crear un pago enorme, de repente sabe que ALICE debe haber poseído al menos esa cantidad de dinero.

En este caso, CoinJoin parece funcionar: si el cambio se convierte en una combinación, ¿quién puede determinar quién es el propietario de las salidas? Pero es frágil. Incluso si las salidas tienen un tamaño aleatorio, al no existir un mecanismo para evitar fusiones, se volverán a combinar para generar un pago grande.

Si ALICE menciona de pasada que se va de vacaciones con su novio, Bob puede mirar los resultados de la mezcla en la que se invirtió su cambio y esperar a que algunos de los resultados se vuelvan a combinar.

Si 1/3 de los resultados quedan sin gastar, 1/3 se gastan sin combinarse de forma significativa y otro 1/3 se combinan en un pago de $5,000 la noche antes de que ALICE mencione sus vacaciones, es bastante probable que el viaje le cueste $5,000.

Propiedades de implementación

Este esquema tiene varias cosas que lo hacen agradable de implementar:

• Se puede escribir de forma incremental: un algoritmo simple y poco inteligente puede, sin embargo, mejorar la Privacidad de alguien. Posteriormente, se puede desarrollar e implementar un algoritmo mejor, pero no requiere actualizaciones globales complejas. Esto se adapta bien al modelo de desarrollo de Bitcoin , basado en la competencia entre monederos y a trompicones, impulsado por voluntarios.
• Es muy simple y no tiene partes móviles ni grandes máquinas de estados. No tienes que preocuparte por un teléfono móvil cualquiera al otro lado del mundo que se meta en un túnel en el momento equivocado, ni por ejecutar una reimplementación defectuosa del software.
• No hay centralización, ni siquiera servidores de encuentro transitorios.
• No existen riesgos legales porque no dependes de ningún servicio que pueda considerarse herramienta de lavado de dinero.
• Es robusto. Anteriormente, presenté ejemplos de cómo CoinJoin puede parecer funcionar, pero aun así presentar fugas con muy poca información adicional. La prevención de fusiones no presenta ese problema.

También hay algunas desventajas:

• La calidad de tu Privacidad depende en gran medida de la inteligencia con la que quienes te envían dinero procesan las transacciones. Por lo tanto, tu Privacidad depende de personas que podrían no tener muchos incentivos para actuar al respecto. Ojalá un software de billetera común hiciera lo correcto por defecto.
• Aumenta el número de transacciones, aunque la sobrecarga no es tan alta como se podría pensar: una transacción es simplemente una lista de entradas, salidas y un encabezado de dos campos (versión y tiempo de bloqueo). Las entradas y salidas no se modifican realmente en una buena implementación de CoinJoin, y la versión y el tiempo de bloqueo podrían comprimirse o codificarse con varintes fácilmente para ahorrar espacio. La diferencia sería del orden de bytes, no de kilobytes.
• Se basa en el protocolo de pago. Pero muchas cosas dependen de él, y el protocolo de pago es fundamental para combatir la reutilización de direcciones, algo necesario para que todos los esquemas de Privacidad propuestos funcionen. Es importante que BIP70 sea lo más fácil y generalizado posible.

La prevención de fusiones no interfiere con el rastreo de monedas. Algunas personas podrían optar por implementar sistemas CoinJoin solo por esa razón.

Sin embargo, no me imagino que esto se generalice. Si se protege la Privacidad de las personas por otros medios, CoinJoin se convierte en un sistema para "ayudar a los ladrones a ocultar el dinero robado", lo que reduce el incentivo para participar, aumenta aún más el riesgo legal y haría que la gente se pregunte por qué sus aplicaciones de billetera les piden comisiones simplemente para proteger a quienes probablemente consideran maliciosos.

Además, elIncidente en Sheep Marketplacedemuestra que la lucha descentralizada contra el crimen como técnica es a veces la única opción: nadie va a pedirle a la policía que ayude a recuperar el dinero robado del tráfico de drogas, y ningún gobierno se molestaría en ayudar si lo hiciera.

Este artículo fue publicado originalmente enMedio

Imagen del teclado de Privacidadvía Shutterstock