116 / 691SYBIL

Ataque Sybil

Un ataque Sybil permite a un adversario presentar muchas identidades de red. Bitcoin separa el número de pares del peso de consenso y vincula la producción de bloques a Proof of Work.

La resistencia Sybil no prohíbe pares falsos. Multiplicar identidades no crea firmas de claves ajenas, monedas válidas ni trabajo; aun así puede apoyar ataques de enrutamiento, eclipse y vigilancia.

John Douceur describió el ataque Sybil en 2002: una entidad aparenta ser varios participantes independientes. Los seudónimos son fáciles de crear, aunque obtener direcciones o conexiones adecuadas puede tener costes. [John R. Douceur — The Sybil Attack]

Bitcoin no tiene un registro global que demuestre que un nodo corresponde a una persona. Una IP diferente tampoco prueba por sí sola un operador independiente. [John R. Douceur — The Sybil Attack] [Bitcoin Developer Guide — P2P Network]

Un Full Node verifica las reglas de consenso de forma independiente. La mayoría de pares conectados no puede votar para convertir una transacción inválida en válida. [Satoshi NakamotoBitcoin whitepaper] [The Bitcoin Backbone Protocol]

Proof of Work vincula el peso en la elección de una cadena válida al trabajo acumulado. Anunciar más identidades no aumenta por sí solo la tasa de hash ni el trabajo de la cadena. [Satoshi NakamotoBitcoin whitepaper] [The Bitcoin Backbone Protocol]

Multiplicar identidades no permite falsificar firmas ajenas, crear monedas fuera de las reglas de emisión ni imponer un bloque inválido. Verificar estas reglas sigue siendo tarea del Full Node. [Satoshi NakamotoBitcoin whitepaper] [The Bitcoin Backbone Protocol]

Los pares controlados pueden competir por espacio en las tablas de direcciones y conexiones de la víctima. Si ayudan a controlar sus conexiones relevantes, puede surgir un ataque eclipse; muchas identidades por sí solas no prueban aislamiento total. [Bitcoin Developer Guide — P2P Network] [Heilman et al. — Eclipse Attacks on Bitcoin]

Las conexiones salientes diversas, la agrupación de direcciones y las conexiones de prueba feeler de Bitcoin Core limitan la concentración. Son defensas, no prueba de independencia de cada par ni garantía contra el aislamiento. [Bitcoin Core v29.0 — Peer connections] [Heilman et al. — Eclipse Attacks on Bitcoin]

Las direcciones IP y de servicios Tor ayudan a enrutar tráfico; no son credenciales de consenso. Varias direcciones pueden pertenecer a un operador y varios usuarios compartir una ruta de red. [Bitcoin Developer Guide — P2P Network] [Bitcoin Core v29.0 — Peer connections]

Proof of Work limita el abuso de identidades al elegir la historia, pero no resuelve todos los abusos P2P. La inundación, la vigilancia y la manipulación de la disponibilidad de mensajes requieren un modelo de amenazas separado. [John R. Douceur — The Sybil Attack] [Heilman et al. — Eclipse Attacks on Bitcoin] [The Bitcoin Backbone Protocol]

Un contador público de nodos accesibles no cuenta personas ni votos sobre reglas. La seguridad se evalúa por recursos adversarios, relaciones de red y validación independiente, no solo por el número de identidades. [John R. Douceur — The Sybil Attack] [Bitcoin Developer Guide — P2P Network] [The Bitcoin Backbone Protocol]

Para obtener la imagen más completa, lee esta entrada junto con Consenso de Nakamoto, Ataque de eclipse, Minería egoísta, Propagación de bloques. También enlazan con esta entrada Problema de los generales bizantinos, Ataque de eclipse.

DOC · 001John R. Douceur — The Sybil AttackFuente primariaDOC · 002Satoshi Nakamoto — Bitcoin whitepaperFuente primariaDOC · 003Bitcoin Developer Guide — P2P NetworkDocumentaciónDOC · 004Bitcoin Core v29.0 — Peer connectionsDocumentaciónDOC · 005Heilman et al. — Eclipse Attacks on BitcoinFuente primariaDOC · 006The Bitcoin Backbone ProtocolFuente primaria
Fuentes primero · No es asesoramiento financiero