Desenvolvedores do Bitcoin Core sob críticas intensas

Uma mudança de filosofia preocupante está em curso entre os desenvolvedores do Bitcoin Core.

No_Return

Bitcoin Core está novamente sob críticas. O desenvolvedor francês Antoine Poinsot lançou uma pedra no lago ao propor remover o limite quanto à quantidade de dados arbitrários (spam) que podem ser inseridos “legalmente” nas transações.

Aqui está, em essência, sua proposta (versão resumida) que ele detalha mais longamente em seu blog:

Por padrão, o Bitcoin Core só propaga e minera transações contendo no máximo um OP_RETURN que não exceda 83 bytes. […] Contudo, alguns conseguem contornar esse limite. Proponho então removê-lo para parar de incentivar técnicas de inserção de dados mais nocivas […].

Antoine Poinsot

Vamos começar explicando o que é “OP_RETURN“. Trata-se de um opcode que permite inserir dados arbitrários de forma limpa numa transação. Este método “oficial” oferece um espaço limitado de 83 bytes para esse fim.

As transações que usam o opcode OP_RETURN têm a particularidade de gerarem UTxOs que não podem mais ser gastos (unspendable output). Usar OP_RETURN serve para sinalizar aos nós que eles não precisam armazenar o UTxO da transação em questão.

[Chamamos de UTxO pequenos pedaços de código (os “scripts”) que ligam matematicamente os bitcoins a endereços BTC (os endereços são codificações de chaves públicas).]

A gota d’água foi quando o desenvolvedor Peter Todd propôs eliminar completamente a possibilidade dos nós configurarem eles mesmos o limite do OP_RETURN:

Vamos também remover a opção de configuração -datacarriersize […]. Este limite, de qualquer forma, é facilmente contornado via submissões diretas aos mempools dos mineradores (por exemplo, MARA Slipstream) ou certas técnicas de inserção.

Peter Todd

Vamos explicar tudo, sem pânico.

Dados não gratos

Sobre o que estamos falando exatamente? O que são esses “dados arbitrários” que tanto causam polêmica?

Comumente chamados de “inscrições”. As mais conhecidas são os “ordinais”. Trata-se geralmente de imagens Jpeg que ficam alojadas dentro dos scripts das transações (P2TR). Há também os STAMPS, ainda mais nocivos. Estes armazenam dados sob a forma de falsas chaves públicas e geram enormes quantidades de UTxO (Baremultisig).

Essas inscrições têm em comum o fato de contornarem o OP_RETURN para escapar de seus limites, o que não é sem consequências. Enquanto o conjunto de UTxO pesava apenas 4 GB antes da moda das inscrições, hoje já alcança 12 GB. Metade dos UTxO contém menos de 1000 sats, isto é, spam.

Esse crescimento ameaça a descentralização, pois fica mais caro instalar um nó (memória, RAM, IBD, etc). Outra desvantagem é que isso afeta o uso legítimo da rede, que é realizar transações monetárias.

Agora vamos esclarecer a expressão -datacarriersize. Trata-se do nome do parâmetro de configuração que define o limite do OP_RETURN. Por padrão, esse limite é fixado em 83 bytes nas versões recentes do Bitcoin Core.

Peter Todd aqui toca no que se chama de “policy rules”. Essas regras permitem filtrar transações para evitar sua propagação até os mempools dos mineradores para serem adicionadas a um bloco. O objetivo é impedir certos ataques de negação de serviço (DoS). Por exemplo, o Bitcoin Core não propaga transações que pesem mais de 100.000 bytes.

[O mempool (contração de memory pool) contém transações válidas aguardando para serem incluídas em um bloco. Cada nó tem seu próprio mempool e configurações de filtro distintas.]

Agora que as bases estão postas, vamos direto ao ponto. Já faz dois anos que o desenvolvedor Luke Dashjr recomenda filtrar transações que contenham inscrições.

O problema é que o pequeno conclave de desenvolvedores à frente do Bitcoin Core se recusa a fazê-lo.

Saber limitar os danos

