Um argumento a favor de 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 moeda sólida, em vez de armazenamento de dados de uso 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 que haja 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 aplicativo. 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 tratado alterando o consenso?
Nem todas as razões abaixo têm o mesmo peso, e várias se reforçam mutuamente. O argumento é cumulativo.
O que o BIP 110 Propõe
Este artigo aborda o BIP 110 versão 1.0.0, o "Reduced Data Temporary Softfork" (Softfork Temporário de Dados Reduzidos), avançado para o status "Complete" em 25 de junho de 2026. De acordo com o BIP 3, "Complete" significa que os autores concluíram o 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 de testemunha e Tapleaf indefinidas, 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 protege (grandfathers) as saídas de transação 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 preventivamente 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. Ele usa um limite de sinalização de mineradores de 55%, em comparação com o limite de 95% especificado no BIP 9; elimina o tempo limite convencional e o estado FAILED; adiciona um período de sinalização obrigatória; garante o lock-in na cadeia de execução o mais tardar em uma altura especificada; e adiciona um novo estado EXPIRED 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 das 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, portanto, 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 um aplicativo futuro.
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 exigida para inclusão.
8. Estreita a liberdade econômica prospectiva na cadeia BIP 110. UTXOs pré-ativação são protegidos, 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 os inovadores provem que seu uso é válido 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 a 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 estritamente 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 o espaço de design completo. A proposta diz que preserva todos os casos de uso monetário conhecidos. A 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 os 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 alegaçã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. O crescimento do estado UTXO, a largura de banda de sincronização inicial, o armazenamento de arquivo, o ônus de retransmissão e o 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 de 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 a 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 o estado UTXO e os custos de validação. Se isso criar um risco mensurável, merece uma proposta de escopo restrito por si só, não apoio automático para seis restrições adicionais. (GitHub
23. A política OP_RETURN de 83 bytes torna-se 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 visam o armazenamento de dados restringindo classes amplas de payloads enviados e itens de testemunha de argumento de script.
25. Gastar versões de testemunha e Tapleaf indefinidas 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 branches 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 em 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 é um substituto para 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 de testemunha futuras, versões de Tapleaf futuras 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 ajuste.
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. A proteção (grandfathering) é valiosa, 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 custo.
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. Ele deve ser especificado, implementado, revisado, testado, implantado, monitorado e posteriormente retirado.
42. A proteção (grandfathering) 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. O software e os 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 EXPIRED. Isso estende a máquina de estado de implantação familiar com um novo comportamento de consenso.
47. Remove o resultado FAILED convencional. 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, lock-in, 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 branches 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 de 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 dada 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 saber 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 partes 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 diminuir as taxas de pagamento, reduzir 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. Uma demanda agregada por taxas mais baixa 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. Existem Melhores Ferramentas de Mercado e Política
61. O Bitcoin já tem uma restrição de capacidade neutra em relação ao 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 limites de validade técnica e 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 portador de dados do Bitcoin Core é configurável. (GitHub
65. A política de mineração permanece 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 em 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 relação ao 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 de forma mais direta 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 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 Layer 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. 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 suporte carteiras seguras, contratos, custódia, liquidação e inovação.
IX. O Mecanismo de Ativação É Muito Agressivo
81. O limite de 55% é um grande desvio do BIP 9. O BIP 9 especifica um limite de prontidão do minerador de 95%; o BIP 110 propõe 55%.
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 muda o significado da não participação. Durante a janela especificada, os nós de execução rejeitariam blocos que não sinalizassem o bit 4.
85. A implantação é projetada para travar (lock-in) o mais tardar em uma altura predeterminada na cadeia de execução. Isso é mais forte do que meramente observar a prontidão voluntária.
86. A ausência de um estado FAILED remove uma saída limpa. Uma proposta que não consegue atrair apoio voluntário suficiente deve ser capaz de 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 aplicarem 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. 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. Fronteiras baseadas em propósito tornam-se fronteiras políticas. Uma vez que a validade depende de julgamentos sobre o uso legítimo, os debates do protocolo tornam-se 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. Cada 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. 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 pessoas se organizem sob a lei com escala, responsabilidade, capital e continuidade. Elas não merecem autoridade especial, mas também não devem ser tratadas como estranhas a uma rede monetária global.
XI. Um Caminho Melhor Está Disponível
101. Participantes podem se opor ao armazenamento de dados sem alterar o consenso. Eles podem se recusar a usar, promover, indexar, retransmitir ou minerar tais 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 reprodutíveis sobre largura de banda, armazenamento, tempo de validação, crescimento de UTXO, deslocamento de taxas e economia dos 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 parcialmente a um propósito percebido.
105. Podemos melhorar o posicionamento dos dados. Melhores compromissos, armazenamento opcional, poda (pruning) 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 excluem pagamentos.
107. Podemos preservar ganchos de atualização (upgrade hooks) 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 se 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 para o Bitcoin.
Guardiões da Neutralidade
A força do Bitcoin não é que todos concordam sobre cada uso. Sua força é que o desacordo é contido por regras neutras e consenso duro.
Taxas precificam o espaço de bloco. Nós escolhem políticas e validam o consenso. Mineradores constroem blocos. Detentores alocam capital. Desenvolvedores propõem código. Empresas constroem infraestrutura e aplicações. Mudanças de protocolo devem prevalecer apenas quando validação, segurança, utilidade e capital alcançarem um alinhamento esmagador.
Isso não é uma defesa de cada inscrição, token, arquivo ou aplicação. É 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 baseia-se 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 transporte de dados do Bitcoin Core; na documentação de poda (pruning) do Bitcoin Core; e na referência de recompensa de bloco do desenvolvedor do Bitcoin. (GitHub
