BIP 110, llamado Reduced Data Temporary Softfork, es una propuesta cerrada para endurecer temporalmente las reglas con las que los nodos aceptan bloques. Un nodo es un ordenador que verifica por sí mismo el historial y los pagos. La propuesta buscaba dificultar ciertos usos para almacenar datos y, según sus defensores, reforzar la función monetaria de la red. Eso no la convirtió automáticamente en una regla de todo Bitcoin.
Imagina que dos operadores de nodos reciben el mismo bloque. Uno lo acepta con las reglas existentes y el otro lo rechaza por una nueva restricción. BIP 110 llegaba hasta ese nivel: cambiaría la validez de los bloques, no solo la disposición a retransmitir una transacción o conservarla en el mempool, la sala de espera local de los pagos sin confirmar. La revisión del 2026-10-23 encontró la versión 1.0.1 de la especificación en estado Closed, es decir, cerrada. Tener un número BIP o un programa publicado no certifica la adopción por la red. El registro conserva el documento y su historia; no cambia a distancia las reglas de los nodos. [1] [2]
Cada salida nueva tiene un scriptPubKey, un script que fija las condiciones para gastarla después. La propuesta permitía como máximo 34 bytes, o 83 bytes si empezaba por OP_RETURN, una instrucción que hace que la salida sea demostrablemente imposible de gastar. Se cuenta el script completo. Otro límite, de 256 bytes, afectaba a los datos individuales de OP_PUSHDATA* y a los argumentos del witness, la información que acompaña a una transacción para verificar el gasto. Una excepción es insertar el redeemScript, el script revelado con las condiciones de gasto, en el scriptSig de BIP16. Los witness scripts y Tapleaf scripts no son en sí esos argumentos, aunque sus instrucciones para insertar datos siguen sujetas al límite. Se miden partes concretas, no el tamaño total de la transacción ni de todo el witness. [1]
La propuesta también afectaba a Taproot, una forma de expresar condiciones de gasto. Prohibía gastar versiones no definidas de witness o Tapleaf, pero no crear esas salidas. Rechazaba el annex, un campo adicional, y los control blocks de más de 257 bytes: pruebas demasiado largas de que un script pertenece a la estructura comprometida. Tapscript no podía contener OP_SUCCESS* ni siquiera en código no ejecutado, ni ejecutar OP_IF u OP_NOTIF, independientemente del resultado de la condición. Como referencia técnica, los formatos definidos incluyen P2WPKH, P2WSH, P2TR con versión Tapleaf 0xc0 y P2A con programa 0x4e73, este último solo con una pila witness vacía. Son nombres precisos de formatos, no datos que el usuario deba introducir en su cartera. [1]
Un UTXO es una salida aún no gastada: una cantidad concreta con condiciones para utilizarla. La propuesta exime a las entradas que gastan UTXO confirmados antes de la activación. Eso no da vía libre a las salidas nuevas de la misma transacción. Firmar por adelantado tampoco protege una salida que solo se crea durante el periodo activo. Para ciertas construcciones Taproot prefirmadas, la especificación admite fondos bloqueados o perdidos si las restricciones invalidan las vías previstas y no queda una alternativa utilizable. Esto también plantea efectos sobre Miniscript, una herramienta para construir condiciones de gasto, y BitVM, construcciones para verificar cálculos. No cabe prometer, por tanto, que solo se vería afectado el contenido no monetario. [1] [3]
Un minero puede incluir una señal de apoyo en el bloque: aquí se usaba el bit 4 y un umbral de 1109 de 2016 bloques, aproximadamente el 55 por ciento. Pero la propuesta iba más allá de la señal voluntaria. Si el umbral no se alcanzaba antes, exigía señalizar entre las alturas 961632–963647, pasar a LOCKED_IN desde 963648 y a ACTIVE desde 965664, siempre que esa cadena llegara hasta allí. La altura es la posición del bloque en la cadena. LOCKED_IN confirma la transición; ACTIVE aplica las restricciones de datos. El cliente ya rechazaría bloques sin señal durante el periodo obligatorio, de modo que los nodos podrían separarse antes de aplicar los límites. Estos durarían 52416 bloques desde la activación real y después pasarían a EXPIRED, dejando de aplicarse; no equivalen a un año exacto de calendario. [1] [4]
Los defensores buscaban reducir el coste de operar nodos, la presión sobre el conjunto UTXO y el contenido no deseado, dando prioridad a los pagos. Esos objetivos explican la motivación, pero no demuestran los resultados. Los críticos señalaron efectos sobre scripts útiles, futuras ampliaciones y el riesgo de dividir la red. Además, los datos pueden fragmentarse: Peter Todd mostró en el debate inicial una transacción que contenía toda la propuesta de entonces repartida en piezas. Ni la especificación promete eliminar por completo la esteganografía, es decir, ocultar información dentro de otros datos. Encarecer el almacenamiento e impedirlo del todo son resultados distintos. Del mismo modo, la preocupación por la responsabilidad legal sobre el contenido no establece por sí sola una obligación jurídica concreta. [1] [3]
El registro del PR 2247 describe una división el 2026-08-08 a la altura 961632. La cadena principal contenía un bloque sin la señal exigida, mientras OCEAN minó una alternativa que sí señalizaba. El 2026-08-09, Murch comunicó que la rama minoritaria había producido solo 2 bloques y se había detenido, mientras la principal avanzaba más de 100 bloques. Hay que leer ese informe con su fecha y autor: no es una reproducción independiente del blockchain realizada para este artículo ni una descripción del estado actual de la rama minoritaria. También muestra por qué una división causada por la señalización no equivale a alcanzar ACTIVE y poner en marcha las restricciones de datos. [5] [6]
El documento pasó por Complete, especificación terminada, y acabó en Closed. El PR 2245 para cerrarlo se incorporó el 2026-08-10; el historial de la especificación indica 2026-08-09. Las fechas corresponden a registros distintos, no a otra activación. La versión del cliente v0.4.1 documenta EXPIRED y vbrequired, el campo de la plantilla de bloque que indica el bit de señalización obligatorio. La existencia de ese cliente no supone adopción en Bitcoin Core. También hay test vectors, transacciones de ejemplo con resultados esperados, y pruebas funcionales. Este artículo no las ejecuta ni verifica la cadena minoritaria actual. Explica la propuesta y su historia documentada, sin presentar un documento histórico como las reglas compartidas actuales de la red. [7] [1] [4]
Un byte más puede cambiar el resultado
Imagina la comprobación de una salida nueva bajo las hipotéticas reglas activas. Un scriptPubKey normal de 34 bytes supera esta prueba de longitud; con 35 bytes falla. Un script que empieza por OP_RETURN puede tener 83 bytes; con 84 bytes supera el límite. Siempre medimos el script de salida completo, no solo el texto insertado. Superar esa prueba no demuestra la validez de toda la transacción, y gastar un UTXO antiguo no exime a la salida nueva.
Para obtener la imagen más completa, lee esta entrada junto con Soft Fork, Full Node, Taproot, Bitcoin Script, Transaction Fees, UTXO. También enlazan con esta entrada OP_RETURN.
01¿Closed significa que ya nadie puede ejecutar el cliente?+
Closed es el estado de un documento, no una prohibición de usar software. Cada nodo sigue las reglas de su programa. Quien elija reglas diferentes puede acabar en otra rama de la cadena; cerrar una entrada del registro no elimina esa diferencia.
02¿Ya se aplicaban los límites de datos durante la señalización obligatoria?+
No. La señalización obligatoria precede a LOCKED_IN y ACTIVE. Un cliente puede rechazar un bloque sin la señal exigida antes de que entren en vigor las reglas de datos. La fecha del calendario no basta: importan el estado y la altura de la cadena concreta.