SegWit2x e os Ataques de Repetição

Em novembro, os signatários restantes do “New York Agreement” (NYA) planejam implantar o hard fork do “SegWit2X” para duplicar o limite do bloco do Bitcoin, permitindo até 8 megabytes de espaço em bloco. Uma vez que nem todos apoiam este hard fork, isso poderia muito bem “dividir” a rede Bitcoin em duas blockchains e moedas incompatíveis, não muito diferentes do Bitcoin e do Bitcoin Cash (Bcash) há dois meses.

Mas este fork do NYA é controverso e não só porque falta consenso. Também é controverso devido às escolhas de design feitas pelo time de desenvolvimento por trás do BTC1, o cliente de software associado ao Acordo de Nova York. Talvez o mais importante, esta equipe de desenvolvimento, liderada pelo CEO da Bloq, Jeff Garzik, é que até agora ele se recusou a implementar a proteção de repetição, uma medida que o Bcash aceitou.

Então, o que é a proteção de repetição, por que o BTC1 deve implementá-lo … e por que não?
O que é proteção de repetição? E o que é ataque de repetição?

Bitcoin poderia ter outra “divisão” até novembro. Para o propósito deste artigo, nos referiremos à blockchain e a moeda que segue o protocolo Bitcoin atual como “Legacy Bitcoin” e “BTC”. A blockchain e a moeda que segue o fork do New York Agreement serão chamados como “SegWit2X” e “B2X”.

Se essa divisão ocorrer, as duas blockchains serão idênticas. Todas as transações passadas e (por isso) “balanços” são copiados da blockchain do Legacy Bitcoin para a blockchain do SegWit2X. Todos os que possuem BTC possuirão uma quantidade correspondente de B2X.

Sem proteção de repetição (replay protection), novas transações também serão válidas em ambas as blockchains. Isso significa que essas transações podem ser copiadas ou “repetidas”, de uma blockchain para a outra. Isso é chamado de “ataque de repetição” (replay attack).

Então, digamos que Alice detém BTC no momento da divisão, o que significa que ela também possui B2X após a divisão. Então, depois da divisão, ela quer enviar BTC para Bob. Então, ela cria uma transação que passa o BTC de um de seus endereços Legacy Bitcoin para um dos endereços do Bob do Legacy Bitcoin. Ela então transmite esta transação sobre a rede Legacy Bitcoin para um minerador Bitcoin Legacy para buscá-la e incluir em um bloco Legacy Bitcoin. O pagamento é confirmado; tudo está bem.

Mas esta mesma transação é perfeitamente válida na blockchain SegWit2X. Qualquer um – incluindo o Bob – pode tomar a transação Legacy da Alice e também transmiti-la pela rede SegWit2X para um minerador incluir em um bloco SegWit2X. (Isso pode até acontecer por acidente com bastante facilidade.) Se este pagamento também for confirmado, Alice enviou inadvertidamente para Bob não apenas BTC, mas também uma quantidade igual de B2X.

E, claro, tudo isso também é verdadeiro no sentido inverso. Se Alice envia B2X para Bob, ela pode acidentalmente mandar BTC também. A falta de proteção de repetição, portanto, é um problema para usuários de ambas as blockchains. Ninguém quer enviar dinheiro acidentalmente – nem mesmo se fosse “dinheiro grátis”.

Tecnicamente, há maneiras de “dividir” moedas em ambas as blockchains para garantir que elas só possam ser gastas em uma blockchain. Isso, por exemplo, exigiria que as moedas recém-extraídas fossem misturadas para uma transação. Os time-locks também podem oferecer soluções. Mas isso leva esforço e não é fácil, especialmente para os usuários comuns – para não mencionar que muitos usuários comuns nem sequer sabem o que está acontecendo, em primeiro lugar.

Para evitar esse tipo de incômodo, pelo menos um lado da divisão poderia adicionar uma regra de protocolo para garantir que as novas transações sejam válidas em uma cadeia e não a outra. Isso é chamado de proteção de repetição.
Por que o BTC1 deve implementar a proteção de repetição? (E por que não Bitcoin Core?)

Por que o BTC1 deve implementar a proteção de repetição? (E por que não Bitcoin Core?)

Em caso de divisão, pelo menos um lado deve implementar proteção de repetição. Mas muitos – desenvolvedores do Bitcoin Core e outros – acreditam que existe apenas uma opção viável. É o BTC1 que deveria fazê-lo.

Existem vários argumentos para isso.

