BIP 110: editores do Bitcoin pedem remoção de Luke Dashjr

O Bitcoin enfrenta uma crise de governança no repositório que centraliza as propostas técnicas da rede. Neste domingo (9), o editor de BIPs Mark “Murch” Erhardt protocolou uma moção para remover Luke Dashjr da posição de editor de Bitcoin Improvement Proposals. O pedido está no pull request nº 2248 do repositório bitcoin/bips e foi apoiado por Olaoluwa “Laolu” Osuntokun, outro integrante do grupo de editores. A ação ocorreu menos de 24 horas depois de o BIP 110 provocar a separação entre os nós que passaram a exigir sua sinalização obrigatória e a cadeia do Bitcoin seguida pela esmagadora maioria do poder computacional.

Na prática, a aprovação da moção não bane Luke do Bitcoin, não apaga suas contribuições nem o proíbe de desenvolver software ou apresentar novas propostas. Se implementada, a mudança retiraria do desenvolvedor a autoridade editorial para atribuir números a BIPs, revisar a conformidade formal e incorporar documentos ao repositório. “Recomendo que Luke Dashjr seja removido da posição de editor de BIPs”, escreveu Murch. Para ele, o episódio do BIP 110 apenas escancarou um problema que já se acumulava: conflito de interesse, baixa participação no trabalho cotidiano e colapso da comunicação entre os editores. Até o fechamento desta edição, não havia comentário público de Dashjr no pull request.

Moção mira autoridade editorial de Luke Dashjr

O alvo imediato da moção não é a atuação de Luke como desenvolvedor ou sua participação no ecossistema. O pedido de Murch se concentra na curadoria dos BIPs, a camada formal por onde passam as propostas que pretendem alterar o protocolo. Sem a posição de editor, Dashjr perderia a capacidade de decidir quais documentos entram no repositório, como são numerados e se atendem aos requisitos formais da comunidade técnica.

Na visão de Murch, o episódio do BIP 110 consolidou um problema que já vinha se acumulando havia anos: conflito de interesse, baixa participação no trabalho cotidiano e colapso da comunicação entre os editores. A moção, porém, não representa um afastamento completo de Luke. Ele continuaria livre para desenvolver software, defender propostas e contribuir com o debate público — apenas sem o poder editorial sobre o repositório oficial de BIPs.

BIP 110 não ativou regras na cadeia dominante

O estopim da crise exige uma distinção técnica. Embora apoiadores tenham descrito o fim de semana como a “ativação” do BIP 110, as sete novas restrições de consenso propostas pelo documento não entraram em vigor na cadeia dominante. O que começou na altura 961.632, no sábado (8), foi a fase de sinalização obrigatória prevista apenas pelo software que implementa o BIP 110. A proposta determinava que, a partir daquele bloco, seus nós rejeitassem qualquer bloco que não sinalizasse apoio por meio do bit 4 no campo de versão.

Na janela anterior de 2.016 blocos, somente 51 sinalizaram o BIP 110, o equivalente a 2,53%. O limiar especificado era de 1.109 blocos, ou 55%, segundo o monitor público da proposta. Em vez de produzir adesão ampla, a chegada da altura programada expôs a incompatibilidade: a cadeia com maior trabalho acumulado aceitou um bloco 961.632 sem a sinalização, e os nós que não aplicavam o BIP 110 continuaram normalmente a partir dele. Já os nós que aplicavam a proposta rejeitaram o bloco e passaram a aguardar uma alternativa com o bit exigido. Um bloco alternativo 961.632 com sinalização foi encontrado, e o ramo recebeu mais um bloco, o 961.633, antes de parar.

Às 18h38 deste domingo, o monitor mostrava a cadeia não aderente ao BIP 110 na altura 961.776, 143 blocos à frente. Na nova janela, nenhum dos primeiros 145 blocos da cadeia dominante sinalizava apoio. Os números são um retrato do momento e mudam à medida que novos blocos são minerados, mas a distância crescente indica que a tentativa não convenceu mineradores a abandonar a cadeia com maior trabalho acumulado. Pelo cronograma do texto oficial, a sinalização obrigatória iria da altura 961.632 à 963.647. O lock-in ocorreria na 963.648, e as novas regras só ficariam ativas na 965.664. Essas transições agora só poderiam acontecer no ramo minoritário se ele voltasse a produzir blocos suficientes. O BIP 110 foi desenhado como um soft fork: nós atualizados aplicariam um conjunto mais restritivo de regras. Mas, ao rejeitar blocos aceitos por praticamente todo o poder computacional, seus aderentes se separaram da rede dominante. Para quem seguiu a cadeia dominante, as regras atuais do Bitcoin permaneceram inalteradas.

