Não fossem as notícias provenientes da China, como a proibição das Ofertas Iniciais de Criptomoedas (ICOs, na sigla em inglês) e o fechamento das exchanges chinesas, o assunto mais quente no mundo do Bitcoin nas últimas semanas teria sido o SegWit2X. Agora que a poeira parece ter baixado lá na Ásia, começaremos a ouvir bastante sobre isso e também sobre um outro importante e controverso termo: “replay attack protection” ou proteção contra ataque de repetição.
Antes de mais nada, vamos entender do que se trata o SegWit2X, que poderá dar origem a um novo Bitcoin. Aqui neste artigo, o chamaremos de B2X (apesar de ainda não ser um nome oficial).
O SegWit2X é, essencialmente, um hard fork, ou seja, uma atualização do software do bitcoin. Ele vem com a premissa de aumentar, no mínimo, em duas vezes (daí 2X) o tamanho dos blocos de transações da rede, ou seja, expandir o poder de processamento de transações de Bitcoin. Se implementado, os blocos poderiam ter um limite de capacidade mínimo de dois megabytes (2MB) e máximo de até oito megabytes (8MB).
Mas aí você deve estar se perguntando: não foi exatamente isso que aconteceu em agosto quando surgiu o Bitcoin Cash?
Praticamente, foi exatamente isso que ocorreu. Só que desta vez, o grupo de mineradores e as empresas que apoiam o B2X querem aumentar o tamanho do bloco e também desejam manter a funcionalidade do SegWit (Segregated Witness ou Testemunha Segregada, em tradução livre).
O SegWit é uma implementação que foi ativada ao software do Bitcoin no dia 23 de agosto de 2017. Ela tem como objetivo desmembrar as informações das transações da rede e torná-las mais leves, o que permite um aumento incremental do número de transações incluído em cada bloco.
O Bitcoin Cash, por exemplo, apesar de ter blocos de até 8MB, não possui o SegWit.
Atualmente, a rede do Bitcoin está apta a processar transações que compactuam com o SegWit. Por isso mesmo, alguns blocos na rede atualmente já excedem o limite máximo de um megabyte (1MB), que existe desde o surgimento do Bitcoin.
Como pode-se perceber, estamos falando de três grupos distintos: o pessoal do Bitcoin Cash, que não tem mais nada a ver com a história do Bitcoin original e só foi citado neste artigo para não causar confusão sobre essa questão dos blocos de 8MB; o grupo que sustenta o SegWit2X, ou seja, que quer aumentar o tamanho do bloco e manter o SegWit; e os defensores da rede do Bitcoin original (BTC), também conhecido como Bitcoin Legacy, que desejam manter apenas o SegWit e não querem mexer no tamanho do bloco.
Analogamente, seria como se um país estivesse em conflito civil e houvesse três grupos divergentes. Um deles já se separou e criou seu próprio país (Bitcoin Cash). O restante do país está discutindo se irá se dividir em dois (Bitcoin Legacy e B2X) ou se, por acaso, o grupo dissidente irá predominar e mudar o nome (e as regras) do país para B2X e, de certa forma, aniquilar o Legacy.
O capítulo final dessa novela, que talvez ainda não tenha sequer chegado ao clímax, está marcado para o dia 23 de novembro, quando poderemos presenciar (ou não) o surgimento do B2X. Mas, até lá, tem muita coisa para acontecer (ou não). Vamos ver o que temos pela frente.
Acordo de Nova York
Em 23 de maio, em Nova York, durante a Consensus, importante conferência do setor, foi firmado um acordo entre diversos mineradores e empresas que ficou conhecimento como New York Agreement (NYA). Ele basicamente estipulava duas coisas:
1) Ativação do SegWit no Bitcoin (já concluída)
2) Aumento do tamanho do bloco de transações seis meses depois da assinatura do acordo.
O problema é que nem todos os players do setor concordam com o NYA. Atualmente, existe falta de consenso por vários motivos. O principal deles reside nas escolhas feitas pelo time de desenvolvimento do BTC1, nome do software cliente associado ao B2X. Liderado pelo CEO da Bloq, Jeff Garzik, este grupo, até agora, nega a possibilidade de implementar uma importante medida de segurança para a realização do hard fork: a aplicação do “replay attack protection”.
Justamente por este motivo, alguns signatários do NYA anunciaram publicamente ao longo das últimas semanas que não mais compactuam com o acordo.
O que é proteção contra repetição?
Como explicamos neste artigo, após uma eventual atualização na rede (hard fork), as duas blockchains serão idênticas, todas as transações passadas e, consequentemente, os “saldos” serão copiados da rede do Bitcoin Legacy para o rede do SegWit2X. Todo mundo que tiver Bitcoin terá o mesmo saldo equivalente de B2X.
Mas e se caso você quiser gastar moedas em uma rede e não quiser gastar na outra? É aí que vem o problema.
Se você gastar em uma rede, alguém poderá copiar a mesma transação, que contém a sua assinatura, e apresentá-la para ser incluída na rede que se ramificou. Ou seja, alguém poderá gastar o seu dinheiro na outra rede porque a sua assinatura é válida em ambas. Em outras palavras, uma repetição da transação será feita e a isso damos o nome de ataque de repetição.
Digamos, por exemplo, que a Maria tenha Bitcoin no momento do hard fork, o que significa dizer que ela também herdará a mesma quantidade na rede do B2X. Depois da atualização, ela deseja enviar Bitcoin ao João. Ela cria a transação para enviar um Bitcoin da rede original para o endereço do João também na rede original. Um minerador da rede original pega essa transação, a verifica, valida e inclui no bloco. O pagamento é confirmado e está tudo certo.
Mas essa mesma transação, como dissemos, é perfeitamente válida na rede do B2X. Qualquer um, incluindo o João, pode pegar a transação da Maria e transmiti-la na rede do SegWit2X para um minerador incluí-la em um bloco do SegWit2X. Isso pode até mesmo acontecer por acidente. Se o pagamento também for confirmado, Maria enviou sem saber não apenas Bitcoin, mas também um montante igual de B2X ao João. O mesmo raciocínio vale no sentido contrário: se alguém performar uma transação de um endereço do SegWit2X para outro, ela poderá ser replicada na rede do Bitcoin.
Por isso, a ausência de proteção contra repetição é um problema para ambas redes.
Tecnicamente, existem maneiras de separar o Bitcoin do B2X em ambas redes para assegurar que eles possam ser gastos apenas em uma rede. Isso, por exemplo, exigiria que novas moedas mineradas fossem misturadas em uma transação. Travas de tempo (time-locks) também podem oferecer soluções. Mas isso exige esforço e não é fácil de se fazer, especialmente para usuários comuns da tecnologia, que muito provavelmente não fazem a menor ideia disso que estamos discutindo aqui.
Para evitar esse cenário, uma das redes poderia adicionar uma regra ao protocolo para garantir que as novas transações sejam válidas somente em uma rede. A isso damos o nome de proteção contra repetição.
Quem deveria implementar a proteção contra repetição?
Quando o Bitcoin Cash decidiu se dividir da rede do Bitcoin, os desenvolvedores implementaram a proteção contra repetição e tudo funcionou o mais perfeitamente possível em relação a este potencial problema.
Os desenvolvedores do Bitcoin Core, o software principal do Bitcoin original, acreditam que o grupo dissidente (leia-se BTC1, que sustenta o SegWit2X) deveria adicionar ao código esta proteção. As razões para isso são as seguintes:
1) Seria relativamente mais fácil adicionar esta regra a um código que ainda está por nascer do que adicioná-la ao código existente do Bitcoin.
2) Não seria suficiente apenas o Bitcoin Core adicionar a proteção. Apesar de ser o software dominante, ele não é a única implementação do Bitcoin na rede. Temos ainda o Bitcoin Knots, Bcoin, Libbitcoin e outros clientes alternativos que também precisariam implementar a proteção. Vale citar que até mesmo os nós não completos da rede precisariam fazer isso.
3) Ainda mais importante, a realidade é que nenhum dos nós da rede do Bitcoin possui ataque contra repetição. E, logicamente, nem poderiam ter. Alguns dos nós são anteriores ao Acordo e Nova York. Então, mesmo que o Bitcoin Core e outras implementações adicionassem a proteção não seria suficiente, pois todos os usuários precisariam atualizar para a nova versão em um espaço de tempo muito curto, cerca de dois meses.
Assim, se apenas alguns nós da rede atualizassem o código, o Bitcoin poderia se dividir em três: a rede original sem proteção contra ataque (Legacy), o SegWit2X e o Bitcoin com proteção contra ataque de repetição.
Não é preciso pensar muito para concluir que essa alternativa não resolveria a situação, muito pelo contrário, apenas causaria mais confusão e incerteza.
O que diz o time de desenvolvedores do SegWit2X?
Até o momento, o BTC1 considera apenas a “proteção contra repetição opcional” como alternativa viável. Esse tipo de proteção tornaria determinadas transações especialmente criadas (“OP_RETURN”) inválidas na rede do SegWit2X. Qualquer um que quisesse separar as duas moedas (Bitcoin e B2X) poderia gastar os Bitcoins com tal transação, que seria confirmada apenas na blockchain do Bitcoin Legacy. Isso efetivamente dividiria as moedas em dois diferentes endereços (saídas) em ambas redes.
Essa alternativa seria o que podemos chamar de a “menos pior”, mas ainda assim não seria uma solução definitiva. O problema é que a blockchain do Bitcoin original precisaria incluir essas marcas de OP_RETURN nas transações, o que resultaria em mais transações na rede e exigiria dados extras em cada transação. Todos esses dados deveriam ser transmitidos, verificados e (ao menos temporariamente) armazenados por todos os nós da rede original. Isso seria um fardo para a rede do Bitcoin Legacy.
E, obviamente, não seria nada fácil utilizar essa opção. Ela poderia ser possível de ser performada por usuários profissionais, corretoras, provedores de carteiras e outros serviços, mas este é justamente o público que poderia sobreviver ao solavanco da ausência de proteção contra ataque de repetição. Os usuários comuns provavelmente teriam muitas dificuldades em utilizar essa alternativa.
Assim, a proteção contra repetição opcional oferece ajuda aos que menos precisam e faz muito pouco por aqueles que mais necessitariam de um ambiente seguro para efetivar transações.
Por que o time de desenvolvedores do B2X não quer implementar a proteção? Existem várias possíveis razões, algumas explícitas e outras especuladas.
A primeira delas é que a proteção contra repetição exigiria a atualização das carteiras com verificação simplificada de pagamento (SPV, Simplified Payment Verification) e de alguns outros clientes (thin clients) para enviar e receber transações na rede do SegWit2X. Com isso, nas palavras de Jeff Garzik, desenvolvedor do BTC1, a proteção contra repetição iria “quebrar” as carteiras SPV, que não ficariam compatíveis com o SegWit2X até serem atualizadas.
Esta afirmação é rebatida por outros desenvolvedores, pois caso o SegWit2X implementasse a proteção (e as carteiras SPV não atualizassem), estas carteiras ainda poderiam enviar e receber transações na rede do Bitcoin Legacy sem nenhum problema e elas não iriam acidentalmente gastar B2X.
Enquanto isso, se a rede do SegWit2X não implementar a proteção (e as carteiras SPV não atualizarem), os usuários podem não ter certeza se a carteira deles estará recebendo ou enviando transações de Bitcoin o B2X em ambas redes. Eles podem também não ter certeza se o saldo de suas carteiras refere-se ao Bitcoin original, ao B2X ou a ambos.
Ou seja, não implementar a proteção contra repetição no SegWit2X poderia realmente “quebrar” as carteiras SPV de forma ainda mais drástica.
O único e mais plausível cenário no qual a implementação da proteção talvez não quebrasse as carteiras SPV de maneira ainda pior seria caso a rede do Bitcoin original não sobrevivesse, ou seja, fosse aniquilada.
O próprio Acordo de Nova York fala em “atualização” do Bitcoin ao invés de divisão na rede e criação de uma nova moeda, como foi o caso do Bitcoin Cash. E baseado na sinalização dos mineradores e nas declarações de várias grandes empresas do ecossistema do Bitcoin, alguns signatários do NYA sustentam a tese de que a rede original do Bitcoin não irá sobreviver.
Logo, a implementação da proteção é, às vezes, considerada como uma admissão de que o SegWit2X irá se dividir da rede original do Bitcoin e se tornar uma nova moeda ao invés de ser considerada uma versão atualizada do Bitcoin.
Contudo, assumir que a rede original do Bitcoin não irá sobreviver é algo muito sério. Na realidade, a sinalização dos mineradores efetivamente não significa nada, pois os desenvolvedores do Bitcoin Core publicamente declaram que não irão adotar o hard fork.
Além disso, existe uma lista significativa de empresas que ainda não declarou apoio ao hard fork, incluindo duas das 10 maiores pools de mineração. Não está claro tampouco se muitos usuários individuais irão apoiar o SegWit2X. A implementação da proteção contra aniquilamento (wipe-out protection) também sugere que até mesmo os desenvolvedores do BTC1 não estão certos de que haverá apenas uma rede sobrevivente.
E talvez o mais importante de tudo é que ainda não está claro se a proteção contra repetição teria algum efeito definitivo sobre qualquer cenário. Se os mineradores, desenvolvedores, companhias e usuários quiserem considerar o SegWit2X como uma atualização do Bitcoin, eles o farão com ou sem a proteção contra repetição.
É por isso que algumas opiniões nas redes sociais sugerem que o BTC1 rejeita a proteção contra repetição com o único objetivo de ser o mais disruptivo possível.
Se a rede original do Bitcoin se tornar efetivamente inútil, o SegWit2X pode ter a maior chance de ser reconhecido como o efetivo Bitcoin.