Un argumento a favor de reglas neutrales, consenso sólido, mercados abiertos e innovación sin permisos
Muchos bitcoiners que respeto apoyan 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 Bitcoin enfocado en dinero sólido en lugar de almacenamiento de datos de uso general. Esas son preocupaciones serias. Comparto los objetivos. Discrepo en 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 aliados con 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 acotada: ¿debería abordarse un uso disputado de transacciones actualmente válidas que pagan tarifas cambiando 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 BIP 110
Este artículo aborda BIP 110 versión 1.0.0, el "Soft Fork Temporal de Datos Reducidos", avanzado a Completado el 25 de junio de 2026. Según BIP 3, Completado 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 implica que una propuesta sea buena, tenga consenso comunitario o esté a punto de ser adoptada. (GitHub
Durante un período activo de aproximadamente un año, BIP 110 agregarí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 testigo de argumentos de script a 256 bytes; prohibiría gastar versiones testigo y Tapleaf no definidas, 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 otorga derechos adquiridos a los outputs de transacciones no gastados creados antes de la activación. Eso es una salvaguarda importante. No afirmo que BIP 110 confisque ampliamente bitcoin existente. Mi objeción es más específica: elimina prospectivamente funcionalidad de transacciones actualmente válidas, puede afectar flujos de trabajo raros pre-firmados que abarcan la activación, reduce la opcionalidad técnica y establece un precedente para usar restricciones de consenso con el fin de desalentar una categoría de uso que de otro modo sería válido. (GitHub
BIP 110 también propone un despliegue modificado de BIP 9. Utiliza un umbral de señalización minera del 55%, en comparación con el umbral del 95% especificado en BIP 9; elimina el tiempo de espera convencional y el estado FALLIDO; agrega un período de señalización obligatoria; garantiza el bloqueo en la cadena que aplica la norma a más tardar en una altura específica; y agrega un nuevo estado EXPIRADO después de 52,416 bloques activos. (GitHub
Como cualquier soft fork, 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 en el cálculo del riesgo. (GitHub
I. Neutralidad y principios fundamentales
1. El consenso es la intervención más poderosa de Bitcoin. Un soft fork invalida para los nodos actualizados algunos bloques que eran válidos bajo reglas anteriores. Ese poder debe reservarse para fallos claros, graves y ampliamente comprendidos.
2. No es una reparación para un fallo de consenso establecido. 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 minera 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 desfavorecidos como legítimos.
6. Un mensaje social no es motivo 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 modificarse 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 BIP 110. Los UTXOs previos a la activación tienen derechos adquiridos, 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 existente.
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 al revés el conservadurismo del protocolo. El conservadurismo en la capa base debería significar reticencia a alterar el consenso, no entusiasmo por alterarlo en favor de una filosofía de uso conservadora.
II. La carga de la prueba no se ha cumplido
11. "Spam" no es un primitivo del consenso. No existe 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 monetarios 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 BIP 110 mejoraría la descentralización no se acompaña de un modelo medible o un objetivo.
16. No cuantifica el alivio de pagos. No estima cuánto caerí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 de urgente y de crisis, pero no proporciona un umbral objetivo en el que la intervención del consenso se vuelve 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 intemporal.
20. El límite de 256 bytes es heurístico. La justificación lo relaciona en parte con el tamaño de imagen comprimida y los enteros criptográficos grandes, 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 riesgo medible, merece una propuesta de alcance limitado por sí sola, no un apoyo automático para seis restricciones adicionales. (GitHub
23. La política de 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 testigo de argumentos de script.
25. Se deshabilitaría el gasto de versiones testigo y Tapleaf no definidas. Esos espacios no se utilizan hoy en parte porque están reservados para futuras actualizaciones.
26. Se deshabilitaría el anexo Taproot. BIP 341 reserva el anexo para futuras extensiones. 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. Se reduciría la profundidad de Taptree. 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 se deshabilitaría incluso en ramas no ejecutadas. 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 más 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 testigo futuras, las versiones Tapleaf futuras 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 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 fuera de la cadena avanzada.
35. Puede afectar las Tapleaves generadas por Miniscript. La propuesta reconoce que algunas salidas 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 modificación mientras las reglas estén activas.
37. Crea un riesgo de acceso a fondos estrecho pero admitido. El BIP identifica honestamente escenarios raros de Taproot pre-firmados en los que los UTXOs posteriores a la activación podrían congelarse o gastarse inesperadamente.
38. Los derechos adquiridos son valiosos pero no un aislamiento completo. Los UTXOs previos a la activación están protegidos, sin embargo, los flujos de trabajo que crean o gastan outputs afectados durante el despliegue aún pueden encontrar nuevas restricciones.
39. Se aconseja a los usuarios migrar los fondos potencialmente afectados. Una propuesta que requiere que incluso una clase limitada de usuarios migre no es un filtro sin costo.
40. "Ningún 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. Los derechos adquiridos hacen 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 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. BIP 110 agrega un nuevo estado EXPIRADO. Eso extiende la máquina de estados de despliegue familiar con un nuevo comportamiento de consenso.
47. Elimina el resultado FALLIDO convencional. El despliegue propuesto no puede simplemente agotar el tiempo de espera de la manera ordinaria de 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 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 sin procesar antiguos y limitar el almacenamiento histórico. Los costos relevantes deben medirse por separado. (Bitcoin Core
52. El problema del destinatario de la tarifa 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 bytes, estado, cómputo y ancho de banda, no de si los observadores aprueban el propósito de la transacción.
54. BIP 110 no puede eliminar la incrustación de datos. La especificación reconoce que los usuarios pueden dividir los datos en partes 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 las 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. (Documentación para desarrolladores de Bitcoin
58. Una menor demanda agregada de tarifas puede debilitar la seguridad en el margen. En la medida en que BIP 110 reduzca la demanda total de tarifas en lugar de simplemente reasignarla, unos ingresos mineros más bajos pueden reducir el incentivo para comprometer poder hash, en igualdad de condiciones.
59. La 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 sobre 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 límites técnicos de validez y 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 minera sigue siendo voluntaria. Los mineros pueden excluir clases de transacciones de sus propias plantillas de bloque sin obligar a cada nodo validador a rechazar los bloques que las contienen.
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 un análisis, no un salto automático a la prohibición por consenso.
67. Ninguna transacción tiene derecho a la inclusión. Un minero puede rechazar una transacción bajo su propia política, pero hacer que una transacción previamente válida sea inválida en 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 utilizarse el consenso. (GitHub
VIII. Desalienta la innovación y la adopción
71. Crea un efecto disuasorio. Los desarrolladores pueden evitar Bitcoin si las construcciones actualmente válidas pueden suspenderse mediante el consenso para suprimir un uso relacionado.
72. Privilegia los casos de uso establecidos. "Todos los casos de uso monetarios conocidos" protege el presente, no el futuro.
73. Destruye el valor de opción antes de que pueda descubrirse. El mejor uso futuro de un gancho de actualización puede que aún no tenga nombre.
74. Los fundamentos estables son importantes 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 script. Eso puede hacer que algunas construcciones sean más grandes, más caras, menos elegantes o temporalmente imposibles.
76. Puede retrasar la investigación avanzada de contratación. 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 el 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 escala sin requerir actividad frecuente en la capa base.
79. Las aplicaciones pueden fortalecer el dinero. Mejores billeteras, sistemas de 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% es un cambio importante respecto a BIP 9. BIP 9 especifica un umbral de preparación minera del 95%; BIP 110 propone el 55%.
82. Una restricción controvertida debería exigir mayor confianza, no menor. La duración temporal no hace que el fracaso de la coordinación sea inofensivo.
83. La señalización minera no es un referéndum sobre todos los usuarios de Bitcoin. El poder 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 la norma 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 aplica la norma. 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 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 de los usuarios podrían verse afectadas.
90. El consenso duro 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 se dirige.
X. El precedente es más peligroso que el objetivo
91. Las reglas expiran, pero el precedente no. Las campañas futuras pueden citar BIP 110 como evidencia de que el consenso puede usarse para suprimir una actividad válida desfavorecida.
92. La misma lógica puede reutilizarse. Una facción puede etiquetar otro uso como no monetario, dañino, legalmente arriesgado o no compatible, y buscar su exclusión.
93. "Uso no compatible" es una categoría expandible. 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 asumen diferentes riesgos y responsabilidades.
99. El capital en riesgo merece consideración sin otorgar control. Los grandes tenedores, mineros, exchanges, custodios y corporaciones no son dueños del consenso. Tampoco lo son los desarrolladores o los operadores de nodos actuando por sí solos. Un acuerdo duradero requiere coordinación entre todos ellos.
100. La participación corporativa es legítima cuando fortalece a Bitcoin. Las empresas permiten que las personas se organicen bajo la ley con escala, responsabilidad, capital y continuidad. No merecen una autoridad especial, pero no deberían ser tratadas como ajenas a una red monetaria global.
XI. Existe un Camino Mejor
101. Los participantes pueden oponerse al almacenamiento de datos sin cambiar el consenso. Pueden negarse a usar, promover, indexar, retransmitir o minar dichos datos.
102. Las opciones de software más estrictas pueden seguir siendo voluntarias. Las implementaciones en competencia y las políticas configurables son características de una red abierta, no defectos.
103. Podemos mejorar la medición antes de intervenir. 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 los datos. Mejores compromisos, almacenamiento opcional, poda y arquitecturas de Capa 2 pueden reducir las cargas mientras se preserva la funcionalidad.
106. Podemos mejorar la transparencia del mercado de tarifas. Mejores herramientas y modelos pueden mostrar quién paga, quién soporta 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 un desperdicio cuando protege futuras rutas de soft fork.
108. Podemos esperar un alineamiento abrumador. El costo de esperar debe medirse frente al costo de un fork innecesario. En ausencia de evidencia convincente de emergencia y un amplio acuerdo, la moderación es el valor predeterminado más seguro.
109. Podemos discrepar sin convertir a los aliados en enemigos. Los partidarios de BIP 110 están tratando de proteger a 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 condición. BIP 110 usaría el consenso para restringir la actividad válida, limitar opciones futuras, complicar el despliegue y establecer un precedente que no se puede borrar después. Eso lo convierte en una Propuesta Iatrogénica de 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 se contiene mediante reglas neutrales y consenso duro.
Las tarifas asignan el espacio de los bloques. Los nodos eligen la política 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 un alineamiento abrumador.
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 permanezca 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 la versión 1.0.0 de BIP 110; 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 de los desarrolladores de Bitcoin. (GitHub
