São caminhos de rede separados para a comunicação de um node Bitcoin: Tor usa um proxy SOCKS e onion services, I2P usa túneis pela interface SAM e CJDNS é um overlay IPv6 cifrado; estes mecanismos não alteram transações, blockchain ou consenso e não garantem por si só o anonimato do utilizador.
Uma rede de anonimato protege o transporte entre nodes, não o conteúdo de uma transação Bitcoin. Pode ocultar o endereço IP comum da contraparte ou dificultar a observação do percurso, mas valores públicos, ligações entre endereços, timing e heurísticas on-chain continuam a ser problemas separados. [5]
O Bitcoin Core pode encaminhar ligações de saída por um proxy SOCKS Tor e criar um onion service Tor v3 para ligações de entrada. Desde a versão 22.0 ignora endereços Tor v2; uma configuração errada pode deixar tráfego DNS ou clearnet contornar o percurso pretendido, por isso importa a combinação de -proxy, -onion, -onlynet, -bind e firewall. [1]
As ligações I2P usam um router I2P externo com interface SAM, normalmente em 127.0.0.1:7656. O Bitcoin Core suporta I2P desde a versão 22.0 e, ao aceitar ligações, cria por defeito um endereço I2P persistente e a sua chave; com -i2pacceptincoming=0 usa um endereço transitório em cada ligação de saída, embora a contraparte I2P veja o endereço do iniciador. [2]
CJDNS é um overlay IPv6 cifrado com endereços em fc00::/8 e routing baseado em chaves públicas. O Bitcoin Core suporta-o desde a versão 23.0 através de -cjdnsreachable; a documentação avisa expressamente que CJDNS não esconde emissor e destinatário dos routers intermédios e que não se deve depender apenas dele quando há poucos peers. [3]
BIP 155 introduziu as mensagens sendaddrv2 e addrv2 com endereço de comprimento variável e network IDs separados para Tor v3, I2P e CJDNS. Um node pode assim guardar e divulgar esses endpoints; anunciar um endereço, só por si, não prova que o node use essa rede nem que tráfego específico tenha passado por ela. [4]
Usar várias redes em simultâneo pode melhorar a disponibilidade e dificultar um ataque eclipse ou partition, pois o node dispõe de caminhos diferentes para peers. A mesma configuração pode ligar identidades aparentemente separadas: um adversário pode comparar tempo de atividade, comportamento, endereços anunciados em conjunto ou tráfego em clearnet e na rede overlay. [1]
Tor, I2P e CJDNS apresentam compromissos diferentes de latência, número de peers disponíveis, visibilidade do endpoint e resistência Sybil. O modo onlynet pode limitar fugas para outra rede, mas um conjunto menor de peers pode atrasar a sincronização e aumentar a dependência de poucos nodes; nenhuma opção corrige erros de wallet ou análise da blockchain. [3]
A verificação deve observar sockets reais e o estado do node: getnetworkinfo, -netinfo, -addrinfo e getpeerinfo mostram endereços locais, quantidades de endpoints conhecidos e ligações concretas. Além da configuração do Bitcoin Core, é necessário verificar o router Tor ou I2P ativo, a interface CJDNS, o caminho DNS, binds, firewall e se o tráfego de entrada e saída usa realmente a rede pretendida. [2]
Para ter uma visão mais completa, leia este verbete junto com Privacidade no Bitcoin, Full Node, Bitcoin Core, Dandelion++, Transação, Lightning Routing. Também há referências a este verbete em Paralelní Polis, Reusable Proofs of Work, Mix Network, Sybil Attack.
01Tor torna uma transação Bitcoin anónima?+
Não. Tor pode esconder o percurso de rede ou o endereço IP comum do node, mas a transação continua registada publicamente na blockchain. Coin selection, reutilização de endereços, valores, timing e uma ligação a uma exchange podem identificar o utilizador mesmo quando Tor funciona corretamente.
02Qual rede de anonimato é melhor para Bitcoin?+
Não existe resposta única sem um threat model. Tor tem o suporte mais amplo, I2P oferece uma rede interna diferente e CJDNS um overlay cifrado rápido que não esconde endpoints da mesma forma. Configuração verificada, número de peers independentes e limites à correlação de identidades importam mais do que o nome.