Limitar dados arbitrários é um caminho perigoso para a censura em nível de protocolo. A força do Bitcoin está em sua recusa em discriminar usuários ou casos de uso.
Live estimate to the BIP-110 fork block, following the same countdown logic used by jlopp.github.io/knotzi-death-march.
O Bitcoin foi projetado para ser um "cano neutro". Ao definir certos dados como "spam", o BIP-110 introduz moralidade humana subjetiva na camada base. Se podemos filtrar imagens hoje, o que será filtrado amanhã?
Ref: Adam Back (Blockstream) → Página completa do argumento →À medida que o subsídio de bloco se aproxima de zero, o Bitcoin precisa depender da receita de taxas. As inscriptions já pagaram mais de 500 milhões de dólares aos mineradores. O BIP-110 remove essa renda, tornando a rede mais vulnerável a ataques de 51%.
Ref: Relatórios de Segurança dos Mineradores → Página completa do argumento →Filtros não impedem dados; eles os empurram para a clandestinidade. O BIP-110 incentiva pagamentos "fora de banda", em que usuários pagam mineradores em privado para incluir dados, criando um mercado centralizado e opaco para blockspace.
Página completa do argumento →"É uma tentativa de turba de impor mudanças para as quais não há consenso... o BIP-110 seria um ataque à credibilidade do Bitcoin como reserva neutra de valor."
As restrições técnicas da proposta trazem riscos que vão além da simples remoção de "spam".
Os limites na profundidade das árvores de script destinados a impedir inscriptions são as mesmas ferramentas usadas por BitVM e contratos inteligentes avançados. O BIP-110 pode inadvertidamente "quebrar" o futuro da escalabilidade do Bitcoin.
Ref: Crítica de Jameson Lopp → Página completa de consequências →Mudar retroativamente o que é "padrão" pode tornar transações pré-assinadas ou carteiras com timelock impossíveis de gastar. Críticos veem isso como um confisco forçado da propriedade dos usuários.
Ref: Análise do The Bitcoin Manual → Página completa de consequências →Baseadas nas notas aos mineradores de Jason Hughes de 15 de julho de 2026, estas objeções se concentram no que o BIP-110 muda para produtores de blocos, descoberta de taxas, coordenação e superfície política de ataque no longo prazo.
O BIP-110 tenta bloquear um estilo de inserção de payload, mas dados arbitrários podem migrar para outras construções de script e outros padrões de transação. Isso deixa os mineradores com risco de coordenação sem remover a demanda subjacente.
Ref: Jason Hughes, notas aos mineradores →Se relay público e ferramentas de wallet rejeitarem algumas transações, usuários grandes ainda podem contornar esse caminho e negociar diretamente com mineradores ou pools. O resultado é menos transparência nas taxas e mais vantagem para insiders.
Ref: Jason Hughes, notas aos mineradores →Quando um soft fork passa a ser usado para banir um uso desagradável de blockspace, discussões futuras deixam de ser estritamente técnicas. Mineradores passam a ser o ponto de pressão de cada nova campanha sobre o que o Bitcoin deve ou não permitir.
Ref: Jason Hughes, notas aos mineradores →Um rollout contencioso obriga mineradores e pools a adivinhar qual cadeia vencerá, como exchanges reagirão e se o risco de reorg subirá. O BIP-110 não é só uma posição de policy: é um evento de risco operacional.
Ref: Jason Hughes, notas aos mineradores →Demanda que paga taxas continua sendo demanda, mesmo quando alguns usuários não gostam da aplicação que consome blockspace. Substituir esse sinal de mercado por preferências sociais enfraquece a credibilidade do leilão neutro do Bitcoin.
Ref: Jason Hughes, notas aos mineradores →Quanto mais o Bitcoin depender de filtros personalizados, fluxo privado e coordenação entre cadeias contenciosas, mais a vantagem migrará para grandes pools com relações mais profundas e melhor postura legal ou comunicacional.
Ref: Jason Hughes, notas aos mineradores →Algumas das críticas públicas mais claras publicadas em blogs, cobertura jornalística e comentários online.
Em seu ensaio de 23 de fevereiro de 2026, Jameson Lopp argumenta que o BIP-110 aumenta o risco de chain split, pode congelar fundos em casos-limite, restringe upgrades futuros e ainda assim não impede dados arbitrários porque os usuários podem contornar as regras.
Ler: A Layman's Guide to BIP-110 →A cobertura dos comentários de Adam Back no X enquadra o BIP-110 como mais perigoso do que o problema que tenta resolver: ele alerta que a proposta prejudicaria a credibilidade do Bitcoin e poderia congelar alguns UTXOs por meio de restrições no nível de consenso.
Ler: Cobertura da Oposição de Adam Back →The Bitcoin Manual explica que um UASF pode pressionar os mineradores, mas também destaca a principal desvantagem: se o apoio econômico for superestimado, o BIP-110 pode desencadear uma cadeia minoritária, dividir liquidez e criar falhas de coordenação no ecossistema.
Ler: What Is BIP-110? →Se o BIP-110 causar um chain split controverso sem replay protection, a mesma transação pode ser válida em ambas as cadeias. Isso abre espaço para replays acidentais, confusão em depósitos, falso suporte de wallet e fraudes no estilo double-spend contra usuários e exchanges.
Ler: Lopp sobre riscos de split e replay →Lopp cita Andreas Antonopoulos para argumentar que espirais de pureza ideológica acabam em autoparódia. Nessa leitura, o BIP-110 é menos uma correção técnica e mais uma tentativa política de cancelar usos do Bitcoin que algumas facções não gostam.
Ler: Lopp citando Andreas sobre política de pureza →Lopp também aponta para a thread pública de Murch que rebate a alegação de que o BIP-110 pode vencer com segurança ao ativar com hashrate minoritário. Essa crítica atinge diretamente a ideia de que um rollout contencioso se resolveria de forma limpa.
Ler: Lopp linkando a refutação de Murch →No seu artigo de 23 de setembro de 2025, Lopp argumenta que o Knots herda um problema basico de confianca porque os binarios ainda eram servidos por uma infraestrutura que ele descreve como comprometida. O ponto e simples: se a higiene de release e fraca, os usuarios estao sendo convidados a confiar em uma pipeline de software mais arriscada.
Ler: It's Knot a Serious Project →Lopp tambem critica o Knots como um fork opaco de maintainer unico: o historico de merges e mais dificil de auditar, os merge commits nao sao assinados como geralmente acontece no Bitcoin Core e a revisao upstream nao se transfere de forma limpa. Isso importa porque mudancas de consenso controversas deveriam receber mais escrutinio, nao menos.
Ler: Lopp sobre o ciclo de software do Knots →Outro fio do artigo de Lopp e que a governanca do Knots nao e apenas tecnicamente controversa, mas tambem politicamente carregada: ele liga o projeto a hostilidade contra mixing, ferramentas de privacidade e ate a dano colateral para sistemas como Whirlpool e Lightning. Isso adiciona um risco de ecossistema mais amplo do que a propria mudanca de regra do BIP-110.
Ler: Lopp sobre privacidade e impacto no ecossistema →Em sua publicação no X de 15 de julho de 2026, Michael Saylor chama o BIP-110 de “Bitcoin Iatrogenic Proposal”: um tratamento que causa dano. A objeção é que mudar as regras de consenso do Bitcoin para lidar com dados indesejados pode ser mais prejudicial do que o problema que pretende resolver.
Ler: Michael Saylor no X →Saylor argumenta que há ameaças ao Bitcoin mais graves que o spam e que transformar esta disputa em uma mudança de consenso é o verdadeiro risco. O BIP-110 invalidaria transações atualmente válidas que pagam taxas e criaria um precedente prejudicial.
Ler: Michael Saylor no X →Na mensagem relacionada, Saylor atribui papéis distintos às taxas, aos nós, aos mineradores e aos detentores. Mudanças no protocolo devem conquistar alinhamento esmagador para que ideias ruins fracassem antes de prejudicar o Bitcoin.
Ler: Michael Saylor no X →DathonPwn relata uma possível falha de consenso numa atualização tardia para o BIP-110. No cenário descrito, nós atualizados a partir de software antigo conservam o histórico de cadeia existente, enquanto nós BIP-110 instalados de raiz rejeitam esse mesmo histórico, criando o risco de uma divisão oculta da cadeia.
Ler: DathonPwn no X →A falha reportada é séria porque a mesma cadeia histórica tem de ser avaliada de forma consistente. Se uma atualização em funcionamento aceita um histórico que uma nova instalação rejeita, os operadores podem executar sem saber nós que discordam sobre qual cadeia é válida.
Ler: DathonPwn no X →O alerta destaca um requisito básico do software de consenso: um nó atualizado em funcionamento e outro sincronizado de raiz têm de chegar ao mesmo estado de consenso. Se essa propriedade falhar, o BIP-110 acrescenta incerteza operacional justamente quando a rede precisa de coordenação fiável.
Ler: DathonPwn no X →