Em primeiro lugar, faz mais sentido para o BTC1 implementar proteção de repetição, porque isso requer o menor esforço. BTC1 é um novo cliente que já está implementando novas regras de protocolo de qualquer forma, e ainda não foi amplamente implantado. Seria relativamente fácil para o BTC1 incluir proteção de repetição.

Enquanto isso, não seria suficiente para o Bitcoin Core implementar proteção de repetição por conta própria. Embora seja dominante, e até mesmo considerado por alguns como a implementação de referência que define o protocolo, o Bitcoin Core não é a única implementação do Bitcoin na rede. Bitcoin Knots, Bcoin, Libbitcoin e outros clientes alternativos terão que implementar proteção de repetição, também. (E isso sem levar em conta clientes de nodes não completos).

Mas, ainda mais importante, a realidade da situação atual é que todos os nodes implementados do Bitcoin não possuem proteção de repetição implementada. E, logicamente, eles não podem: alguns desses nodes ainda são anteriores ao Acordo de Nova York. Portanto, mesmo que o Bitcoin Core e outras implementações implementassem proteção de repetição em novos lançamentos de seu software, não seria suficiente. Todos os usuários também devem atualizar para esta nova versão em cerca de dois meses: um período de tempo muito curto para uma atualização em toda a rede.

Se apenas alguns dos nodes da rede atualizarem para essa nova atualização, o Bitcoin poderia dividir em três: Legacy Bitcoin, SegWit2X e “Bitcoin com Proteção de Repetição”. Desnecessário dizer que essa divisão de três vias provavelmente pioraria o problema.

Por fim, há um pouco de argumento filosófico. Quem quer adotar novas regras de protocolo, então o argumento é que tem a responsabilidade de se separar com a maior segurança possível. Esta responsabilidade não deve cair sobre aqueles que querem continuar usando o protocolo existente: eles devem ser livres para continuar usando o protocolo como está.

Muitos desenvolvedores – incluindo o fundador da RSK, Sergio Lerner, que redigiram a proposta SegWit2Mb em que o SegWit2X se baseia – argumentaram que o BTC1 deveria implementar proteção de repetição. Na verdade, muitos desenvolvedores pensam que qualquer hard fork, mesmo um hard fork que pareça inteiramente incontroverso, deve implementar proteção de repetição.

Mas até agora, a equipe de desenvolvimento do BTC1 só considerará a proteção de reprodução opcional.
O que está errado com a proteção de repetição opcional?

O que está errado com a proteção de repetição opcional?

A implementação da proteção de repetição opcional, conforme proposto pelo ex-desenvolvedor do Bitcoin Gavin Andresen, por exemplo, está atualmente na mesa para o BTC1.

Em suma, esse tipo de proteção de reprodução opcional tornaria inválida as transações Legacy Bitcoin especialmente criadas (“OP_RETURN”) na blockchain SegWit2X. Quem quiser dividir suas moedas poderia gastar seu BTC com essa transação. Essas transações devem confirmar na blockchain do Legacy Bitcoin, mas não na blockchain do SegWit2X. Isso efetivamente divide as moedas em diferentes endereços (“saídas”) em ambas as blockchains.

Essa proteção de reprodução opcional provavelmente é melhor do que nada, mas ainda não é uma solução definitiva.

Um problema é que a blockchain Legacy Bitcoin deveria incluir todas essas transações OP_RETURN. Isso provavelmente resultaria em mais transações na rede e exigiria dados adicionais para cada transação. Todos esses dados devem ser transmitidos, verificados e (pelo menos temporariamente) armazenados por todos os nodes do Legacy Bitcoin. Isso representa um fardo para a rede Legacy Bitcoin.

Mas, mais importante, provavelmente ainda não seria muito fácil utilizar esta opção. Pode ser suficiente para usuários profissionais – exchanges, fornecedores de carteiras e outros provedores de serviços -, além de usuários individuais com conhecimento avançado. Mas estes geralmente são também os tipos de usuários que poderiam dividir suas moedas mesmo sem proteção de repetição. Os usuários comuns, se eles estão conscientes do que está acontecendo, provavelmente achariam muito mais difícil utilizar a proteção de repetição opcional.

A proteção de repetição opcional, portanto, oferece ajuda para quem precisa menos e faz pouco para aqueles que mais precisam.

O Acordo de Nova York impede de ter a Proteção de Repetição?

Embora não esteja claro o que foi (ou é) discutido a portas fechadas, o Acordo de Nova York parece ser um acordo pequeno. Publicado em 23 de maio de 2017, ele realmente consiste apenas em dois pontos concretos:

