Un caso a favor de reglas neutrales, consenso firme, mercados abiertos e innovación sin permisos
Muchos bitcoiners que respeto apoyan el BIP 110. Quieren mantener la validación accesible, proteger a los operadores de nodos de costos y contenidos no deseados, preservar pagos asequibles y mantener a Bitcoin enfocado en dinero sólido en lugar de almacenamiento de datos de propósito general. Esas son preocupaciones serias. Comparto los objetivos. Discrepo sobre el remedio. (GitHub
Este artículo critica la propuesta, no a las personas detrás de ella. Asumo buena fe. Bitcoin es más fuerte cuando podemos discrepar vigorosamente sin confundir a los aliados con los enemigos.
Tampoco es una defensa de cada inscripción, token, archivo o aplicación. Algunos pueden ser frívolos, dañinos o fraudulentos. La pregunta es más concreta: ¿debería abordarse un uso disputado de transacciones actualmente válidas que pagan tarifas mediante un cambio en el consenso?
No todas las razones que siguen tienen el mismo peso, y varias se refuerzan entre sí. El caso es acumulativo.
Lo que propone el BIP 110
Este artículo aborda el BIP 110 versión 1.0.0, el "Reduced Data Temporary Softfork", avanzado a Completo el 25 de junio de 2026. Según el BIP 3, Completo significa que los autores han concluido su trabajo planificado y recomiendan su adopción. No significa que Bitcoin haya adoptado la propuesta ni que la comunidad haya alcanzado consenso. El repositorio de BIPs establece explícitamente que la publicación no determina que una propuesta sea buena, tenga consenso comunitario o esté a punto de adoptarse. (GitHub
Durante un período activo de aproximadamente un año, el BIP 110 añadiría siete restricciones de consenso. Limitaría los nuevos scriptPubKeys a 34 bytes, con una excepción de 83 bytes para OP_RETURN; limitaría muchos payloads enviados y elementos de testigo de argumento de script a 256 bytes; prohibiría gastar versiones de witness y Tapleaf indefinidas, aunque aún permitiría crear dichos outputs; prohibiría el anexo Taproot; limitaría los bloques de control Taproot a 257 bytes; rechazaría Tapscripts que contengan opcodes OP_SUCCESSx; y rechazaría ejecuciones de OP_IF u OP_NOTIF en Tapscript. (GitHub
La propuesta hereda los outputs de transacciones no gastados creados antes de la activación. Eso es una salvaguarda importante. No afirmo que el BIP 110 confisque ampliamente bitcoins existentes. Mi objeción es más limitada: elimina prospectivamente funcionalidad de transacciones actualmente válidas, puede afectar flujos de trabajo prefirmados raros que abarquen la activación, reduce la opcionalidad técnica y establece un precedente para usar restricciones de consenso para desalentar una categoría de uso por lo demás válido. (GitHub
El BIP 110 también propone un despliegue modificado del BIP 9. Utiliza un umbral de señalización de mineros del 55 por ciento, en comparación con el umbral del 95 por ciento especificado en el BIP 9; elimina el tiempo de espera convencional y el estado FALLIDO; añade un período de señalización obligatoria; garantiza el bloqueo en la cadena que lo aplica a más tardar en una altura especificada; y añade un nuevo estado EXPIRADO después de 52,416 bloques activos. (GitHub
Como cualquier soft fork, el BIP 110 no es impuesto por una autoridad central. Los usuarios eligen qué software y reglas aplicar. El riesgo surge cuando participantes económicamente significativos aplican reglas materialmente diferentes, creando presión, incertidumbre o una división de la cadena.
Los autores proporcionan una implementación de referencia, vectores de prueba, una justificación detallada y una discusión franca de las compensaciones. Esas son fortalezas sustanciales del documento. La propuesta argumenta que la urgencia y la duración temporal justifican el umbral más bajo y las restricciones intencionalmente simples y contundentes. Respeto la preocupación y el trabajo. Discrepo con el cálculo de riesgo. (GitHub
I. Neutralidad y Primeros Principios
1. El consenso es la intervención más poderosa de Bitcoin. Un soft fork hace que algunos bloques que eran válidos según reglas anteriores sean inválidos para los nodos actualizados. Ese poder debe reservarse para fallos claros, graves y ampliamente comprendidos.
2. No es una reparación para un fallo de consenso establecido. El BIP 110 no corrige inflación, validación de firmas, doble gasto ni un error crítico conocido. Aborda una externalidad y un caso de uso controvertidos, por lo que la carga de la prueba debería ser especialmente alta.
3. Eleva un juicio controvertido a ley de protocolo. La propuesta traslada una disputa sobre el uso legítimo y las externalidades desde la política de retransmisión, la política de minería y los mercados hacia la validez del consenso.
4. Bitcoin no puede leer la intención. La red no puede saber si los bytes representan una imagen, una prueba, un contrato, metadatos, un registro de autenticación o una aplicación futura.
5. Los proxies estructurales crean riesgo colateral. Debido a que no se puede conocer la intención, la propuesta restringe formas técnicas que pueden servir tanto para propósitos no favorecidos como legítimos.
6. Un mensaje social no es justificación suficiente para un cambio de consenso. La especificación trata explícitamente la activación como una forma de comunicar que el almacenamiento de datos no es bienvenido. El consenso debe cambiarse por razones técnicas o monetarias convincentes, no principalmente para expresar desaprobación. (GitHub
7. La desaprobación no es invalidez. Una transacción puede ser trivial, especulativa, ofensiva o derrochadora y aun así seguir las reglas y pagar la tarifa requerida para su inclusión.
8. Reduce la libertad económica prospectiva en la cadena del BIP 110. Los UTXOs anteriores a la activación están heredados, pero los usuarios que creen UTXOs durante el período activo tendrían menos formas válidas de estructurarlos y gastarlos que bajo el consenso actual.
9. Los sistemas sin permisos deben tolerar la experimentación no aprobada. Exigir que los innovadores demuestren que su uso es valioso antes de construir invierte el significado de la innovación sin permisos.
10. Pone la conservadurismo del protocolo patas arriba. El conservadurismo en la capa base debería significar renuencia a alterar el consenso, no entusiasmo por alterarlo a favor de una filosofía de uso conservadora.
II. La Carga de la Prueba No se Ha Cumplido
11. "Spam" no es un primitivo de consenso. No hay un opcode que pueda distinguir el spam de la utilidad. Esas etiquetas surgen del juicio humano.
12. "Monetario" y "no monetario" no son claramente separables. Un canal de pago, una prueba de reservas, una política de custodia, un contrato inteligente o un compromiso de liquidación son tanto actividad financiera como datos.
13. Los casos de uso conocidos no son el espacio de diseño completo. La propuesta dice que preserva todos los casos de uso monetario conocidos. La innovación se define por lo que aún no se conoce.
14. El propio BIP no cuantifica la carga del nodo que eliminaría. Describe costos pero no estima el ancho de banda, almacenamiento, carga de validación, umbrales de hardware o número de operadores de nodos que probablemente se ganarían o perderían.
15. No cuantifica el beneficio de descentralización. La afirmación de que el BIP 110 mejoraría la descentralización no va acompañada de un modelo o objetivo medible.
16. No cuantifica el alivio de pagos. No estima cuánto disminuirían las tarifas de transacción, por cuánto tiempo ni cuántos usuarios de pagos se beneficiarían.
17. Combina costos distintos en un solo diagnóstico. El crecimiento del estado UTXO, el ancho de banda de sincronización inicial, el almacenamiento de archivo, la carga de retransmisión y el tiempo de validación tienen causas diferentes y pueden requerir remedios diferentes.
18. La urgencia se afirma más que se define operativamente. La propuesta califica la situación como urgente y una crisis, pero no proporciona un umbral objetivo en el cual la intervención del consenso sea necesaria.
19. Un límite histórico de política de retransmisión no es prueba de un límite de consenso óptimo. Un valor predeterminado de 83 bytes puede ser una política útil sin convertirse en una regla de validez de bloque atemporal.
20. La línea de 256 bytes es heurística. La justificación la relaciona parcialmente con el tamaño de imagen comprimida y grandes enteros criptográficos, pero no establece 256 bytes como un límite óptimo entre seguridad e innovación. (GitHub
III. El Alcance Técnico es Demasiado Amplio
21. Se agrupan siete cambios de consenso separados. Los participantes no pueden apoyar una restricción y rechazar otra. Deben aceptar o rechazar el paquete.
22. La preocupación técnica más fuerte se agrupa con restricciones no relacionadas. Los scriptPubKeys grandes pueden aumentar el costo del estado UTXO y la validación. Si eso crea un peligro medible, merece una propuesta de alcance limitado por sí sola, no apoyo automático a seis restricciones adicionales. (GitHub
23. La política OP_RETURN de 83 bytes se convierte en consenso. Eso convierte una preferencia configurable de retransmisión y minería en una regla de validez de bloque.
24. Los límites de 256 bytes restringen primitivas generales. Apuntan al almacenamiento de datos restringiendo clases amplias de payloads enviados y elementos de testigo de argumento de script.
25. Gastar versiones de witness y Tapleaf indefinidas quedaría deshabilitado. Esos espacios no se utilizan hoy en parte porque están reservados para futuras actualizaciones.
26. El anexo Taproot quedaría deshabilitado. El BIP 341 reserva el anexo para extensiones futuras. Incluso si los usuarios no deberían emplearlo antes de que se defina su significado, cerrar una ruta de actualización deliberada debería requerir una justificación excepcional. (GitHub
27. La profundidad del Taptree se reduciría. Un límite de bloque de control de 257 bytes restringe las rutas de script reveladas a siete niveles y puede limitar árboles de script complejos.
28. OP_SUCCESSx quedaría deshabilitado incluso en ramas no ejecutadas. El BIP 342 creó estos opcodes como ganchos de actualización limpios para futuros soft forks. (GitHub
29. Se prohibirían OP_IF y OP_NOTIF ejecutados en Tapscript. Los autores los consideran redundantes y comúnmente abusados, pero también reconocen usos experimentales y posibles eficiencias de Miniscript.
30. La propuesta acepta abiertamente la contundencia a cambio de velocidad. Su justificación dice que un enfoque mejor equilibrado requeriría más desarrollo y revisión, por lo que elige restricciones más simples destinadas a un despliegue más rápido. La urgencia no es un sustituto de la precisión en el código de consenso. (GitHub
IV. Sacrifica la Compatibilidad y la Opcionalidad Futura
31. Cierra varias rutas de actualización a la vez. Los anexos, las versiones futuras de witness, las versiones futuras de Tapleaf y OP_SUCCESSx son parte del espacio de diseño reservado de Bitcoin. (GitHub
32. Reservado no significa inútil. Significa que los diseñadores anteriores preservaron deliberadamente el valor de la opción para necesidades que aún no habían surgido.
33. Un cierre de un año aún puede interrumpir los plazos de desarrollo. Los autores esperan que los futuros soft forks requieran más de un año de coordinación, pero eso es una estimación, no una garantía.
34. Puede complicar diseños de estilo BitVM. La especificación reconoce que el límite del bloque de control podría impedir la contratación avanzada fuera de la cadena.
35. Puede afectar Tapleaves generados por Miniscript. La propuesta reconoce que algunos resultados del compilador pueden contener OP_IF y necesitarían ajustes.
36. Requiere cambios en las herramientas de billetera afectadas. La sección de compatibilidad hacia atrás establece que el compilador Miniscript necesitaría modificaciones mientras las reglas estén activas.
37. Crea un riesgo de acceso a fondos limitado pero admitido. El BIP identifica francamente escenarios raros de Taproot prefirmados en los que los UTXOs posteriores a la activación podrían congelarse o gastarse inesperadamente.
38. La herencia es valiosa pero no es un aislamiento completo. Los UTXOs anteriores a la activación están protegidos, pero los flujos de trabajo que crean o gastan outputs afectados durante el despliegue aún pueden encontrar nuevas restricciones.
39. Se recomienda a los usuarios migrar fondos potencialmente afectados. Una propuesta que requiere que incluso una clase limitada de usuarios migre no es un filtro sin costo.
40. "No hay caso de uso conocido" no es una prueba de seguridad. Los sistemas privados, los contratos no publicados, las billeteras experimentales y los protocolos futuros no son completamente observables. (GitHub
V. Las Reglas de Consenso Temporales Aún Crean Complejidad Real
41. El código de consenso temporal sigue siendo código de consenso. Debe ser especificado, implementado, revisado, probado, desplegado, monitoreado y luego retirado.
42. La herencia hace que la validez dependa del historial. La misma construcción de gasto puede tratarse de manera diferente según cuándo se creó el UTXO.
43. Las reglas que dependen del historial aumentan la complejidad de la implementación. Cada implementación debe identificar la altura de creación del UTXO relevante y aplicar las exenciones de manera idéntica.
44. La activación crea un límite crítico. El software y los actores económicos deben acordar cuándo comienzan las nuevas restricciones.
45. La expiración crea otro. También deben acordar cuándo terminan las restricciones y el comportamiento previamente restringido vuelve a ser válido.
46. El BIP 110 añade un nuevo estado EXPIRADO. Eso extiende la máquina de estados de despliegue familiar con un nuevo comportamiento de consenso.
47. Elimina el resultado convencional de FALLIDO. El despliegue propuesto no puede simplemente agotar el tiempo de la manera habitual del BIP 9.
48. Crea varias ventanas de coordinación. La señalización voluntaria, la señalización obligatoria, el bloqueo, la activación y la expiración introducen cada una oportunidades de divergencia. (GitHub
49. Las reglas temporales pueden dejar artefactos permanentes. El código de la billetera, los procedimientos operativos, los contratos y los controles de riesgo institucionales pueden necesitar cambios que sobrevivan al despliegue.
50. Más ramas de consenso significan más superficie de errores. Los vectores de prueba reducen el riesgo conocido, pero no pueden enumerar cada interacción privada o futura.
VI. Los Efectos Económicos y de Seguridad Son Inciertos
51. La externalidad del nodo es real pero heterogénea. Cada nodo de validación completa debe descargar y verificar bloques, mientras que los nodos podados pueden descartar datos de bloques originales antiguos y limitar el almacenamiento histórico. Los costos relevantes deben medirse por separado. (Bitcoin Core
52. El problema del destinatario de tarifas no es exclusivo de las transacciones de datos. Los mineros cobran tarifas mientras que los validadores soportan algunos costos por cada transacción. La magnitud puede diferir, pero la estructura básica es universal.
53. Los costos técnicos deben medirse directamente. Para una cantidad determinada de datos y trabajo de validación, los costos de recursos surgen de los bytes, el estado, el cómputo y el ancho de banda, no de si los observadores aprueban el propósito de la transacción.
54. El BIP 110 no puede eliminar la incrustación de datos. La especificación reconoce que los usuarios pueden dividir los datos en piezas más pequeñas o disfrazarlos dentro de estructuras permitidas. (GitHub
55. La evasión puede hacer que las transacciones sean menos eficientes. Las codificaciones fragmentadas u ofuscadas pueden consumir más estructura y complicar el análisis sin eliminar la demanda subyacente.
56. El efecto en las tarifas es ambiguo. Suprimir un uso puede reducir las tarifas de pago, disminuir los ingresos totales por tarifas, desplazar la demanda hacia otras codificaciones o producir alguna combinación de los tres.
57. Los ingresos de los mineros importan más a medida que disminuye el subsidio. Las tarifas de transacción son un componente de la recompensa del bloque, mientras que el subsidio del bloque se reduce a la mitad cada 210,000 bloques. (Bitcoin Developer Docs
58. Una menor demanda agregada de tarifas puede debilitar la seguridad en el margen. En la medida en que el BIP 110 reduce la demanda total de tarifas en lugar de simplemente reasignarla, unos ingresos más bajos para los mineros pueden reducir el incentivo para comprometer poder de hash, en igualdad de condiciones.
59. Una demanda diversa puede hacer que el mercado de tarifas sea más resistente. Los pagos, los canales, los sistemas de custodia, las aplicaciones financieras y otros usos no necesitan alcanzar su punto máximo al mismo tiempo.
60. La especificación no modela la compensación de seguridad. Argumenta a favor de pagos más baratos y costos de nodo más bajos sin estimar los posibles efectos en los ingresos de los mineros, la inversión en hash o la profundidad del mercado de tarifas a largo plazo.
VII. Existen Mejores Herramientas de Mercado y Políticas
61. Bitcoin ya tiene una restricción de capacidad neutral en cuanto al contenido. El peso del bloque impone un límite común a la capacidad de transacción de cada bloque. (GitHub
62. Las tarifas ya racionan el espacio de bloque escaso. Los usuarios expresan urgencia ofertando, y los mineros seleccionan transacciones válidas bajo sus propias políticas.
63. El límite de bloque y el mercado de tarifas no piden a los usuarios que declaren su propósito. Aplican validez técnica y límites de recursos en lugar de una prueba semántica de si una transacción es suficientemente monetaria.
64. La política de retransmisión sigue siendo una herramienta menos coercitiva. Las implementaciones y los operadores de nodos pueden elegir qué transacciones no confirmadas retransmitir sin redefinir los bloques válidos. La política de portador de datos de Bitcoin Core es configurable. (GitHub
65. La política de minería sigue siendo voluntaria. Los mineros pueden excluir clases de transacciones de sus propias plantillas de bloque sin obligar a cada nodo de validación a rechazar bloques que las contengan.
66. La política es imperfecta, pero la imperfección no es un fracaso. El envío directo a los mineros puede eludir los filtros de retransmisión. Esa limitación merece análisis, no un salto automático a la prohibición de consenso.
67. Ninguna transacción tiene derecho a ser incluida. Un minero puede rechazar una transacción bajo su propia política, pero hacer que una transacción previamente válida sea inválida a través de un fork es un acto mucho más consecuente.
68. El precio de los recursos puede mejorarse sin clasificar el propósito. Si ciertas estructuras imponen costos desproporcionados, Bitcoin puede estudiar límites neutrales en cuanto al contenido o precios vinculados al uso medible de recursos.
69. La poda y los diseños de datos opcionales merecen investigación continua. Puede que no resuelvan todas las preocupaciones, pero abordan las cargas de almacenamiento de manera más directa que una regla destinada en parte a señalar que un uso no es bienvenido.
70. El propio BIP concede que la política es generalmente el lugar correcto para combatir el spam. Su incapacidad para garantizar un filtrado perfecto no prueba por sí misma que deba usarse el consenso. (GitHub
VIII. Desalienta la Innovación y la Adopción
71. Crea un efecto desalentador. Los desarrolladores pueden evitar Bitcoin si las construcciones actualmente válidas pueden suspenderse mediante consenso para suprimir un uso relacionado.
72. Privilegia los casos de uso existentes. "Todos los casos de uso monetario conocidos" protege el presente, no el futuro.
73. Destruye el valor de la opción antes de que se pueda descubrir. El mejor uso futuro de un gancho de actualización puede no tener aún nombre.
74. Los fundamentos estables importan para los contratos de larga duración. Las billeteras, los sistemas de custodia, los canales de pago y los protocolos financieros necesitan confianza en que las estructuras de transacción válidas seguirán estando disponibles.
75. Reduce el espacio de diseño de scripts. Eso puede hacer que algunas construcciones sean más grandes, más caras, menos elegantes o temporalmente imposibles.
76. Puede retrasar la investigación de contratación avanzada. El BIP acepta explícitamente que el trabajo de estilo BitVM puede necesitar esperar o proceder en testnets y sidechains. (GitHub
77. Aleja la experimentación de Bitcoin mediante consenso. Las testnets y las sidechains son útiles, pero los constructores no deberían ser desplazados de la capa base sin un caso de seguridad convincente.
78. Los futuros sistemas de Capa 2 pueden depender de los ganchos no utilizados de hoy. La opcionalidad de la capa base puede soportar la escala sin requerir actividad frecuente en la capa base.
79. Las aplicaciones pueden fortalecer el dinero. Mejores billeteras, custodia, liquidación, crédito, valores y sistemas de prueba pueden aumentar la utilidad, liquidez y demanda de Bitcoin.
80. Bitcoin no necesita elegir entre dinero y tecnología. Su fortaleza monetaria puede ser reforzada por una red abierta que soporte billeteras seguras, contratos, custodia, liquidación e innovación.
IX. El Mecanismo de Activación es Demasiado Agresivo
81. El umbral del 55 por ciento es un gran cambio respecto al BIP 9. El BIP 9 especifica un umbral de preparación del minero del 95 por ciento; el BIP 110 propone el 55 por ciento.
82. Una restricción controvertida debería exigir mayor confianza, no menos. La duración temporal no hace que un fallo de coordinación sea inofensivo.
83. La señalización del minero no es un referéndum sobre todos los usuarios de Bitcoin. El poder de hash asegura y ordena las transacciones, pero los tenedores, intercambios, billeteras, comerciantes, custodios y empresas determinan qué reglas y activo aceptan económicamente.
84. La señalización obligatoria cambia el significado de la no participación. Durante la ventana especificada, los nodos que aplican las reglas rechazarían los bloques que no señalen el bit 4.
85. El despliegue está diseñado para bloquearse a más tardar en una altura predeterminada en la cadena que lo aplica. Eso es más fuerte que simplemente observar la preparación voluntaria.
86. La ausencia de un estado FALLIDO elimina una salida limpia. Una propuesta que no puede atraer suficiente apoyo voluntario debería poder expirar sin coordinación forzada. (GitHub
87. La maquinaria de activación no puede fabricar consenso. Puede coordinar estados de software, pero no puede crear acuerdo social y económico.
88. La aplicación divergente puede dividir la red. Si los participantes económicamente significativos aplican reglas de validez incompatibles, el resultado puede ser una división de la cadena o una incertidumbre prolongada.
89. Una división temporal no sería trivial. La liquidez, la custodia, la liquidación, la contabilidad y la confianza del usuario podrían verse afectadas.
90. El consenso firme es el sistema inmunológico de Bitcoin. Reducir el listón para una restricción de caso de uso disputada puede crear un riesgo más grave que el problema de almacenamiento de datos al que apunta.
X. El Precedente es Más Peligroso que el Objetivo
91. Las reglas expiran, pero el precedente no. Futuras campañas pueden citar el BIP 110 como evidencia de que el consenso puede usarse para suprimir una actividad válida no favorecida.
92. La misma lógica puede reutilizarse. Una facción puede etiquetar otro uso como no monetario, dañino, legalmente riesgoso o no respaldado y buscar su exclusión.
93. "Uso no respaldado" es una categoría ampliable. Bitcoin no tiene un gerente de producto central que pueda definir permanentemente su alcance aprobado.
94. Los límites basados en el propósito se convierten en límites políticos. Una vez que la validez depende de juicios sobre el uso legítimo, los debates del protocolo se convierten en contiendas sobre valores y poder.
95. El objetivo de hoy no limita el objetivo de mañana. Las herramientas de privacidad, la custodia novedosa, la liquidación de stablecoins, los sistemas de tokens, las aplicaciones corporativas u otros usos impopulares podrían enfrentar argumentos similares. Esto no es una predicción. Es un riesgo de gobernanza.
96. Cada restricción se presenta como excepcional. Los precedentes se crean precisamente por casos que sus defensores consideran únicos.
97. La cohesión social es un activo escaso. Codificar una disputa cultural en el consenso puede consumir la confianza y la capacidad de coordinación necesarias para amenazas más graves.
98. Cada parte interesada merece ser escuchada. Los desarrolladores, operadores de nodos, mineros, tenedores, billeteras, intercambios, custodios, empresas e instituciones todos soportan diferentes riesgos y responsabilidades.
99. El capital en riesgo merece consideración sin otorgar control. Los grandes tenedores, mineros, exchanges, custodios y corporaciones no poseen el consenso. Tampoco los desarrolladores u operadores de nodos que actúan solos. Un acuerdo duradero requiere coordinación entre todos ellos.
100. La participación corporativa es legítima cuando fortalece Bitcoin. Las empresas permiten que las personas se organicen dentro del marco legal con escala, responsabilidad, capital y continuidad. No merecen autoridad especial, pero tampoco deben ser tratadas como ajenas a una red monetaria global.
XI. Un Camino Mejor Está Disponible
101. Los participantes pueden oponerse al almacenamiento de datos sin cambiar el consenso. Pueden negarse a usarlo, promoverlo, indexarlo, retransmitirlo o minarlo.
102. Las opciones de software más estrictas pueden seguir siendo voluntarias. Las implementaciones competidoras y las políticas configurables son características de una red abierta, no defectos.
103. Podemos mejorar la medición antes de la intervención. Publicar datos reproducibles sobre ancho de banda, almacenamiento, tiempo de validación, crecimiento de UTXO, desplazamiento de tarifas y economía de nodos.
104. Podemos apuntar a costos de recursos medibles. Una regla estrecha vinculada a un riesgo demostrado de denegación de servicio o validación es más defendible que un paquete amplio vinculado en parte a un propósito percibido.
105. Podemos mejorar la ubicación de datos. Mejores compromisos, almacenamiento opcional, poda y arquitecturas de Capa 2 pueden reducir las cargas mientras preservan la funcionalidad.
106. Podemos mejorar la transparencia del mercado de tarifas. Mejores herramientas y modelos pueden mostrar quién paga, quién asume los costos y qué usos realmente desplazan a los pagos.
107. Podemos preservar los ganchos de actualización mientras la investigación continúa. La capacidad no utilizada no es necesariamente desperdicio cuando protege futuras rutas de bifurcación suave.
108. Podemos esperar una alineación abrumadora. El costo de esperar debe medirse frente al costo de una bifurcación innecesaria. Ante la ausencia de evidencia contundente de emergencia y amplio acuerdo, la moderación es la opción predeterminada más segura.
109. Podemos discrepar sin convertir aliados en enemigos. Los partidarios de BIP 110 están tratando de proteger Bitcoin. La respuesta respetuosa es abordar sus preocupaciones mientras se rechaza un remedio que crea mayores riesgos.
110. La cura propuesta es más peligrosa que la enfermedad. BIP 110 usaría el consenso para restringir la actividad válida, limitar opciones futuras, complicar el despliegue y establecer un precedente que no puede borrar después. Eso lo convierte en una Propuesta Iatrogénica para Bitcoin.
Guardianes de la Neutralidad
La fortaleza de Bitcoin no es que todos estén de acuerdo en cada uso. Su fortaleza es que el desacuerdo está contenido por reglas neutrales y consenso duro.
Las tarifas valoran el espacio de bloque. Los nodos eligen políticas y validan el consenso. Los mineros construyen bloques. Los tenedores asignan capital. Los desarrolladores proponen código. Las empresas construyen infraestructura y aplicaciones. Los cambios de protocolo deberían prevalecer solo cuando la validación, la seguridad, la utilidad y el capital alcanzan una alineación abrumadora.
Esto no es una defensa de cada inscripción, token, archivo o aplicación. Es una defensa de las reglas neutrales que permiten que Bitcoin siga siendo abierto mientras los mercados recompensan lo que es útil y abandonan lo que no.
Bitcoin debería permanecer conservador en la capa base. Para mí, eso significa rechazar BIP 110.
Bitcoin no necesita guardianes de la pureza.
Necesita guardianes de la neutralidad.
Fuentes Primarias
Este análisis se basa principalmente en BIP 110 versión 1.0.0; las definiciones de proceso y estado de BIP 3; el diseño de activación de BIP 9; los BIP 141, 341 y 342; la documentación de política de portador de datos de Bitcoin Core; la documentación de poda de Bitcoin Core; y la referencia de recompensa de bloque del desarrollador de Bitcoin. (GitHub
