El 10 de agosto de 2026 el proyecto Bitcoin Knots publicó un anuncio que empieza así: "La red Bitcoin está bajo ataque y la producción de bloques se ha desacelerado de forma significativa". Y recomienda a los usuarios "no bajar de versión ni cambiar a software que debilite las protecciones de consenso de Bitcoin" (feed de anuncios de bitcoinknots.org).
El 21 de agosto de 2026 a las 09:39 UTC, la cadena que están construyendo los grandes pools de minería estaba en la altura 963.417, con ocho bloques producidos en los cuarenta minutos anteriores, atribuidos a SpiderPool, Foundry USA, MARA Pool y otros (mempool.space).
Las dos afirmaciones se pueden verificar y ninguna es mentira. Describen cadenas distintas.
Desde el 8 de agosto de 2026, un nodo que aplica BIP-110 y un nodo que no lo aplica dejaron de
coincidir en qué bloques existen: el propio sitio del proyecto BIP-110 da el hash de su bloque
961.632 terminado en 7c78dbc16
(bitcoinknots.org/learn/2026-rdts), mientras que el
bloque 961.632 de la cadena que extienden esos pools es
00000000000000000000d1e01392faa65ceeaed307f0a3159144b84146ff24ba
(mempool.space).
Así se ve la gobernanza de Bitcoin desde adentro: no una decisión, sino un conjunto de partes separadas, cada una con una palanca, ninguna de las cuales es el todo. Vale la pena precisar cuál es cuál, porque casi toda frase escrita con seguridad sobre este tema se equivoca al menos en una de ellas.
Qué deciden los nodos
Un nodo decide qué acepta como válido, para sí mismo, y nada más. Eso es todo, y es más de lo que parece. Los colaboradores de Bitcoin Core dejaron su posición por escrito en una declaración firmada el 6 de junio de 2025: "Bitcoin es una red definida por sus usuarios, que tienen libertad absoluta para elegir qué software usan (con validación completa o no) y para aplicar las políticas que deseen. Los colaboradores de Bitcoin Core no están en posición de imponer cuáles son". La misma declaración menciona su "práctica de larga data de evitar la actualización automática en el software", de modo que "ninguna entidad puede enviar cambios de forma unilateral a los usuarios de Bitcoin Core" (bitcoincore.org, 6 de junio de 2025).
El conteo de nodos es lo más parecido a una medición de esa elección, y es una medición pobre.
Las cadenas de user agent son autodeclaradas, los rastreadores solo ven nodos que aceptan
conexiones entrantes, y un nodo detrás de Tor o de un firewall es invisible. Dicho eso: un
rastreo de Bitnodes fechado a las 09:26 UTC del 21 de agosto de 2026 registró 27.225 nodos
alcanzables, de los cuales 5.075, el 18,6 por ciento, anunciaban un user agent de Bitcoin Knots
y 21.548 anunciaban uno de tipo Satoshi
(API de bitnodes.io, contado sobre la instantánea de
ese momento). Para la dirección del cambio y no un punto en el tiempo, el blog de investigación
de Bitfinex informó el 5 de septiembre de 2025 que Knots estaba en "4.240 de 23.842 nodos
alcanzables, alrededor del 17,78 por ciento", frente a "solo 69 nodos Knots en enero de 2024"
(Bitfinex, 5 de septiembre de 2025).
Sea lo que sea, es mucha gente tomando una decisión explícita sobre un software que antes daba
por dado.
Qué deciden los mineros
Los mineros deciden qué cadena válida extender y qué transacciones entran en sus bloques. Eso es poder real, es exclusivamente suyo y ningún nodo puede anularlo. Lo que no es, es autoridad sobre las reglas.
BIP-110 es la demostración más limpia disponible, porque intentó convertir lo primero en lo segundo y toda la maquinaria quedó registrada. La propuesta, "Reduced Data Temporary Softfork", de Dathon Ohm, usaba señalización obligatoria: a partir del bloque 961.632, un nodo que la ejecutara rechazaría cualquier bloque que no marcara el bit de versión 4, y el umbral de activación era de 1.109 bloques de cada 2.016. En el período de reajuste que terminó en el bloque 961.631, en la cadena que construían los pools, 51 de esos 2.016 bloques marcaron el bit 4. Eso es el 2,53 por ciento, contado a partir de los campos de versión de los bloques que devuelve la API Esplora de Blockstream el 21 de agosto de 2026. El 8 de agosto se abrió la ventana, llegaron bloques sin el bit, los nodos que aplicaban BIP-110 los rechazaron como inválidos y siguieron otra cadena. La propuesta quedó marcada como Closed en el repositorio de BIPs el 9 de agosto, con la línea de changelog "Mark as Closed, following a chain split with stalled mining" (bip-0110.mediawiki), y cubrimos la división en su momento.
Los relatos de lo que vino después difieren, y ambos están publicados. El estado en el repositorio de BIPs es "Closed". La página del propio proyecto BIP-110 dice que "Bitcoin está vivo, aunque con poco poder de hash, después de que los pools de minería SHA256d abandonaran la red" y que "se minan bloques nuevos, aunque a un ritmo más lento de lo habitual". El anuncio de Knots del 10 de agosto describe un ataque en curso y agrega que "se elegirá un nuevo algoritmo de prueba de trabajo el 11 de agosto a las 14:00 UTC" en un canal de Discord; hasta el 21 de agosto de 2026 no había aparecido ningún anuncio posterior en ese feed. Este sitio no va a decir cuál de esos encuadres es el correcto. Sí va a decir que son descripciones de dos historias de bloques distintas y que nada del desenlace está resuelto.
El punto transferible es angosto y corta para los dos lados. Los mineros no pudieron convertir BIP-110 en la regla señalizándola, y tampoco pudieron impedirla: los nodos que la aplicaban siguieron aplicándola sobre una cadena con casi nada del hashrate. Lo que sí determinaron los mineros fue con qué rapidez confirmaría cada una de las dos cadenas, que es una cuestión de usabilidad y no de validez, y bajo la regla de dificultad una cadena minoritaria no tiene forma rápida de corregirlo.
Qué deciden los desarrolladores, y qué no
El caso vivo es el valor por defecto de retransmisión de OP_RETURN.
Bitcoin Core integró el
pull request #32406 el 9 de junio de 2025, y el
cambio salió en la versión 30.0: "-datacarriersize sube a 100.000 por defecto, lo que en la
práctica elimina el límite (porque primero se alcanza el límite de tamaño de transacción). Se
puede anular con -datacarriersize=83 para volver al límite aplicado en versiones anteriores"
(notas de la versión 30.0).
Ya escribimos aparte sobre
la integración y qué cambió; la versión corta es
que el límite siempre fue una regla sobre qué retransmite un nodo, nunca sobre qué puede
contener un bloque, y el texto sobre la mempool desarrolla esa
distinción completa.
¿Qué decidieron entonces los desarrolladores? Decidieron qué hace su software cuando se ejecuta
sin cambiar nada. Eso es menos que "qué permite Bitcoin" y mucho más que "nada", porque los
valores por defecto son lo que ejecuta casi todo el mundo. No decidieron qué es válido: ninguna
regla de consenso se movió, y una transacción con un OP_RETURN grande era válida en un bloque
antes de la integración y también después. Tampoco pueden enviarle el cambio a nadie. Y de forma
explícita no decidieron la discusión, cosa que la propia declaración dice: "no respalda ni avala
el uso de datos no financieros".
La otra mitad de la respuesta es Bitcoin Knots, que existe justamente porque un valor por
defecto no es un veredicto. El proyecto se describe como "un derivado de Bitcoin Core con un
conjunto de mejoras retroportadas, propuestas y a veces mantenidas fuera del árbol git
principal"
(descripción de la versión 29.4.knots20260508),
y su sitio nombra a Luke Dashjr como mantenedor principal y describe el software como un "nodo y
billetera Bitcoin en uno" que "garantiza que los bitcoins recibidos sean bitcoins reales y estén
realmente recibidos a nombre de quien los recibe"
(bitcoinknots.org). Sus notas de versión incluyen una sección
titulada "New spam filters", es decir nuevos filtros de spam, y la versión 29.3.knots20260508,
publicada el 9 de mayo de 2026, incorporó BIP-110 detrás de una activación explícita
consensusrules=rdts, describiéndola como una actualización "que corrige vulnerabilidades
críticas en un diseño de red de larga data"
(notas de Knots 29.3.knots20260508).
Eso es lo que significa tener dos implementaciones. Una cambió un valor por defecto; la otra lo mantuvo y después fue más lejos. Nadie tuvo que ser pasado por encima para que ocurriera cualquiera de las dos cosas.
Las dos posiciones, en su versión más fuerte
Es un desacuerdo vivo entre personas que siguen discutiendo, así que acá está cada caso tal como lo plantean quienes lo defienden, con sus propias palabras.
La política de retransmisión debería ser restrictiva. Luke Dashjr respondió a la propuesta en la lista de correo de desarrollo el 26 de abril de 2025: "Debería sobrar decirlo, pero esta idea es una locura absoluta (utter insanity). Decepciona ver respuestas positivas y ni una sola réplica sensata que lo señale. Los errores deberían corregirse, no abrazar el abuso. Si los atacantes siguen esquivando los filtros, podemos volver a un enfoque de lista blanca completa. Llevamos más de dos años de esta ola de ataques, y el daño que ya ha causado debería bastar para demostrar que la actitud de no intervenir no es viable" (bitcoindev, 26 de abril de 2025). BIP-110 plantea el mismo caso al nivel del consenso: "para proteger la función que Bitcoin debe cumplir como dinero nativo de internet, la comunidad de Bitcoin ha tratado históricamente con antagonismo las técnicas para incrustar datos arbitrarios en transacciones de Bitcoin", y la propuesta "busca devolver a Bitcoin al camino de convertirse en el dinero del mundo, rechazando en el consenso la normalización del almacenamiento de datos como un uso soportado".
Dicho en una frase que un crítico tendría que responder: los costos del almacenamiento de datos caen sobre gente que nunca aceptó cargarlos, cada operador de nodo los guarda y los sirve para siempre, los valores por defecto son la política real de la red diga lo que diga la documentación, y un filtro con fugas sigue siendo un filtro que encarece la conducta a la que apunta. "Se puede esquivar" no es un argumento para quitarlo, o las cerraduras no tendrían sentido.
La política de retransmisión no debería hacerse pasar por consenso. Antoine Poinsot abrió el hilo el 17 de abril de 2025 con la observación de que la regla producía lo contrario de su intención: Clementine, un diseño de puente, "usa salidas Taproot no gastables para almacenar datos en su transacción 'WatchtowerChallenge' debido a las restricciones de standardness sobre el tamaño de los OP_RETURN", y "hemos visto en los últimos años que el empujón es ineficaz para disuadir el almacenamiento de datos en la cadena" (bitcoindev, 17 de abril de 2025). La declaración firmada plantea la versión sistémica: "negarse a sabiendas a retransmitir transacciones que los mineros incluirían en bloques de todos modos empuja a los usuarios a canales de comunicación alternativos", lo que traslada el envío de transacciones a acuerdos privados con mineros grandes y perjudica tanto la estimación de comisiones como la propagación de bloques.
Dicho en una frase que sus críticos tendrían que responder: el filtro no detuvo los datos, eligió
el formato, y el formato al que empujó a la gente fue una salida no gastable que queda en el
conjunto de UTXO para siempre en lugar de un OP_RETURN que un nodo puede descartar. Si el
efecto de una política es empeorar la externalidad mientras quienes la defienden señalan su
intención, la intención no es lo que hay que medir.
Las dos posturas son serias. Este sitio no va a elegir, y el motivo no es la diplomacia. Es que la pregunta sobre la que discrepan, si los valores por defecto de retransmisión de un nodo deben intentar moldear lo que hace la gente o intentar predecir lo que van a minar los mineros, sigue sin resolverse con ningún hecho disponible hoy.
Qué deciden los exchanges y los custodios
La palanca menos descrita. Cuando una cadena se divide, alguien tiene que decir cómo se llama lo que hay en cada cuenta, y esa decisión la toman empresas, en público y con fecha límite.
El aviso previo de Kraken para la división de Bitcoin Cash de 2018, publicado el 10 de noviembre de 2018, sigue siendo la formulación más clara del mecanismo: "Inicialmente Kraken solo dará soporte a Bitcoin ABC" y "después del fork, cualquier saldo de BCH en una cuenta de Kraken serán tokens de la red Bitcoin ABC" (Kraken, 10 de noviembre de 2018). Ocho días después listó también la otra cadena, con un ticker separado y una lista de riesgos declarados (Kraken, 18 de noviembre de 2018). Ese episodio es el tema de nuestro texto sobre la hash war, y lo que importa acá es que esa decisión no la tomó ningún minero ni ningún desarrollador.
La misma maquinaria funcionó otra vez este mes. Crypto Finance, escribiendo el 3 de agosto de 2026 sobre BIP-110, planteó el problema del custodio en términos operativos: "un custodio podría, por lo tanto, procesar un retiro en la cadena de Bitcoin que soporta y transferir sin quererlo el activo correspondiente en la otra rama", y enumeró lo que una división le exige a un custodio, incluida "una evaluación de si existe protección contra replay" (Crypto Finance, 3 de agosto de 2026).
Un ticker no es una afirmación sobre la verdad, y tampoco es nada. Decide qué puede comprar, vender, usar como garantía y tomar como unidad de precio la mayoría de la gente, lo que con el tiempo decide qué cadena tiene una economía. Eso es una forma de poder, en manos de partes que nadie eligió, y es la parte de la gobernanza de Bitcoin menos examinada por quienes escriben sobre la gobernanza de Bitcoin.
Dónde quedan los usuarios
Ni al final de esta lista como una ocurrencia tardía, ni arriba de todo como un eslogan.
Quien tiene monedas en un exchange delegó la pregunta entera. Quien ejecuta un nodo tomó una decisión sobre reglas de consenso, la haya vivido así o no, porque eso es instalar una implementación. Start9, que empaqueta software de nodo e incorporó una tarea de activación de BIP-110, le planteó la cuestión a sus propios clientes con toda la claridad posible: "esta guía no toma posición sobre qué cadena seguir. Es una decisión sobre reglas de consenso, y le corresponde a cada quien" (Start9, 5 de agosto de 2026).
La parte incómoda es que la mayoría de la gente no quiere esa decisión, y no hay manera honesta de devolverla. La alternativa a "cada quien decide qué reglas aplica su nodo" es que otro decida, y todo el diseño existe para impedir eso. Las notas de versión de Knots dicen el corolario sin rodeos desde el otro lado: saltearse una actualización "no la rechaza", y "para rechazar esta actualización de forma efectiva hay que ejecutar software alternativo diseñado para separarse de la red actualizada". La inacción no es neutralidad. Es consentir lo que haga a continuación el software que ya está corriendo.
Qué queda sin resolver
Al 21 de agosto de 2026: la retransmisión de OP_RETURN está sin tope por defecto en Bitcoin
Core y con tope por defecto en Bitcoin Knots. Alrededor de uno de cada cinco nodos alcanzables
anuncia Knots. BIP-110 figura como Closed en el repositorio de BIPs y como activa según el
proyecto que la escribió. Existen dos historias de bloques por encima de la altura 961.631 y cada
una tiene software que la aplica. Nadie concedió nada.
Cualquiera que diga cómo termina esto está adivinando. Lo que sí se puede decir sin adivinar es que el mecanismo funcionó tal como fue diseñado en todo el recorrido: quienes discrepaban sobre las reglas ejecutaron software distinto, y el desacuerdo se hizo visible como dos cadenas en lugar de como un lado obligado a acatar. Eso no es un fracaso de la gobernanza. En un sistema donde nadie manda, es la única forma que puede tomar un desacuerdo real, y el costo lo paga quien necesita saber, esta semana, en qué cadena está su dinero.