O Bitcoin Core justificou sua passividade argumentando que filtros contrários aos interesses financeiros dos mineradores acabariam sendo contornados. Isso já é uma realidade com o sistema “slipstream” do minerador Marathon.

Slipstream permite contornar os nós da rede enviando as transações (que seriam filtradas) diretamente para o mempool da Marathon.

Certamente, mas esse serviço não é gratuito. Quanto mais caras as inscrições para produzir, menos haverá. Tudo é válido para limitar os danos. Sem contar que Marathon minera menos de 5% dos blocos.

É bem simples, apenas 30 transações OP_RETURN em 7 milhões ultrapassaram o limite de 83 bytes desde o início do ano. Isso representa uma taxa de sucesso de 99,9957% para o filtro anti-spam limitado a 83 bytes.

Voltando agora a Peter Todd. Sua proposta incomoda porque parece uma capitulação diante da indústria do spam. Ainda mais que muito provavelmente remover os limites do OP_RETURN não terá nenhum impacto positivo quanto ao spam.

Por quê? Pela boa e simples razão de que as novas técnicas de inserção são quatro vezes mais baratas do que com OP_RETURN porque se aproveitam do “witness”.

Esse enorme desconto está ligado ao soft fork SegWit, que fez com que o tamanho dos blocos passasse de 1 MB para 1 vMB. O “v” significa “virtual”.

Segwit, a origem do problema

SegWit é fruto de um compromisso da “Blocksize war”, um episódio que vale a pena explorar. Para ser claro, SegWit permitiu aumentar o tamanho dos blocos de 1 MB para 4 MB.

Isso se deve ao fato de que as transações SegWit são divididas em duas seções diferentes. Os bytes da primeira seção são contados como pesando 4 Vbytes, enquanto os bytes da seção witness pesam apenas um Vbyte.

Assim, um bloco contendo 1 MB de transações clássicas (sem SegWit) pesa 4 VMB. Um bloco de 4 MB contendo uma única transação transportando uma imagem de 4 MB no witness pesa 4 VMB.

O problema é que ninguém podia prever (na verdade, podia…) que o witness seria explorado por spammeiros. Os criadores do SegWit pensavam que a seção witness conteria apenas assinaturas ECDSA legítimas e que os blocos chegariam no máximo a 1,5 a 2 MB.

Hoje, a maior parte do spam está alojada no witness de scripts de transações P2TR. Esses scripts não se destinam a serem executados: servem somente como armazenamento para dados arbitrários (imagens, textos, JSON, etc.), até 4 MB por bloco.

Quem lucra com o crime?

Uma possível resposta inicial está no fato de que os filtros atrasam a propagação de blocos contendo OP_RETURNs que ultrapassam o limite de 83 bytes. O minerador Marathon, portanto, tem interesse financeiro para que esse limite seja removido.

O projeto Citrea de Jameson Lopp também se beneficiaria. O cypherpunk foi aliás um dos primeiros a apoiar a proposta de Peter Todd. A propósito, vale notar que Bitcoin Mechanic (CTO da pool Ocean) foi banido do Github Bitcoin por destacar esse conflito de interesse. Uma censura irônica…

Vamos terminar reforçando que Bitcoin é um sistema de pagamento. Facilitar outros usos que prejudicam a descentralização da rede é uma pílula difícil de engolir. Diante do diálogo surdo instalado com o Bitcoin Core, cada vez mais pessoas migram para outras implementações como o Bitcoin Knots.

Bitcoin Knots é uma versão modificada do Bitcoin Core mantida por Luke Dashjr. Trata-se de um cliente alternativo para a rede Bitcoin. Oferece funcionalidades extras e correções de bugs que os desenvolvedores do Core se recusam a fazer.

O próximo passo é cortar o financiamento a organizações como @OpenSats, @bitcoinbrink, @HRF, assim como retirar fundos dos ETFs que patrocinam desenvolvedores ditadores. Esperamos que a controvérsia seja suficiente para convencer o Bitcoin Core a não fazer nada.

Aqui está, para os anglófonos, uma longa tirada de Bitcoin Mechanic para entender bem onde estamos:

Se você ainda está aí, certamente apreciará este artigo sobre Bitcoin e a Ameaça Quântica.