Desenvolvedores do SegWit2x se recusam a incluir proteção contra ataques de repetição

O desenvolvedor e empresário de Bitcoin, Jimmy Song, em seu novo post para o blog Bitcoin Tech News, explicou detalhadamente as consequências para o Bitcoin em caso de recusa dos desenvolvedores do SegWit2x de incluir proteção contra o ataque de repetição durante a implementação do hard fork que eles pretendem realizar em novembro desse ano.

A equipe de desenvolvedores do Segwit2x confirmou que planeja realizar o hard fork no bloco 494.784. É enfatizado que, este código, embora inclua suporte ao Segregated Witness a partir da ativação, o mesmo será incompatível com as versões atuais do Bitcoin Core e UASF. No entanto, uma preocupação ainda maior para a comunidade é o fracasso do comando do Segwit2x em incluir proteção contra ataques de repetição – ou seja, atacar o sistema de autenticação gravando e reproduzindo mensagens corretas enviadas anteriormente ou suas partes.

O que está por trás dessa ameaça e quais podem ser suas consequências, o ex-vice-presidente de engenharia Armory elabora em seu blog.

I just published “Replay Attacks Explained” https://t.co/P9TwyUmar8

— Jimmy Song (@jimmysong) 21 de agosto de 2017

Transações Bitcoin

Para entender o que é um ataque de repetição, você precisa entender como as operações de Bitcoin funcionam.

O Bitcoin pode ser representado como um registro global, e as transações em Bitcoin funcional de forma análoga aos cheques bancários. E, como este registro global está em forma digital, qualquer um pode realizar sua auditoria baixando uma cópia completa da blockchain.

Isso também significa que todos os cheques bancários estão no espaço público. Ou seja, qualquer pessoa pode ver uma transação separada e certificar-se da autenticidade da assinatura digital.

Hard Fork

O Hard Fork é a essência da atualização global do registro. Se a atualização for feita por todos os membros da rede, apenas um registro global permanece. Se a atualização não for unanime, em vez de um registro global, dois serão formados: o registro original (legado) e o registro formado como resultado do fork.

Antes do fork, ambos os registros são idênticos. Ou seja, eles compartilham um histórico comum de transações. Mas depois do fork, conforme novos blocos são encontrados, esses registros têm transações diferentes e, portanto, saldos de conta diferentes. Isto é exatamente o que aconteceu, por exemplo, com o Hard fork que deu origem ao Bitcoin Cash em 1.º de agosto de 2017.

Ataque de repetição

Se antes de dividir a rede você tiver um certo número de moedas, após a divisão você terá o mesmo valor em ambos os registros. Mas, o que acontece se você quiser gastar dinheiro em apenas uma rede?

Há um problema, porque se você gastar dinheiro em um registro, outro usuário pode copiar o mesmo cheque com sua assinatura e enviá-lo para inclusão em outro registro. Isso mesmo, outra pessoa pode gastar seu dinheiro em outro registro, porque sua assinatura é válida em ambos os registros. Claro, o destinatário e o montante enviado devem ser idênticos (caso contrário, a assinatura será inválida), mas ainda sim representa um problema.

Uma pessoa que apresenta uma cópia de um cheque em outro registro reproduz a transação. E, se você quiser enviar dinheiro em apenas um registro, surge o problema, que chamamos de ataque de repetição.

O Bitcoin Cash resolveu esse problema alterando ligeiramente o cheque. Eles fizeram uma espécie de marca d’agua no cheque, o que mostra que esse cheque é destinado ao registro do BCH, mas não para outro registro.

Assim, qualquer nó [nó de rede] que conduz auditorias do Bitcoin rejeita automaticamente a verificação do Bitcoin Cash, porque o mesmo possui uma marca especial. E, assim como qualquer pessoa que realize uma auditoria no Bitcoin Cash, rejeitará o Bitcoin, uma vez que esta marca especial não estará presente.

Esta marca especial é chamada de proteção contra repetição, pois impede esse ataque.

Segwit2x e proteção contra ataques de repetição

Os desenvolvedores do Segwit2x se recusam a adicionar proteção contra o ataque de repetição. Em vez disso, eles dizem que se isso é um problema para a equipe do Bitcoin Core, então que eles adicionem uma solução.

Infelizmente, a maioria dos esquemas de proteção de repetição consiste em um hard fork. Como os hard forks não são compatíveis com versões anteriores e nem todos irão atualizar, isso causará dois ledgers diferentes (novamente). Muitos desenvolvedores do Bitcoin Core consideraram que um hard fork feitos às presas, sem o planejamento de no mínimo dois anos, levaria a esse cenário.

Então, se o Bitcoin Core adicionasse proteção de repetição no curto espaço de tempo para o hard fork Segwit2x (3 meses), isso provavelmente criaria três ledgers diferentes: Segwit2x, Bitcoin com proteção e Bitcoin Legacy. E, isso para nem mencionarmos o Bitcoin Cash que já foi um fork que ocorreu este ano.

A falha do Bitcoin Core de adicionar esta nota de proteção é consistente com a recusa de aceitar o pé duro Segwit2x. Se os desenvolvedores do Bitcoin Core não tiveram objeções ao hard fork por 3 meses, então um hard fork como o que o Segwit2x oferece faria sentido. No entanto, como a maioria dos desenvolvedores do Bitcoin Core acredita que 3 meses para se preparar para hard fork é um espaço de tempo muito pequeno, a inclusão de proteção contra ataques de repetição no código do Bitcoin Core está excluída.

Alternativas

Se você é um usuário de Bitcoin e quer se proteger de ataques repetidos após o hard fork do Segwit2x, você precisa separar suas contas em dois registros: Bitcoin Core e Segwit2x.

Uma das maneiras óbvias é misturar as moedas. Esse processo envolve a busca de uma transação em um dos registros que não podem ser reproduzidos em outro registro. Talvez você pense que tais transações não existem, mas há pelo menos uma categoria de transações que não podem ser reproduzidas.

As chamadas transações de “coinbase” (a recompensa que os mineiros recebem) que serão criadas após o fork, serão exclusivamente diferentes em ambos os registros. Assim, as transações “coinbase” não podem ser reproduzidas em outro registro. Se você criar uma transação que é misturada com uma transação que não pode ser reproduzida, outra transação não utilizável é criada como resultado. Portanto, quaisquer transações que sejam misturadas com as transações de coinbase não serão, em si mesmas, reprodutíveis.

Assim, corretoras e comerciantes podem acessar os serviços de mixagem para facilitar as transações em ambas as redes.

Conclusão

Para os usuários que não realizam transações com muita frequência, repetir a reprodução provavelmente não é um problema. Após o hard fork Segwit2x, esses usuários provavelmente se absterão de realizar transações até que uma solução clara e acessível seja desenvolvida para proteger contra ataques de repetição.

E, embora isso possa parecer terrível, dada a experiência adquirida como resultado do hard fork do Bitcoin Cash, as coisas podem não ser tão terríveis, conclui Jimmy Song.