Um caso para regras neutras, consenso firme, mercados abertos e inovação sem permissão
Muitos bitcoiners que respeito apoiam o BIP 110. Eles querem manter a validação acessível, proteger os operadores de nós de custos e conteúdos indesejados, preservar pagamentos acessíveis e manter o Bitcoin focado em dinheiro sólido, em vez de armazenamento de dados de propósito geral. Essas são preocupações sérias. Compartilho os objetivos. Discordo do remédio. (GitHub
Este artigo critica a proposta, não as pessoas por trás dela. Presumo boa fé. O Bitcoin é mais forte quando podemos discordar vigorosamente sem confundir aliados com inimigos.
Também não é uma defesa de cada inscrição, token, arquivo ou aplicação. Alguns podem ser frívolos, prejudiciais ou fraudulentos. A questão é mais restrita: um uso contestado de transações atualmente válidas e que pagam taxas deve ser resolvido alterando o consenso?
Nem todos os motivos abaixo têm o mesmo peso, e vários se reforçam mutuamente. O caso é cumulativo.
O que o BIP 110 Propõe
Este artigo aborda o BIP 110 versão 1.0.0, o "Reduced Data Temporary Softfork", avançado para Completo em 25 de junho de 2026. De acordo com o BIP 3, Completo significa que os autores concluíram seu trabalho planejado e recomendam a adoção. Não significa que o Bitcoin adotou a proposta ou que a comunidade chegou a um consenso. O repositório de BIPs afirma explicitamente que a publicação não estabelece que uma proposta é boa, tem consenso da comunidade ou está prestes a ser adotada. (GitHub
Durante um período ativo de aproximadamente um ano, o BIP 110 adicionaria sete restrições de consenso. Limitaria novos scriptPubKeys a 34 bytes, com uma exceção de 83 bytes para OP_RETURN; limitaria muitos payloads enviados e itens de testemunha de argumento de script a 256 bytes; proibiria gastar versões indefinidas de testemunha e Tapleaf, embora ainda permitisse a criação de tais saídas; proibiria o anexo Taproot; limitaria os blocos de controle Taproot a 257 bytes; rejeitaria Tapscripts contendo opcodes OP_SUCCESSx; e rejeitaria execuções de Tapscript de OP_IF ou OP_NOTIF. (GitHub
A proposta avaliza (grandfathers) as saídas de transações não gastas criadas antes da ativação. Essa é uma salvaguarda importante. Não afirmo que o BIP 110 confisca amplamente bitcoins existentes. Minha objeção é mais restrita: ele remove prospectivamente a funcionalidade de transações atualmente válidas, pode afetar fluxos de trabalho pré-assinados raros que abrangem a ativação, reduz a opcionalidade técnica e estabelece um precedente para usar restrições de consenso para desencorajar uma categoria de uso de outra forma válido. (GitHub
O BIP 110 também propõe uma implantação BIP 9 modificada. Usa um limite de sinalização de mineradores de 55 por cento, comparado com o limite de 95 por cento especificado no BIP 9; elimina o timeout convencional e o estado FALHOU; adiciona um período de sinalização obrigatória; garante o bloqueio na cadeia de aplicação o mais tardar em uma altura especificada; e adiciona um novo estado EXPIRADO após 52.416 blocos ativos. (GitHub
Como qualquer soft fork, o BIP 110 não é imposto por uma autoridade central. Os usuários escolhem qual software e regras aplicar. O risco surge quando participantes economicamente significativos aplicam regras materialmente diferentes, criando pressão, incerteza ou uma divisão da cadeia.
Os autores fornecem uma implementação de referência, vetores de teste, uma justificativa detalhada e uma discussão franca sobre as compensações. Esses são pontos fortes substanciais do documento. A proposta argumenta que a urgência e a duração temporária justificam o limite mais baixo e as restrições intencionalmente simples e diretas. Respeito a preocupação e o trabalho. Discordo do cálculo de risco. (GitHub
I. Neutralidade e Primeiros Princípios
1. Consenso é a intervenção mais poderosa do Bitcoin. Um soft fork torna alguns blocos que eram válidos sob regras anteriores inválidos para nós atualizados. Esse poder deve ser reservado para falhas claras, sérias e amplamente compreendidas.
2. Não é um reparo para uma falha de consenso estabelecida. O BIP 110 não corrige inflação, validação de assinatura, gasto duplo ou um bug crítico conhecido. Ele aborda uma externalidade e um caso de uso contestados, então o ônus da prova deve ser especialmente alto.
3. Eleva um julgamento contestado a lei do protocolo. A proposta move uma disputa sobre uso legítimo e externalidades da política de retransmissão, política de mineração e mercados para a validade do consenso.
4. O Bitcoin não pode ler intenções. A rede não pode saber se os bytes representam uma imagem, uma prova, um contrato, metadados, um registro de autenticação ou uma aplicação futura.
5. Proxies estruturais criam risco colateral. Como a intenção não pode ser conhecida, a proposta restringe formas técnicas que podem servir tanto a propósitos desfavorecidos quanto legítimos.
6. Uma mensagem social não é motivo suficiente para uma mudança de consenso. A especificação trata explicitamente a ativação como uma forma de comunicar que o armazenamento de dados é indesejado. O consenso deve ser alterado por razões técnicas ou monetárias convincentes, não principalmente para expressar desaprovação. (GitHub
7. Desaprovação não é invalidade. Uma transação pode ser trivial, especulativa, ofensiva ou desperdiçadora e ainda assim seguir as regras e pagar a taxa necessária para inclusão.
8. Estreita a liberdade econômica prospectiva na cadeia BIP 110. UTXOs pré-ativação são avalizados, mas os usuários que criam UTXOs durante o período ativo teriam menos maneiras válidas de estruturá-los e gastá-los do que sob o consenso existente.
9. Sistemas sem permissão devem tolerar experimentação não aprovada. Exigir que inovadores provem que seu uso é digno antes de construir inverte o significado de inovação sem permissão.
10. Inverte o conservadorismo do protocolo. Conservadorismo na camada base deve significar relutância em alterar o consenso, não entusiasmo em alterar o consenso em favor de uma filosofia de uso conservadora.
II. O Ônus da Prova Não Foi Atendido
11. "Spam" não é um primitivo de consenso. Não há opcode que possa distinguir spam de utilidade. Esses rótulos surgem do julgamento humano.
12. "Monetário" e "não monetário" não são claramente separáveis. Um canal de pagamento, prova de reservas, política de custódia, contrato inteligente ou compromisso de liquidação é tanto atividade financeira quanto dados.
13. Casos de uso conhecidos não são todo o espaço de design. A proposta diz que preserva todos os casos de uso monetário conhecidos. Inovação é definida pelo que ainda não é conhecido.
14. O próprio BIP não quantifica o ônus do nó que removeria. Ele descreve custos, mas não estima a largura de banda, armazenamento, carga de validação, limites de hardware ou o número de operadores de nós provavelmente ganhos ou perdidos.
15. Não quantifica o benefício de descentralização. A afirmação de que o BIP 110 melhoraria a descentralização não é acompanhada por um modelo ou alvo mensurável.
16. Não quantifica o alívio de pagamento. Não estima quanto as taxas de transação cairiam, por quanto tempo ou quantos usuários de pagamento se beneficiariam.
17. Combina custos distintos em um único diagnóstico. Crescimento do estado UTXO, largura de banda de sincronização inicial, armazenamento de arquivo, ônus de retransmissão e tempo de validação têm causas diferentes e podem exigir remédios diferentes.
18. A urgência é afirmada em vez de definida operacionalmente. A proposta chama a situação de urgente e de crise, mas não fornece nenhum limite objetivo no qual a intervenção do consenso se torna necessária.
19. Um limite histórico de política de retransmissão não é prova de um limite de consenso ideal. Um padrão de 83 bytes pode ser uma política útil sem se tornar uma regra de validade de bloco atemporal.
20. O limite de 256 bytes é heurístico. A justificativa o relaciona parcialmente ao tamanho de imagem compactada e grandes inteiros criptográficos, mas não estabelece 256 bytes como um limite ideal entre segurança e inovação. (GitHub
III. O Escopo Técnico é Muito Amplo
21. Sete mudanças de consenso separadas são agrupadas. Os participantes não podem apoiar uma restrição e rejeitar outra. Eles devem aceitar ou rejeitar o pacote.
22. A preocupação técnica mais forte é agrupada com restrições não relacionadas. ScriptPubKeys grandes podem aumentar os custos de estado UTXO e validação. Se isso criar um risco mensurável, merece uma proposta de escopo restrito por si só, não suporte automático para seis restrições adicionais. (GitHub
23. A política OP_RETURN de 83 bytes se torna consenso. Isso converte uma preferência configurável de retransmissão e mineração em uma regra de validade de bloco.
24. Os limites de 256 bytes restringem primitivas gerais. Eles miram o armazenamento de dados restringindo classes amplas de payloads enviados e itens de testemunha de argumento de script.
25. Gastar versões indefinidas de testemunha e Tapleaf seria desabilitado. Esses espaços não são usados hoje em parte porque são reservados para atualizações futuras.
26. O anexo Taproot seria desabilitado. O BIP 341 reserva o anexo para extensões futuras. Mesmo que os usuários não devam empregá-lo antes que seu significado seja definido, fechar um caminho de atualização deliberado deve exigir justificativa excepcional. (GitHub
27. A profundidade da Taptree seria reduzida. Um limite de bloco de controle de 257 bytes limita os caminhos de script revelados a sete níveis e pode restringir árvores de script complexas.
28. OP_SUCCESSx seria desabilitado mesmo em ramos não executados. O BIP 342 criou esses opcodes como hooks de atualização limpos para soft forks futuros. (GitHub
29. OP_IF e OP_NOTIF executados seriam proibidos no Tapscript. Os autores os consideram redundantes e comumente abusados, mas também reconhecem usos experimentais e possíveis eficiências do Miniscript.
30. A proposta aceita abertamente a falta de sutileza em troca de velocidade. Sua justificativa diz que uma abordagem mais equilibrada exigiria mais desenvolvimento e revisão, então escolhe restrições mais simples destinadas a uma implantação mais rápida. Urgência não substitui precisão no código de consenso. (GitHub
IV. Sacrifica a Compatibilidade e a Opcionalidade Futura
31. Fecha vários caminhos de atualização de uma só vez. Anexos, versões futuras de testemunha, versões futuras de Tapleaf e OP_SUCCESSx fazem parte do espaço de design reservado do Bitcoin. (GitHub
32. Reservado não significa inútil. Significa que designers anteriores preservaram deliberadamente o valor da opção para necessidades que ainda não haviam surgido.
33. Um fechamento de um ano ainda pode interromper os cronogramas de desenvolvimento. Os autores esperam que soft forks futuros exijam mais de um ano de coordenação, mas isso é uma estimativa, não uma garantia.
34. Pode complicar designs do tipo BitVM. A especificação reconhece que o limite do bloco de controle pode impedir a contratação avançada fora da cadeia.
35. Pode afetar Tapleaves gerados por Miniscript. A proposta reconhece que algumas saídas do compilador podem conter OP_IF e precisariam de ajustes.
36. Exige mudanças em ferramentas de carteira afetadas. A seção de compatibilidade retroativa afirma que o compilador Miniscript precisaria de modificação enquanto as regras estiverem ativas.
37. Cria um risco de acesso a fundos estreito, mas admitido. O BIP identifica candidamente cenários raros de Taproot pré-assinados nos quais UTXOs pós-ativação poderiam ser congelados ou gastos inesperadamente.
38. O aval é valioso, mas não é um isolamento completo. UTXOs pré-ativação são protegidos, mas fluxos de trabalho que criam ou gastam saídas afetadas durante a implantação ainda podem encontrar novas restrições.
39. Os usuários são aconselhados a migrar fundos potencialmente afetados. Uma proposta que exige que mesmo uma classe restrita de usuários migre não é um filtro sem custos.
40. "Nenhum caso de uso conhecido" não é uma prova de segurança. Sistemas privados, contratos não publicados, carteiras experimentais e protocolos futuros não são totalmente observáveis. (GitHub
V. Regras de Consenso Temporárias Ainda Criam Complexidade Real
41. Código de consenso temporário ainda é código de consenso. Deve ser especificado, implementado, revisado, testado, implantado, monitorado e posteriormente retirado.
42. O aval torna a validade dependente do histórico. A mesma construção de gasto pode ser tratada de forma diferente dependendo de quando o UTXO foi criado.
43. Regras dependentes do histórico aumentam a complexidade da implementação. Cada implementação deve identificar a altura de criação do UTXO relevante e aplicar as isenções de forma idêntica.
44. A ativação cria um limite crítico. Software e atores econômicos devem concordar sobre quando as novas restrições começam.
45. A expiração cria outro. Eles também devem concordar sobre quando as restrições terminam e o comportamento anteriormente restrito se torna válido novamente.
46. O BIP 110 adiciona um novo estado EXPIRADO. Isso estende a máquina de estado de implantação familiar com novo comportamento de consenso.
47. Remove o resultado convencional FALHOU. A implantação proposta não pode simplesmente expirar da maneira comum do BIP 9.
48. Cria várias janelas de coordenação. Sinalização voluntária, sinalização obrigatória, bloqueio, ativação e expiração introduzem cada uma oportunidades de divergência. (GitHub
49. Regras temporárias podem deixar artefatos permanentes. Código de carteira, procedimentos operacionais, contratos e controles de risco institucionais podem precisar de mudanças que sobrevivam à implantação.
50. Mais ramos de consenso significam mais superfície de bugs. Vetores de teste reduzem o risco conhecido, mas não podem enumerar todas as interações privadas ou futuras.
VI. Os Efeitos Econômicos e de Segurança São Incertos
51. A externalidade do nó é real, mas heterogênea. Cada nó de validação completa deve baixar e verificar blocos, enquanto nós podados podem descartar dados brutos de blocos antigos e limitar o armazenamento histórico. Os custos relevantes devem ser medidos separadamente. (Bitcoin Core
52. A questão do beneficiário da taxa não é exclusiva das transações de dados. Os mineradores coletam taxas enquanto os validadores arcam com alguns custos para cada transação. A magnitude pode diferir, mas a estrutura básica é universal.
53. Os custos técnicos devem ser medidos diretamente. Para uma determinada quantidade de dados e trabalho de validação, os custos de recursos surgem de bytes, estado, computação e largura de banda, não de se os observadores aprovam o propósito da transação.
54. O BIP 110 não pode eliminar a incorporação de dados. A especificação reconhece que os usuários podem dividir os dados em pedaços menores ou disfarçá-los dentro de estruturas permitidas. (GitHub
55. A evasão pode tornar as transações menos eficientes. Codificações fragmentadas ou ofuscadas podem consumir mais estrutura e complicar a análise sem eliminar a demanda subjacente.
56. O efeito na taxa é ambíguo. Suprimir um uso pode reduzir as taxas de pagamento, diminuir a receita agregada de taxas, deslocar a demanda para outras codificações ou produzir alguma combinação dos três.
57. A receita do minerador é mais importante à medida que o subsídio diminui. As taxas de transação são um componente da recompensa do bloco, enquanto o subsídio do bloco é reduzido pela metade a cada 210.000 blocos. (Bitcoin Developer Docs
58. A menor demanda agregada por taxas pode enfraquecer a segurança na margem. Na medida em que o BIP 110 reduz a demanda total por taxas, em vez de apenas realocá-la, uma receita menor do minerador pode reduzir o incentivo para comprometer poder de hash, tudo o mais constante.
59. A demanda diversificada pode tornar o mercado de taxas mais resiliente. Pagamentos, canais, sistemas de custódia, aplicações financeiras e outros usos não precisam atingir o pico ao mesmo tempo.
60. A especificação não modela a compensação de segurança. Ela argumenta por pagamentos mais baratos e custos de nó mais baixos sem estimar os possíveis efeitos na receita do minerador, no investimento em hash ou na profundidade do mercado de taxas de longo prazo.
VII. Melhores Ferramentas de Mercado e Política Existem
61. O Bitcoin já tem uma restrição de capacidade neutra em conteúdo. O peso do bloco impõe um limite comum à capacidade de transação de cada bloco. (GitHub
62. As taxas já racionam o espaço de bloco escasso. Os usuários expressam urgência através de lances, e os mineradores selecionam transações válidas sob suas próprias políticas.
63. O limite de bloco e o mercado de taxas não pedem aos usuários que declarem o propósito. Eles aplicam validade técnica e limites de recursos, em vez de um teste semântico de se uma transação é suficientemente monetária.
64. A política de retransmissão continua sendo uma ferramenta menos coercitiva. Implementações e operadores de nós podem escolher quais transações não confirmadas retransmitir sem redefinir blocos válidos. A política de transporte de dados do Bitcoin Core é configurável. (GitHub
65. A política de mineração continua voluntária. Os mineradores podem excluir classes de transação de seus próprios modelos de bloco sem forçar todos os nós de validação a rejeitar blocos que as contenham.
66. A política é imperfeita, mas a imperfeição não é falha. A submissão direta a mineradores pode contornar os filtros de retransmissão. Essa limitação merece análise, não um salto automático para a proibição de consenso.
67. Nenhuma transação tem direito à inclusão. Um minerador pode rejeitar uma transação sob sua própria política, mas tornar uma transação anteriormente válida inválida através de um fork é um ato muito mais consequente.
68. A precificação de recursos pode ser melhorada sem classificar o propósito. Se certas estruturas impõem custos desproporcionais, o Bitcoin pode estudar limites neutros em conteúdo ou precificação vinculada ao uso mensurável de recursos.
69. A poda e designs de dados opcionais merecem pesquisa contínua. Eles podem não resolver todas as preocupações, mas abordam os encargos de armazenamento mais diretamente do que uma regra destinada em parte a sinalizar que um uso é indesejado.
70. O próprio BIP concede que a política é geralmente o lugar certo para combater spam. Sua incapacidade de garantir filtragem perfeita não prova por si só que o consenso deve ser usado. (GitHub
VIII. Desencoraja a Inovação e a Adoção
71. Cria um efeito de intimidação. Os desenvolvedores podem evitar o Bitcoin se construções atualmente válidas puderem ser suspensas através do consenso para suprimir um uso relacionado.
72. Privilegia casos de uso existentes. "Todos os casos de uso monetário conhecidos" protege o presente, não o futuro.
73. Destrói o valor da opção antes que o valor possa ser descoberto. O melhor uso futuro de um hook de atualização pode ainda não ter um nome.
74. Fundações estáveis são importantes para contratos de longa duração. Carteiras, sistemas de custódia, canais de pagamento e protocolos financeiros precisam de confiança de que estruturas de transação válidas permanecerão disponíveis.
75. Estreita o espaço de design de script. Isso pode tornar algumas construções maiores, mais caras, menos elegantes ou temporariamente impossíveis.
76. Pode atrasar a pesquisa avançada de contratos. O BIP aceita explicitamente que o trabalho do tipo BitVM pode precisar esperar ou prosseguir em testnets e sidechains. (GitHub
77. Empurra a experimentação para longe do Bitcoin por consenso. Testnets e sidechains são úteis, mas os construtores não devem ser deslocados da camada base sem um caso de segurança convincente.
78. Futuros sistemas de Camada 2 podem depender dos hooks não utilizados de hoje. A opcionalidade da camada base pode suportar escala sem exigir atividade frequente na camada base.
79. As aplicações podem fortalecer o dinheiro. Melhores carteiras, custódia, liquidação, crédito, títulos e sistemas de prova podem aumentar a utilidade, liquidez e demanda do Bitcoin.
80. O Bitcoin não precisa escolher entre dinheiro e tecnologia. Sua força monetária pode ser reforçada por uma rede aberta que suporta carteiras seguras, contratos, custódia, liquidação e inovação.
IX. O Mecanismo de Ativação é Muito Agressivo
81. O limite de 55 por cento é um grande desvio do BIP 9. O BIP 9 especifica um limite de prontidão do minerador de 95 por cento; o BIP 110 propõe 55 por cento.
82. Uma restrição controversa deve exigir maior confiança, não menos. A duração temporária não torna a falha de coordenação inofensiva.
83. A sinalização do minerador não é um referendo sobre todos os usuários do Bitcoin. O poder de hash protege e ordena transações, mas detentores, exchanges, carteiras, comerciantes, custodiantes e empresas determinam quais regras e ativos aceitam economicamente.
84. A sinalização obrigatória altera o significado da não participação. Durante a janela especificada, os nós aplicadores rejeitariam blocos que não sinalizam o bit 4.
85. A implantação é projetada para ser bloqueada o mais tardar em uma altura predeterminada na cadeia de aplicação. Isso é mais forte do que meramente observar a prontidão voluntária.
86. A ausência de um estado FALHOU remove uma saída limpa. Uma proposta que não consegue atrair suporte voluntário suficiente deve poder expirar sem coordenação forçada. (GitHub
87. A maquinaria de ativação não pode fabricar consenso. Ela pode coordenar estados de software, mas não pode criar acordo social e econômico.
88. A aplicação divergente pode dividir a rede. Se participantes economicamente significativos aplicam regras de validade incompatíveis, o resultado pode ser uma divisão da cadeia ou incerteza prolongada.
89. Uma divisão temporária não seria trivial. Liquidez, custódia, liquidação, contabilidade e confiança do usuário poderiam ser afetados.
90. O consenso firme é o sistema imunológico do Bitcoin. Abaixar a barra para uma restrição de caso de uso contestada pode criar um risco mais sério do que o problema de armazenamento de dados visado.
X. O Precedente é Mais Perigoso do que o Alvo
91. As regras expiram, mas o precedente não. Campanhas futuras podem citar o BIP 110 como evidência de que o consenso pode ser usado para suprimir atividade válida desfavorecida.
92. A mesma lógica pode ser reutilizada. Uma facção pode rotular outro uso como não monetário, prejudicial, legalmente arriscado ou não suportado e buscar sua exclusão.
93. "Uso não suportado" é uma categoria expansível. O Bitcoin não tem um gerente de produto central que possa definir permanentemente seu escopo aprovado.
94. Limites baseados em propósito tornam-se limites políticos. Uma vez que a validade depende de julgamentos sobre uso legítimo, os debates do protocolo se tornam disputas sobre valores e poder.
95. O alvo de hoje não limita o alvo de amanhã. Ferramentas de privacidade, custódia inovadora, liquidação de stablecoins, sistemas de tokens, aplicações corporativas ou outros usos impopulares poderiam enfrentar argumentos semelhantes. Isso não é uma previsão. É um risco de governança.
96. Toda restrição é apresentada como excepcional. Precedentes são criados precisamente por casos que seus defensores consideram únicos.
97. A coesão social é um ativo escasso. Codificar uma disputa cultural no consenso pode consumir confiança e capacidade de coordenação necessárias para ameaças mais sérias.
98. Cada parte interessada merece ser ouvida. Desenvolvedores, operadores de nós, mineradores, detentores, carteiras, exchanges, custodiantes, empresas e instituições todos carregam riscos e responsabilidades diferentes.
99. O capital em risco merece consideração sem conferir controle. Grandes detentores, mineradores, exchanges, custodiantes e corporações não possuem o consenso. Desenvolvedores ou operadores de nós agindo sozinhos também não. Um acordo duradouro requer coordenação entre todos eles.
100. A participação corporativa é legítima quando fortalece o Bitcoin. Empresas permitem que as pessoas se organizem dentro da lei com escala, responsabilidade, capital e continuidade. Elas não merecem autoridade especial, mas também não devem ser tratadas como outsiders de uma rede monetária global.
XI. Um Caminho Melhor Está Disponível
101. Os participantes podem se opor ao armazenamento de dados sem alterar o consenso. Eles podem se recusar a usar, promover, indexar, relayar ou minerar esses dados.
102. Escolhas de software mais restritivas podem permanecer voluntárias. Implementações concorrentes e políticas configuráveis são características de uma rede aberta, não defeitos.
103. Podemos melhorar a medição antes da intervenção. Publique dados reproduzíveis sobre largura de banda, armazenamento, tempo de validação, crescimento de UTXO, deslocamento de taxas e economia de nós.
104. Podemos mirar em custos de recursos mensuráveis. Uma regra restrita vinculada a um risco demonstrado de negação de serviço ou validação é mais defensável do que um pacote amplo ligado em parte a um propósito percebido.
105. Podemos melhorar o posicionamento dos dados. Melhores compromissos, armazenamento opcional, poda e arquiteturas de Camada 2 podem reduzir encargos enquanto preservam a funcionalidade.
106. Podemos melhorar a transparência do mercado de taxas. Melhores ferramentas e modelos podem mostrar quem paga, quem arca com os custos e quais usos realmente deslocam os pagamentos.
107. Podemos preservar hooks de atualização enquanto a pesquisa continua. Capacidade não utilizada não é necessariamente desperdício quando protege caminhos futuros de soft fork.
108. Podemos esperar por um alinhamento esmagador. O custo de esperar deve ser medido contra o custo de um fork desnecessário. Na ausência de evidências convincentes de emergência e amplo acordo, a moderação é o padrão mais seguro.
109. Podemos discordar sem transformar aliados em inimigos. Os apoiadores do BIP 110 estão tentando proteger o Bitcoin. A resposta respeitosa é abordar suas preocupações enquanto rejeita um remédio que cria riscos maiores.
110. A cura proposta é mais perigosa do que a condição. O BIP 110 usaria o consenso para restringir a atividade válida, limitar opções futuras, complicar a implantação e estabelecer um precedente que não pode ser apagado depois. Isso o torna uma Proposta Iatrogênica do Bitcoin.
Guardians of Neutrality (Guardiões da Neutralidade)
A força do Bitcoin não é que todos concordam com cada uso. Sua força é que o desacordo é contido por regras neutras e consenso sólido.
As taxas precificam o espaço do bloco. Os nós escolhem a política e validam o consenso. Os mineradores constroem blocos. Os detentores alocam capital. Os desenvolvedores propõem código. As empresas constroem infraestrutura e aplicativos. As mudanças no protocolo devem prevalecer apenas quando a validação, a segurança, a utilidade e o capital atingirem um alinhamento esmagador.
Isso não é uma defesa de cada inscrição, token, arquivo ou aplicativo. É uma defesa das regras neutras que permitem que o Bitcoin permaneça aberto enquanto os mercados recompensam o que é útil e abandonam o que não é.
O Bitcoin deve permanecer conservador na camada base. Para mim, isso significa rejeitar o BIP 110.
O Bitcoin não precisa de guardiões da pureza.
Ele precisa de guardiões da neutralidade.
Fontes Primárias
Esta análise é baseada principalmente no BIP 110 versão 1.0.0; nas definições de processo e status do BIP 3; no design de ativação do BIP 9; nos BIPs 141, 341 e 342; na documentação de política de data-carrier do Bitcoin Core; na documentação de poda do Bitcoin Core; e na referência de recompensa de bloco do desenvolvedor do Bitcoin. (GitHub