O que o BIP 110 queria mudar

Apresentado pelo autor pseudônimo Dathon Ohm, o BIP 110 — Reduced Data Temporary Softfork — credita a Luke Dashjr o “rascunho original e aconselhamento”. Dashjr também é o principal mantenedor do Bitcoin Knots, implementação pela qual a proposta chegou aos usuários, e ocupa os cargos de presidente do conselho e diretor de tecnologia da mineradora OCEAN, que apoiou a sinalização.

A proposta previa sete restrições adicionais de consenso, com duração de aproximadamente um ano:

• Limitar novos scriptPubKeys a 34 bytes, com exceção de saídas OP_RETURN, que poderiam ter até 83 bytes;
• Limitar a 256 bytes cargas de OP_PUSHDATA e determinados itens de testemunha usados como argumentos de script;
• Invalidar o gasto de versões ainda indefinidas de Witness ou Tapleaf;
• Proibir o annex do Taproot;
• Limitar blocos de controle do Taproot a 257 bytes;
• Invalidar opcodes OP_SUCCESS em Tapscript;
• Invalidar a execução de OP_IF e OP_NOTIF em Tapscript.

UTXOs criados antes da ativação seriam preservados pelas regras anteriores. Depois de 52.416 blocos — aproximadamente um ano — as restrições expirariam automaticamente.

Para os defensores, o objetivo era impedir que o Bitcoin se consolidasse como camada de armazenamento de arquivos e devolver prioridade aos pagamentos. O documento argumenta que um minerador recebe uma taxa apenas uma vez, enquanto operadores de nós carregam indefinidamente os custos de baixar, validar e armazenar os dados inseridos na blockchain. Nessa visão, inscrições, imagens e outros conteúdos não monetários impõem uma externalidade que o mercado de taxas não distribui adequadamente.

Por que a proposta dividiu a comunidade

Os opositores enxergam um risco maior na solução do que no problema. Para eles, desde que uma transação pague a taxa e cumpra as regras vigentes, o protocolo não deveria distinguir usos “bons” e “ruins” do espaço de bloco. Também criticaram o limiar de apenas 55%, a sinalização forçada e as limitações sobre mecanismos do Taproot reservados para futuras atualizações.

O próprio BIP reconhece que não eliminaria completamente o armazenamento de dados, afetaria deliberadamente esse “espaço de uso” e poderia restringir construções avançadas como BitVM e alguns casos de Miniscript. O documento também admite cenários considerados improváveis nos quais certos fundos criados depois da ativação poderiam ficar temporariamente congelados ou ser gastos de forma inesperada.

A controvérsia é uma extensão da disputa iniciada com o Bitcoin Core 30. A remoção do antigo limite padrão para retransmissão de dados em OP_RETURN dividiu desenvolvedores. De um lado, defensores de políticas mais rígidas, como Dashjr, consideram inscrições e arquivos um ataque à função monetária da rede. De outro, desenvolvedores como Peter Todd defendem que filtros locais não devem ser convertidos em juízos de consenso sobre a finalidade de transações válidas.

Conflito de interesse e o futuro da governança

Na moção, Murch afirma que Luke usou a posição de editor de maneira incompatível com o processo estabelecido e favoreceu uma proposta na qual estava diretamente envolvido. Segundo o texto, Dashjr tentou atribuir publicamente um número ao rascunho antes de a proposta ser discutida na lista de e-mails de desenvolvedores. Murch também apontou que Luke incorporou uma atualização do BIP 110 minutos depois de sua abertura — o histórico público confirma esse segundo episódio.

O movimento ocorre em meio a uma disputa semântica sobre o que o BIP 110 realmente representou. Críticos passaram a chamar o ramo minoritário de “forkcoin” ou “110-coin”. Luke sustenta a leitura oposta: em publicações anteriores no X, afirmou que “BIP 110 é Bitcoin” e que rejeitá-lo seria uma tentativa controversa de hard fork.

Até o fechamento desta edição, o ramo minoritário do BIP 110 permanecia parado na altura 961.633, enquanto a cadeia dominante seguia avançando. A moção contra Dashjr segue aberta no repositório, sem resposta pública do desenvolvedor. O desfecho do processo pode redefinir não apenas quem controla a curadoria dos BIPs, mas também os limites do que a comunidade do Bitcoin aceita como mudança legítima de consenso.