117 / 691ECL

Eclipse attack

Um ataque eclipse captura as conexões de um nó Bitcoin com a rede. A vítima continua ligada ao atacante, mas perde acesso independente a pares honestos e vê a história selecionada por ele.

Eclipse é isolamento de rede, não desvio das regras de consenso. Um Full Node ainda rejeita dados inválidos, mas pode sofrer atrasos, censura ou permanecer em um ramo válido antigo.

O atacante deve capturar os caminhos relevantes da vítima, não apenas estabelecer uma conexão. Uma conexão funcional com um par honesto pode romper seu controle completo. [Heilman et al. — Eclipse Attacks on Bitcoin] [Bitcoin Optech — Eclipse attacks]

O estudo de Heilman e coautores de 2015 examinou preencher tabelas de endereços e capturar reconexões. O resultado depende dos recursos e da implementação; um experimento histórico não testa a versão atual. [Heilman et al. — Eclipse Attacks on Bitcoin] [Bitcoin Core v29.0 — addrman]

O atacante escolhe quais blocos e transações entram ou saem. Pode reter mensagens e observar a origem das transações mesmo sem maioria do poder computacional. [Heilman et al. — Eclipse Attacks on Bitcoin] [Bitcoin Optech — Eclipse attacks]

Um Full Node continua verificando assinaturas, scripts e emissão. Isolamento não valida um bloco inválido, mas a validação não revela um bloco válido que nunca chega. [Bitcoin Developer Guide — Block Chain]

Sem novos blocos honestos, o nó pode ficar em uma ponta antiga; um minerador isolado pode desperdiçar trabalho em um ramo abandonado pelo restante. Disponibilidade e atualidade diferem de validade. [Heilman et al. — Eclipse Attacks on Bitcoin] [Bitcoin Optech — Eclipse attacks]

Um receptor pode ver confirmações em um ramo válido do atacante e sua reorganização quando a conexão retorna. O ramo ainda exige Proof of Work; inventar um número de confirmações sozinho não engana um Full Node. [Heilman et al. — Eclipse Attacks on Bitcoin] [Bitcoin Developer Guide — Block Chain] [Bitcoin Optech — Eclipse attacks]

Agrupar endereços e diversificar caminhos de saída reduz concentração. Endereços diferentes podem pertencer ao mesmo adversário; diversidade não garante independência. [Bitcoin Core v29.0 — addrman] [Bitcoin Core v29.0 — Peer connections]

Bitcoin Core usa conexões de teste feeler e conexões adicionais de retransmissão de blocos para buscar caminhos. As primeiras testam endereços, as segundas podem trazer cabeçalhos; nenhuma garante sozinha o fim do isolamento. [Bitcoin Core v29.0 — Peer connections]

Um par conhecido configurado manualmente pode acrescentar um caminho, mas exige confiança em disponibilidade e conectividade. Mais conexões pelo mesmo provedor não significam necessariamente caminhos independentes. [Bitcoin Developer Guide — P2P Network] [Bitcoin Optech — Eclipse attacks]

Eclipse visa um nó ou grupo selecionado; uma partição mais ampla separa regiões inteiras da rede. A defesa examina caminhos e modelo adversário, não apenas o número de conexões abertas. [Heilman et al. — Eclipse Attacks on Bitcoin] [Bitcoin Optech — Eclipse attacks]

Para ter uma visão mais completa, leia este verbete junto com Sybil attack, Block propagation, Compact block relay, Nakamoto consensus. Também há referências a este verbete em Gasto duplo, Sybil attack, Neutrino.

DOC · 001Heilman et al. — Eclipse Attacks on BitcoinFonte primária ↗DOC · 002Bitcoin Developer Guide — P2P NetworkDocumentação ↗DOC · 003Bitcoin Core v29.0 — addrmanDocumentação ↗DOC · 004Bitcoin Core v29.0 — Peer connectionsDocumentação ↗DOC · 005Bitcoin Developer Guide — Block ChainDocumentação ↗DOC · 006Bitcoin Optech — Eclipse attacksDocumentação ↗
Fontes em primeiro lugar · Não é recomendação de investimento