A ‘guerra’ sobre o que pode ou não ser armazenado na blockchain do Bitcoin se transformou, neste fim de semana, em uma crise de governança no principal repositório de propostas técnicas da rede.
Mark “Murch” Erhardt, um dos seis editores de Bitcoin Improvement Proposals (BIPs), apresentou neste domingo (9) uma moção para retirar Luke Dashjr da função de editor. O pedido foi formalizado no pull request nº 2248 do repositório bitcoin/bips e apoiado por outro integrante do grupo, Olaoluwa “Laolu” Osuntokun.
O movimento aconteceu menos de 24 horas depois de o BIP 110 provocar uma separação entre os nós que decidiram aplicar sua fase de sinalização obrigatória e a cadeia do Bitcoin sustentada pela esmagadora maioria do poder computacional. O ramo que aplicava o BIP 110 produziu dois blocos e, até o fechamento desta reportagem, permanecia parado na altura 961.633.
O pedido não “bane Luke do Bitcoin”, não apaga suas contribuições e tampouco o proíbe de desenvolver software ou apresentar novas propostas. Se aprovada e acompanhada das medidas administrativas correspondentes, a mudança retiraria de Luke a autoridade editorial para tarefas como atribuir números, revisar a conformidade formal e incorporar documentos no repositório de BIPs.
“Recomendo que Luke Dashjr seja removido da posição de editor de BIPs”, escreveu Murch. Para ele, 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.
Até o fechamento, não havia comentário público de Dashjr no PR, e a reportagem não localizou uma resposta dele à moção nas fontes abertas consultadas.
A discussão ganhou uma nova manifestação com uma mensagem pública de Michael Tidwell dirigida a Luke Dashjr. Embora tenha agradecido sinceramente pelos anos de trabalho e reconhecido suas contribuições históricas, Tidwell afirmou considerar correta a saída do desenvolvedor e defendeu que ele renuncie voluntariamente, em vez de ser removido por meio do processo informal em andamento. Em sua avaliação, tornou-se improvável que Dashjr consiga manter uma relação de trabalho eficaz com integrantes do ecossistema do Bitcoin Core daqui em diante.
Tidwell acrescentou que a OCEAN continuará precisando de uma liderança técnica forte na área de mineração descentralizada e que, caso a nova cadeia baseada em prova de trabalho mencionada por ele avance, também haverá necessidade de um editor de BIPs próprio. Ele desejou sucesso aos próximos projetos de Dashjr e elogiou o trabalho realizado pela OCEAN, mas encerrou com uma crítica à comunicação do desenvolvedor: sugeriu que Luke verificasse se não havia bloqueado pessoas que acreditava terem deixado de falar com ele e afirmou que teria enviado a mensagem em particular caso não estivesse bloqueado.
Na minha opinião, esta é a decisão certa. Além disso, é melhor deixar o cargo por vontade própria do que ser forçado a sair por meio desse processo informal (francamente, é constrangedor que isso pareça adequado, dadas as suas contribuições históricas). Acredito que esteja claro para a maioria (e espero que para você também) que dificilmente você conseguiria trabalhar de forma eficaz com o Core daqui para frente.
Quanto à “comunicação”: certifique-se de não ter bloqueado acidentalmente alguém que você acha que parou de falar com você… por exemplo, se eu não estivesse bloqueado, teria enviado isso apenas como uma mensagem direta (DM). Obrigado, Tidwell
BIP 110 não ativou suas regras na cadeia dominante
O estopim da crise exige uma distinção técnica. Embora o último fim de semana tenha sido descrito por apoiadores 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 do Bitcoin.
O que começou na altura 961.632, no sábado (8), foi a fase de mandatory signaling, ou sinalização obrigatória, prevista apenas pelo software que implementa o BIP 110. A proposta determinava que, a partir desse 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, equivalentes a 2,53%. O limiar especificado era de 1.109 blocos, ou 55%, segundo o monitor público da proposta. Em vez de produzir uma adesão ampla, portanto, a chegada da altura programada expôs a incompatibilidade.
A cadeia com maior trabalho acumulado aceitou um bloco 961.632 sem a sinalização. Nós que não aplicavam o BIP 110 continuaram normalmente a partir dele. Já os nós que aplicavam a proposta rejeitaram esse bloco e passaram a aguardar uma alternativa que carregasse o bit exigido.
Um bloco alternativo 961.632 com sinalização foi encontrado e o ramo recebeu mais um bloco, o 961.633. Depois disso, parou de avançar. Na atualização das 18h38, horário de Brasília, 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.
Esses 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 do BIP 110, a fase de 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. Assim, essas transições agora só poderiam acontecer no ramo minoritário se ele voltasse a produzir blocos suficientes. Para os participantes que seguiram a cadeia dominante, as regras atuais do Bitcoin permaneceram inalteradas.
É daí que nasce a disputa semântica que tomou conta da comunidade. 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. Críticos passaram a chamar o resultado 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.
O que o BIP 110 queria mudar
Intitulado Reduced Data Temporary Softfork, o BIP 110 foi apresentado pelo autor pseudônimo Dathon Ohm. O documento 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.
O BIP propunha aplicar durante aproximadamente um ano sete restrições adicionais de consenso:
- Limitar novos
scriptPubKeysa 34 bytes, com exceção de saídasOP_RETURN, que poderiam ter até 83 bytes. - Limitar a 256 bytes cargas de
OP_PUSHDATAe 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_SUCCESSem Tapscript. - Invalidar a execução de
OP_IFeOP_NOTIFem 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 uma camada de armazenamento de arquivos e devolver prioridade aos pagamentos. O próprio 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 (como os Ordinals e NFTs no Bitcoin).
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. Como relatado anteriormente pelo Cointelegraph Brasil, 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.
A acusação de conflito de interesse
Na moção publicada neste domingo, 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 o segundo episódio. O PR nº 2115, intitulado “BIP-110: esclarecer a regra 2, atualizar a implantação e especificar o uso de GBT”, foi aberto em 5 de março, às 03h29min20s UTC. Luke o incorporou às 03h39min46s, 10 minutos e 26 segundos depois.
A alteração tinha 28 adições e sete remoções. Além de esclarecer quais itens de testemunha estariam sujeitos ao limite de 256 bytes, o patch especificou a sinalização obrigatória no getblocktemplate e alterou a máquina de estados para incluir o estágio de expiração. Depois da incorporação, Murch comentou que, se o PR tivesse permanecido aberto por mais tempo, outras pessoas poderiam ter se manifestado.
Murch acrescentou que essa rapidez destoava da participação habitual de Luke. Segundo seu levantamento, Dashjr teria produzido menos de 1% dos comentários feitos por editores desde a ampliação do grupo, em abril de 2024, e aquela teria sido sua primeira incorporação desde maio do mesmo ano. Esses percentuais são uma alegação acompanhada da moção.
Há, contudo, uma nuance relevante. A proposta original não foi incorporada às pressas por Luke. O PR nº 2017 foi aberto em 24 de outubro de 2025 e permaneceu em revisão por mais de três meses. Quem o incorporou, em 7 de fevereiro de 2026, foi o próprio Murch, depois de solicitar ajustes e concluir que o documento atendia aos requisitos editoriais para publicação.
Laolu apoia a remoção e nega “punição” por defender um fork
Olaoluwa Osuntokun, também editor de BIPs, apoiou a moção apresentada por Murch.
Em sua manifestação, Laolu afirmou que o caso não deveria ser interpretado como punição a um desenvolvedor por defender um fork. Segundo ele, qualquer participante é livre para promover ideias controversas e lançar software incompatível se considerar necessário. O ponto decisivo seria a confiança necessária para ocupar uma função editorial.
Para Osuntokun, Luke recebeu críticas técnicas de diferentes partes do ecossistema, não se engajou adequadamente com elas e usou a posição para acelerar o BIP 110. Ele também afirmou que a continuidade do ramo minoritário cria um conflito de interesse entre a liderança de um projeto concorrente e o papel de guardião do processo de padronização do Bitcoin.
“Isso não é sobre ‘punir’ um desenvolvedor por defender um fork”, escreveu Laolu. “É sobre saber se alguém que contorna os processos editoriais quando isso o beneficia […] pode receber a confiança de uma posição editorial.”
O que faz um editor de BIPs, e o que a remoção não faria
O BIP 3, que define o processo atual, lista seis editores: Bryan Bishop, Jon Atack, Luke Dashjr, Murch, Laolu e Ruben Somsen.
As responsabilidades são administrativas e editoriais. O grupo acompanha a lista de e-mails e o repositório, verifica se uma ideia foi discutida publicamente, confere formato e licença, avalia se a especificação é compreensível e tecnicamente completa, atribui o número e incorpora o documento quando ele está pronto.
A posição oferece influência real: um editor pode acelerar, atrasar ou exigir ajustes antes de uma proposta passar a integrar o arquivo oficial de BIPs. Por isso, a percepção de imparcialidade é importante. Mas o cargo não permite ativar mudanças no consenso, obrigar mineradores a instalar software ou decidir sozinho o que mercados reconhecerão como BTC.
A eventual aprovação do PR 2248 tampouco baniria Dashjr dos repositórios públicos. Ele poderia continuar programando o Bitcoin Knots, operando a OCEAN, propondo mudanças, revisando código e participando da discussão como qualquer outro colaborador. Também permaneceriam intactos o histórico do Git e os documentos que ele ajudou a editar.
Moção não é automática e pode exigir ao menos um mês de debate
Existe ainda uma questão processual que torna o caso especialmente sensível. O BIP 3 é um Process BIP com status “Deployed”, isto é, um documento vivo que define as próprias regras editoriais. Seu texto estabelece que modificações devem alcançar “consenso aproximado” na lista de desenvolvedores: discussão aberta por pelo menos um mês, participação significativa e ausência de objeções fundamentadas que permaneçam sem resposta.
Como o PR de Murch altera diretamente a lista de editores dentro do BIP 3, a regra aponta para um processo de deliberação, não para uma remoção imediata. Não há no documento, porém, uma seção específica e detalhada sobre destituição de editores. A forma como os demais responsáveis aplicarão o critério existente será parte do teste de governança que a moção inaugurou.
O caso também abriu uma disputa paralela sobre o destino documental do próprio BIP 110. No PR nº 2245, Jon Atack propôs mover seu status de “Complete” para “Deployed” e imediatamente para “Closed”, registrando que a implementação chegou ao software de produção, mas que a tentativa de ativação fracassou e o ramo travou.
Matt Corallo contestou a passagem por “Deployed”, por considerar confuso usar esse rótulo para uma proposta cuja cadeia não avançou de forma relevante. Outro PR, o nº 2247, tentou excluir o BIP 110 do repositório, mas foi encerrado. Editores argumentaram que propostas fracassadas devem ser preservadas como registro histórico, em vez de apagadas.
Leave a Reply