Limitar datos arbitrarios es una pendiente resbaladiza hacia la censura a nivel de protocolo. La fortaleza de Bitcoin está en negarse a discriminar entre usuarios o casos de uso.
Live estimate to the BIP-110 fork block, following the same countdown logic used by jlopp.github.io/knotzi-death-march.
Bitcoin está diseñado para ser una "tubería neutral". Al definir ciertos datos como "spam", BIP-110 introduce una moral humana subjetiva en la capa base. Si hoy podemos filtrar imágenes, ¿qué se filtrará mañana?
Ref: Adam Back (Blockstream) → Página completa del argumento →A medida que el subsidio por bloque se acerca a cero, Bitcoin debe depender de las comisiones. Las inscripciones ya han pagado más de 500 millones de dólares a los mineros. BIP-110 elimina ese ingreso y vuelve a la red más vulnerable a ataques del 51 %.
Ref: Informes sobre Seguridad de Mineros → Página completa del argumento →Los filtros no detienen los datos; los empujan a la clandestinidad. BIP-110 incentiva pagos "fuera de banda", donde los usuarios pagan en privado a los mineros para incluir datos, creando un mercado centralizado y opaco para el espacio en bloques.
Página completa del argumento →"Es un intento de turba por imponer cambios para los que no existe consenso... BIP-110 sería un ataque contra la credibilidad de Bitcoin como reserva de valor neutral."
Las restricciones técnicas de la propuesta implican riesgos que van más allá de eliminar simple "spam".
Los límites en la profundidad de los árboles de script pensados para frenar las inscripciones son las mismas herramientas usadas por BitVM y contratos inteligentes avanzados. BIP-110 podría "romper" sin querer el futuro de la escalabilidad de Bitcoin.
Ref: Crítica de Jameson Lopp → Página completa de consecuencias →Cambiar retroactivamente lo que es "estándar" puede volver inutilizables transacciones prefirmadas o wallets con timelock. Los críticos lo consideran una confiscación forzada de la propiedad de los usuarios.
Ref: Análisis de The Bitcoin Manual → Página completa de consecuencias →Basadas en las notas a mineros de Jason Hughes del 15 de julio de 2026, estas objeciones se centran en lo que BIP-110 cambia para productores de bloques, descubrimiento de comisiones, coordinación y superficie política de ataque a largo plazo.
BIP-110 intenta bloquear una forma de inserción de payloads, pero los datos arbitrarios pueden migrar a otras construcciones de script y otros patrones de transacción. Eso deja a los mineros con riesgo de coordinación sin eliminar la demanda subyacente.
Ref: Jason Hughes, notas para mineros →Si el relay público y las herramientas de wallet rechazan algunas transacciones, los grandes usuarios todavía pueden rodear ese camino y negociar directamente con mineros o pools. El resultado es menos transparencia en comisiones y más ventaja para insiders.
Ref: Jason Hughes, notas para mineros →Una vez que un soft fork se usa para prohibir un uso desagradable del blockspace, los argumentos futuros dejan de ser estrictamente técnicos. Los mineros se convierten en el punto de presión de cada nueva campaña sobre lo que Bitcoin debería o no permitir.
Ref: Jason Hughes, notas para mineros →Un rollout conflictivo obliga a mineros y pools a adivinar qué cadena ganará, cómo reaccionarán los exchanges y si subirá el riesgo de reorg. BIP-110 no es solo una posición de policy: es un evento de riesgo operativo.
Ref: Jason Hughes, notas para mineros →La demanda que paga comisiones sigue siendo demanda, incluso cuando algunos usuarios no soportan la aplicación que consume blockspace. Reemplazar esa señal de mercado con preferencias sociales debilita la credibilidad de la subasta neutral de Bitcoin.
Ref: Jason Hughes, notas para mineros →Cuanto más dependa Bitcoin de filtros personalizados, flujos privados y coordinación entre cadenas conflictivas, más se desplazará la ventaja hacia grandes pools con relaciones más profundas y mejor postura legal o comunicativa.
Ref: Jason Hughes, notas para mineros →Algunas de las críticas públicas más claras publicadas en blogs, cobertura periodística y comentarios online.
En su ensayo del 23 de febrero de 2026, Jameson Lopp sostiene que BIP-110 aumenta el riesgo de división de cadena, puede congelar fondos en casos límite, limita futuras mejoras y aun así no impide los datos arbitrarios porque los usuarios pueden rodear las reglas.
Leer: A Layman's Guide to BIP-110 →La cobertura de los comentarios de Adam Back en X presenta a BIP-110 como más peligroso que el problema que intenta resolver: advierte que dañaría la credibilidad de Bitcoin y podría congelar algunos UTXO mediante restricciones a nivel de consenso.
Leer: Cobertura de la Oposición de Adam Back →The Bitcoin Manual explica que un UASF puede presionar a los mineros, pero también subraya la principal desventaja: si el apoyo económico se sobreestima, BIP-110 puede activar una cadena minoritaria, dividir la liquidez y crear fallos de coordinación en todo el ecosistema.
Leer: What Is BIP-110? →Si BIP-110 provoca una división conflictiva sin replay protection, la misma transacción puede ser válida en ambas cadenas. Eso abre la puerta a replays accidentales, confusión en depósitos, falsas ayudas de wallet y fraudes tipo double-spend contra usuarios y exchanges.
Leer: Lopp sobre split y replay risk →Lopp cita a Andreas Antonopoulos para sostener que las espirales de pureza ideológica terminan en autoparodia. En este marco, BIP-110 es menos una solución técnica y más un intento político de cancelar usos de Bitcoin que a algunas facciones no les gustan.
Leer: Lopp citando a Andreas sobre la política de pureza →Lopp también apunta al hilo público de Murch que rebate la afirmación de que BIP-110 puede imponerse con seguridad activándose con hashrate minoritario. Esa crítica golpea directamente la idea de que un despliegue conflictivo se resolvería limpiamente.
Leer: Lopp enlazando la refutación de Murch →En su articulo del 23 de septiembre de 2025, Lopp sostiene que Knots hereda un problema basico de confianza porque los binarios seguian sirviendose desde una infraestructura que el describe como comprometida. Su punto es simple: si la higiene de release es debil, se les pide a los usuarios que confien en una pipeline de software mas riesgosa.
Leer: It's Knot a Serious Project →Lopp tambien critica a Knots como un fork opaco de un solo maintainer: la historia de merges es mas dificil de auditar, los merge commits no estan firmados como suele ocurrir en Bitcoin Core y la revision upstream no se traslada limpiamente. Eso importa porque los cambios de consenso controvertidos deberian recibir mas escrutinio, no menos.
Leer: Lopp sobre el ciclo de software de Knots →Otro hilo del articulo de Lopp es que la governance de Knots no es solo tecnicamente polemica sino tambien politicamente cargada: vincula el proyecto con hostilidad hacia el mixing, las herramientas de privacidad e incluso con dano colateral para sistemas como Whirlpool y Lightning. Eso suma un riesgo de ecosistema mas amplio que el simple cambio de reglas de BIP-110.
Leer: Lopp sobre privacidad y danos de ecosistema →En su publicación en X del 15 de julio de 2026, Michael Saylor llama a BIP-110 una “Bitcoin Iatrogenic Proposal”: un tratamiento que causa daño. La objeción es que cambiar las reglas de consenso de Bitcoin para abordar datos no deseados podría ser más perjudicial que el problema que pretende resolver.
Leer: Michael Saylor en X →Saylor sostiene que existen amenazas para Bitcoin más graves que el spam y que convertir esta disputa en un cambio de consenso es el riesgo real. BIP-110 invalidaría transacciones actualmente válidas que pagan comisiones y crearía un precedente dañino.
Leer: Michael Saylor en X →En su mensaje relacionado, Saylor asigna funciones distintas a las comisiones, los nodos, los mineros y los tenedores. Los cambios de protocolo deben obtener, según él, una alineación abrumadora para que las malas ideas fracasen antes de dañar Bitcoin.
Leer: Michael Saylor en X →DathonPwn informa de un posible error de consenso en una actualización tardía a BIP-110. En el escenario descrito, los nodos actualizados desde software antiguo conservan su historial de cadena existente, mientras que nodos BIP-110 instalados desde cero rechazan ese mismo historial, con el riesgo de una división oculta de la cadena.
Leer: DathonPwn en X →El problema comunicado es grave porque una misma cadena histórica debe evaluarse de forma coherente. Si una actualización en el sitio acepta un historial que una instalación nueva rechaza, los operadores pueden ejecutar sin saberlo nodos que discrepan sobre qué cadena es válida.
Leer: DathonPwn en X →El aviso subraya un requisito básico del software de consenso: un nodo actualizado en el sitio y otro sincronizado desde cero deben alcanzar el mismo estado de consenso. Si esa propiedad falla, BIP-110 añade incertidumbre operativa justo cuando la red necesita una coordinación fiable.
Leer: DathonPwn en X →