Ativar a SegWit em um limite de 80%, sinalizando o bit4
Ativar um hard fork de 2 MB dentro de seis meses.

Com o primeiro ponto concluído através do BIP91, o único ponto restante é um hard fork de 2 megabytes antes de 23 de novembro. (Isso pressupõe que este fork não foi concluído com a criação do Bitcoin Cash, que é suportado por vários signatários do NYA. )

Notavelmente, muitos detalhes estão completos. Por exemplo, o contrato nem sequer afirma que os signatários devem executar o software BTC1 especificamente: qualquer implementação de software que implementa um hard fork de 2 megabytes pode servir. Isso pode até incluir uma implementação de software que implemente proteção de repetição. E, claro, nada no NYA interrompe o BTC1 de implementar proteção de repetição; Alguns signatários podem até ter esperado isso.
Por que o BTC1 não implementará proteção de repetição?

Existem realmente várias razões pelas quais o BTC1 – ambas declaradas e especuladas – por não querer adicionar proteção de repetição.

O primeiro motivo é que a proteção de repetição exigiria que as carteiras de verificação de pagamento simplificado (SPV) e alguns outros thin clients atualizassem para enviar e receber transações do SegWit2X. A proteção de repetição, portanto, nas palavras do desenvolvedor BTC1 Jeff Garzik, “quebrariam” as carteiras SPV; eles não seriam compatíveis com SegWit2X até serem atualizados.

Este enquadramento e escolha de palavras é contestado. Se o SegWit2X implementasse a proteção de repetição (e se as carteiras SPV não atualizarem), essas carteiras ainda poderiam enviar e receber transações do Legacy Bitcoin perfeitamente bem. Além disso, eles não gastariam acidentalmente B2X quando eles não quisessem.

Enquanto isso, se a cadeia SegWit2X não implementar a proteção de repetição (e se as carteiras SPV não atualizarem), os usuários podem não ter certeza se a carteira está recebendo ou enviando transações BTC ou transações B2X ou ambas. Eles também não podem ter certeza se o saldo em sua carteira é um saldo BTC ou um saldo B2X ou ambos. E se o poder de hash se deslocar de uma blockchain para outra ao longo do tempo, essas carteiras poderiam até mudar de exibir saldos BTC para saldos B2X ou vice-versa sem que os usuários saibam. (Este problema pode ser resolvido, até certo ponto, através de outra solução, mas isso ainda não foi implementado em nenhum outro.)

De fato, não implementar a proteção de repetição no SegWit2X pode, com toda a probabilidade, “quebrar” as carteiras SPV de forma muito pior.

O único cenário (plausível) em que a implementação da proteção de repetição talvez não “quebre” as carteiras do SPV é se não houver o Legacy Bitcoin. Na verdade, o acordo de Nova York especificamente pretende “melhorar” o Bitcoin, em vez de se dividir em uma nova moeda, como Bcash fez. E com base em sinalizadores de mineradores e declarações de intenções por várias grandes empresas Bitcoin, alguns signatários do NYA afirmam que o Legacy Bitcoin não poderá sobreviver.

A implementação da proteção de repetição é, portanto, às vezes considerada uma admissão de que o SegWit2X se separará do (Legacy) Bitcoin em algo novo e não será considerada a versão atualizada do Bitcoin.

Mas a suposição de que o Legacy Bitcoin não conseguirá sobreviver é grande. Na realidade, a sinalização dos mineradores é efetivamente sem sentido, enquanto o Bitcoin Core – a implementação dominante da Bitcoin – não adotar o hard fork. Há também uma lista significativa de empresas que não afirmaram que eles apoiem o hard fork, incluindo duas das top 10 pools de mineração. Da mesma forma, não está claro se muitos usuários (individuais) suportarão SegWit2X também. A implementação da wipe-out protection (outra medida de segurança) também sugere que mesmo os desenvolvedores do BTC1 não estão tão certos de que haverá apenas uma blockchain.

E, talvez, ainda mais importante, não está claro se a proteção de repetição afetaria qualquer coisa. Se os mineradores, desenvolvedores, empresas e usuários considerarem o SegWit2X uma atualização do Bitcoin, eles provavelmente o farão com ou sem proteção de repetição.

É por isso que também foi sugerido que o BTC1 está rejeitando a proteção de repetição com o objetivo específico de ser o mais perturbador possível. Se a blockchain do Legacy Bitcoin se tornar efetivamente inutilizável, o SegWit2X pode ter a melhor chance de ser reconhecido como o “Bitcoin”.

*Texto escrito por @AaronvanW.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *