Este artigo é fruto da parceria entre o Criptomoedas Fácil e a Blockchain Academy na busca de trazer à comunidade de criptomoedas conteúdos conceituais e técnicos que ajudam na educação e compreensão deste novo universo disruptivo.
No artigo anterior, explicamos o é um Fork na rede do Bitcoin e contei brevemente sobre a ativação do protocolo SegWit, que permitiu, entre outras coisas, a criação das Side Chains (correntes paralelas) e o aumento da capacidade da rede.
O que significa SegWit?
O termo significa Segregated Witness, ou em português, Testemunha Segregada. O termo vem do fato de que este protocolo basicamente separa (segrega) a assinatura (testemunha) de uma TXIN (transação de entrada) para o final da transação.
Proposta
O protocolo visava resolver alguns problemas na rede Bitcoin, entre eles, dois dos mais importantes: a Maleabilidade nas Transações e a Quantidade de Transações por Bloco.
Maleabilidade nas Transações
Era possível que um nó mal intencionado replicasse uma transação verídica, alterando seu TXID (identificador da transação), causando assim um double-spend (gasto duplo) inválido que costumava cancelar a transação original e publicar a transação alterada. Acredita-se que este ataque tenha sido usado contra algumas Exchanges de Bitcoin, incluindo o Mt Gox.
Basicamente, um nó mal intencionado alterava dados não sensíveis de uma transação, fazendo com que ela continuasse válida e enviando exatamente os mesmos valores para as mesmas pessoas mas modificando seu TXID. Dessa maneira, alguém esperando por uma determinada transação nunca a veria validada em um bloco no blockchain. O golpe visava fazer com que a outra parte refizesse a transação, sendo que a primeira já havia sido completada.
Quando falamos de uma transação, as únicas coisas que importam são: as entradas (de onde vem os valores), as saídas (para onde vão os valores) e, é claro, os valores transferidos. Uma WTXID (witness transaction identifier) é gerada à partir, principalmente, destes campos. Fazendo assim com que todas as falhas conhecidas que poderiam permitir maleabilidade nas transações fossem removidas.
Para garantir a compatibilidade entre clientes que utilizam ou não o protocolo SegWit, as transações carregam tanto as TXID legadas quanto as novas WTXID e cabe a cada cliente utilizar ou ignorar cada uma delas.
O protocolo SegWit na verdade é a terceira iteração para resolver a maleabilidade nas transações e dessa vez nos parece que o problema foi resolvido, já que, como dito anteriormente, as assinaturas não são mais utilizadas para calcular o hash da transação e consequentemente seu identificador.
As duas falhas mais conhecidas e o que foi feito para mitigar os ataques está descrito tecnicamente à seguir.
OpenSSL e a verificação do DER ASN.1
Até 4 de Julho de 2015, era possível que um nó mal intencionado replicasse uma transação verídica, alterando seu TXID (identificador da transação), causando assim um double-spend (gasto duplo) inválido. Acredita-se que este ataque tenha sido usado contra algumas Exchanges de Bitcoin, incluindo o Mt Gox.
O ataque não é tão complexo, você deposita 1 BTC em uma exchange e mais tarde você faz um pedido de saque de 1 BTC de volta para sua carteira. Se você tem um Full-Node conectado com a corretora, você poderia alterar o TXID do saque usando a maleabilidade da transação.
A versão do OpenSSL utilizada no Bitcoin continha um erro na verificação da transação codificada em DER ASN.1. Ao invés de ignorar espaços em branco no final dos dados da transação o mesmo era incluído na geração do hash desta transação, ou seja, o TXID. Então bastava adicionar apenas um espaço para que o TXID da transação válida, já esperada pela outra parte, fosse alterado.
O seu depósito era então efetuado, mas sob um novo TXID. O ataque prosseguia com um contato com a exchange para informar que o depósito nunca aconteceu, desta maneira, outro depósito poderia ser feito para a carteira. Ao fazer isso repetidamente, uma grande quantidade de Bitcoins poderia ser retirado antes que a exchange percebesse o golpe. Há relatos de que possivelmente foi o que aconteceu com o Mt Gox, drenando seus fundos e tornando a exchange insolúvel.
Este erro foi corrigido no bloco 363.724 através do BIP66 em 4 de Julho de 2015 através de um Soft-Fork, onde Pieter Wuille alterou 4 verificações do DER ASN.1 efetuadas pelo OpenSSl nas assinaturas para que retornassem um erro, não permitindo assim qualquer que a maleabilidade fosse explorada:
- S1′ P1 CHECKSIG: A assinatura (S1’) é válida para a chave pública (P1) mas não segue o padrão DER;
- F’ P1 CHEGSIG NOT: A assinatura (F’) é inválida para a chave pública (P1) e não segue o padrão DER;
- 0 S1′ S2 2 P1 P2 2 CHECKMULTISIG: Uma das assinaturas (S1′) é válida para a chave pública (P1) mas não segue o padrão DER em uma carteira multi-assinada;
- 0 F S2′ 2 P1 P2 2 CHECKMULTISIG NOT: Uma assinatura (F) é inválida para a chave pública (P1) mas segue o padrão DER, a outra assinatura (S2′) é válida para a outra chave pública (P2) mas não segue o padrão DER em uma carteira multi-assinada.
ECDSA e a Assinatura Complementar
Até Outubro de 2015 uma nova falha foi utilizada para alterar o TXID de uma transação, utilizando a assinatura ECDSA complementar de uma assinatura válida.
A assinatura utilizada em uma transação de Bitcoin é criada à partir do esquema ECDSA, que nada mais é do que uma versão do DSA utilizando Curvas Elípticas. A assinatura consiste em um par de números (r,s) pertencentes a uma curva elíptica de ordem n, e isso é um problema, já que a matemática envolvida nas curvas elípticas permite que (r,−s mod n) seja calculado sem a necessidade de saber a chave privada utilizada na assinatura.
Então era possível repetir o ataque à uma exchange ao, por exemplo, alterar a assinatura de uma transação pela sua assinatura complementar, o que altera o hash da transação, ou seja, seu TXID.
Esta falha foi descoberta por Sergio Lerner e corrigida por Pieter Wuille através da PR #6769, onde os clientes passaram a utilizar o opcode SCRIPT_VERIFY_LOW_S. Dessa maneira o cliente Bitcoin passou a validar somente transações onde o s é par, ou seja, para criar uma transação é necessário gerar as duas assinaturas e utilizar a que tenha o s com o último bit 0.
Tamanho dos blocos
Outro problema resolvido pela ativação do protocolo SegWit foi o aumento da capacidade de transações nos blocos, que foi feito de uma forma muito elegante.
Ao invés de simplesmente aumentar o limite em MB, eles criaram uma nova medida chamada de weight (peso, em português). Para manter a compatibilidade com clientes anteriores eles também introduziram as medidas em virtual size (ou vsize), onde os bytes foram convertidos em vbytes, que são equivalentes a 4 unidades de weight, e 1 weight é equivalente à 1 byte. Os blocos criados depois da ativação do protocolo seguem a regra de consenso onde o tamanho máximo do bloco deve ser 1MB, mas agora o bloco pode ter até 1M vbytes, ou seja, até 4M weight (4MB gravados em disco e transmitidos pela rede).
Em uma transação legada, onde normalmente são utilizadas uma entrada P2PKH (com chave publica comprimida) e duas saídas P2PKH, são utilizados 226 vbytes, ou 904 weight, utilizando a nova medida.
Já em uma transação SegWit, equivalente à transação anterior, seriam utilizados 222 bytes, ou 525 weight, uma redução de 61% comparada à uma transação legada.
Para realizar este cálculo, todos os campos que representam witness (marcadores, flags e assinaturas) representam apenas uma unidade de weight e os outros campos são representados em vbytes (4 * weight). Na transação anterior temos 101 vbytes em campos tradicionais e 121 bytes em campos witness (121 + (101 * 4) = 525 weight).
Vale lembrar que as transações SegWit quase não reduzem o tamanho dos blocos em disco ou transferidos pela rede, o que muda é a maneira como medimos as transações. Caso um bloco seja totalmente preenchido com transações SegWit, seu tamanho máximo seria cerca de 2.3 MB, e não 4 MB, graças à composição de uma transação SegWit, que contém tanto campos medidos em weight quanto campos medidos em vbytes.
Benefícios
A implementação do protocolo SegWit tornou possível garantir a segurança em um lightweight node (nó leve), já que a WTXID pode ser calculada apenas com as partes sensíveis da transação, liberando assim cerca de 60% de espaço em disco necessário de um full node (considerando que todas as transações são SegWit).
O maior benefício do protocolo SegWit é a capacidade de conectarmos tanto Side Chains à rede Bitcoin como criar novas camadas que utilizam a moeda, pois temos a garantia de que as transações não estão sendo manipuladas, além do fato de que não é necessário tanto espaço e tempo para sincronizar a rede.
No próximo artigo
Em seguida vamos falar de uma das maiores promessas para realizar pequenos pagamentos com Bitcoin, a Lightning Network, uma nova camada que se conecta na rede através de smart contracts que só foram viabilizados graças à implementação do protocolo SegWit.
Leia também: Bitcoin em R$ 138.500 enquanto Ethereum dispara 13,5%
Leia também: Bitcoin 2.0 (parte 1): as divisões e atualizações da rede do Bitcoin