Maleabilidade de transações

O pagamento continuava funcionando; só o nome dele mudava. O Bitcoin fechou a brecha por etapas entre 2015 e 2017, e o SegWit terminou o trabalho para as entradas que guardam as assinaturas na testemunha. As entradas legadas continuam maleáveis, o que é mais uma razão para guardar bitcoins em um endereço bc1.

Como funciona

Um id de transação é um hash dos bytes da transação, então alterar qualquer byte produz um id diferente, e em uma entrada legada a assinatura é um desses bytes.

Três tipos de folga tornavam possível uma alteração sem quebrar nada.

A primeira é aritmética. Uma assinatura ECDSA é um par de números, r e s, e para cada s válido existe um segundo valor igualmente válido: a ordem da curva menos s. Qualquer pessoa que observe a rede pode trocar um pelo outro e a verificação continua sendo aceita.

A segunda é a codificação. As assinaturas vinham envolvidas em DER, e a biblioteca da qual o bitcoin dependia aceitava variantes descuidadas: bytes zero à esquerda sobrando, marcadores de comprimento não canônicos, um preenchimento que nenhum codificador cuidadoso emitiria. Cada variante gerava um id diferente ao ser submetida ao hash.

A terceira é o script de desbloqueio em volta da assinatura. Colocar um item inofensivo extra na pilha deixava o resultado do script idêntico e os bytes serializados diferentes.

Os consertos chegaram uma camada por vez. O BIP66 transformou a codificação DER estrita em regra de consenso na altura 363.725, em 4 de julho de 2015, uma ativação lembrada sobretudo porque várias pools grandes estavam construindo sobre cabeçalhos que não tinham validado e produziram uma bifurcação de seis blocos naquela tarde. O Bitcoin Core 0.11.1, lançado em outubro de 2015, transformou os valores baixos de s em regra de política de retransmissão, documentada depois como BIP146. O BIP62, uma tentativa de enumerar e proibir todas as fontes restantes, foi abandonado por ser inviável e conserva até hoje o status Withdrawn. O que resolveu a questão foi o SegWit, ativo na altura 481.824, em 24 de agosto de 2017: as assinaturas passaram para a testemunha, o id é calculado sem a testemunha e, para uma entrada segwit, simplesmente não sobra nada para alterar.

Onde isso aparece

A maleabilidade nunca causou roubo; causou falhas de contabilidade, e é essa ainda a forma do risco.

A uma plataforma que guarda seus fundos e acompanhava os saques pelo id que havia transmitido podia ser mostrada uma transação confirmada com um id diferente, e ela podia concluir que o próprio pagamento havia falhado e enviar os bitcoins de novo. Esse padrão causou perdas reais em corretoras em 2014, e é por isso que operadores sérios conciliam por endereço de saída e valor, e não apenas pelo id.

As transações encadeadas foram a outra vítima. Uma transação filha que gasta uma transação pai não confirmada identifica a transação pai pelo id, então uma transação pai alterada deixa a transação filha permanentemente impossível de gastar. Qualquer protocolo que assine um reembolso antes de a transação de funding ser transmitida, que é exatamente o que a abertura de um canal Lightning faz, era inseguro de construir até os ids se tornarem estáveis.

Para quem compra e guarda, um único hábito cobre tudo isso. Um id não confirmado não é um fato. Ele ainda pode mudar por maleabilidade nas entradas legadas, e agora muda com frequência por um motivo sem relação, porque o Bitcoin Core retransmite o replace-by-fee completo por padrão e um remetente que aumenta a taxa publica um id novo. Espere uma confirmação e depois informe o id a quem pedir.

Maleabilidade de transações vs gasto duplo

A maleabilidade move o rótulo; um gasto duplo move o dinheiro. Em uma transação alterada, os mesmos bitcoins chegam ao mesmo endereço pelo mesmo valor, e só o software que memorizou o id antigo percebe que algo aconteceu. Em um gasto duplo, uma transação concorrente envia esses bitcoins para outro lugar e uma das versões acaba sem valor. Confundir as duas coisas ensina as pessoas a desconfiar de pagamentos confirmados, que é a lição errada: um id confirmado nunca foi maleável, porque a maleabilidade só se aplicava enquanto uma transação estava sem confirmação.