Pseudo-nodo y vectores de ataque putativos en la red

Una gran cantidad de pseudonodos interconectados hace que lanzar un ataque de agotamiento del ancho de banda sea mucho más fácil. Bitcoin Core valida la mayor parte de la información antes de transmitirla, pero los psuedo-nodos no validan, por lo que si puede conectar algunos psuedo-nodos, probablemente sea fácil hacer que desperdicien toneladas de ancho de banda al transmitirse datos basura entre sí. y luego a sus compañeros.

Por ejemplo, si hay 101 psuedo-nodos (PN) conectados entre sí, puede enviar a PN1 un invpaquete de aspecto válido que anuncie una sola transacción falsa (alrededor de 61 bytes más la sobrecarga del paquete TCP). Cada PN transmite eso invpor un mínimo de 6100 bytes de carga desperdiciados.

Pero esas PN también están conectadas a nodos reales. Digamos 500 nodos reales, por lo que ahora el ancho de banda de carga de PN desperdiciado es de 36 600 bytes (más la sobrecarga de TCP), todo porque un atacante creó un único archivo inv. Peor aún, los nodos reales solicitarán la transacción utilizando un getdatapaquete de 61 bytes , desperdiciando 30 500 bytes de ancho de banda de carga de nodos reales.

Si el atacante envía 1 MB de datos falsos por segundo durante todo un día, usará 86 gigabytes de su propio ancho de banda, pero desperdiciará 52 terabytes de ancho de banda de carga de PN agregado y potencialmente 43 terabytes de ancho de banda de carga de nodo real.

(Dependiendo de cómo se escriban las PN, pueden desperdiciar aún más ancho de banda al retransmitir el getdatapaquete).

Compare esto con el costo de ejecutar el ataque contra un solo nodo real. Por cada paquete de 61 bytes invque carga el atacante, el nodo real responde cargando un único paquete de 61 bytes getdata. Por lo tanto, un ataque de agotamiento del ancho de banda contra un nodo real requiere aproximadamente 1:1 de ancho de banda desperdiciado. El nodo real no transmite más invhasta que recibe y valida la transacción a la que se refiere, por lo que ningún otro nodo tiene ancho de banda desperdiciado.

¿Hay contingencias factibles en el protocolo para delinear entre un PN y un nodo? Por ejemplo, ¿diferentes versiones de Bitcoincore identificarían PN (o una simple modificación del protocolo)?

El protocolo ya tiene la noción de una puntuación de prohibición DoS, en la que cada nodo de Bitcoin Core asigna una puntuación privada a cada uno de sus pares por cualquier mal comportamiento que realicen. Una vez que la puntuación de prohibición de DoS para un par en particular alcanza un umbral (100 de forma predeterminada), el nodo se desconecta del par y rechaza más conexiones desde su dirección IP durante un tiempo (un día de forma predeterminada). El mal comportamiento incluye el envío de transacciones y bloques no válidos.

Debido a que las PN no validan los datos, felizmente transmitirán datos no válidos. Si se vuelven comunes, alguien que quiera dañar las PN podría simplemente conectarse a cualquier nodo anunciado y enviarle un montón de datos no válidos. Si fuera un nodo completo real, se desconectará (prohibición de DoS). Si fuera un PN, transmitiría esos datos a los nodos completos reales, lo que provocaría que los nodos completos reales lo prohibieran. Esto haría que la PN fuera inútil y permitiría que el afligido detectara qué nodos son PN; entonces, el afligido podría publicar una base de datos (no autenticable) de direcciones IP de PN.

Este método funciona mejor contra las NP a largo plazo. Para dificultar la ejecución de ataques Sybil a corto plazo desde muchas PN livianas, se podría usar algo como la prueba de almacenamiento de Greg Maxwell para hacer que el consumo de recursos distribuidos sea costoso .