La propuesta BIP 110 describe una bifurcación suave temporal para reducir algunas formas de insertar datos en Bitcoin. El documento figura con estado «Complete» en el repositorio de Bitcoin Improvement Proposals, pero eso no significa que las reglas estén ya vigentes: una BIP es una especificación y su activación requiere el mecanismo de señalización y los hitos que la propia propuesta define.
La distinción es importante. Las transacciones y los nodos de la red no cambian porque un texto técnico se dé por terminado. BIP 110 plantea un despliegue de aproximadamente un año, con un periodo de señalización de los mineros, bloqueo y activación. Hasta que esos pasos no se cumplan en la cadena, las restricciones no forman parte de las reglas de consenso aplicadas por Bitcoin.
Siete límites durante un despliegue de un año
La propuesta se titula Reduced Data Temporary Softfork. Durante la ventana en que estuviera activa, añade siete comprobaciones de consenso. Limita los nuevos scriptPubKey a 34 bytes, salvo salidas OP_RETURN de hasta 83 bytes; también invalida cargas OP_PUSHDATA y elementos de argumentos del testigo que superen 256 bytes, con la excepción prevista para ciertos redeemScript de BIP16.
Las otras medidas afectan a caminos menos cotidianos de Taproot y SegWit. BIP 110 impediría gastar versiones de testigo o de Tapleaf que aún no estén definidas, descartaría las pilas con anexo de Taproot, pondría un máximo de 257 bytes a los bloques de control de Taproot y rechazaría tanto los opcodes OP_SUCCESS como la ejecución de OP_IF u OP_NOTIF en Tapscript. No es un límite general al tamaño de las transacciones: son reglas concretas sobre determinados campos y construcciones.
El texto incorpora una salvaguarda esencial: los UTXO creados antes de la hipotética altura de activación quedarían exentos. Es decir, la propuesta intenta que las monedas ya existentes puedan gastarse según las condiciones con las que fueron creadas. Las restricciones se aplicarían a UTXO nacidos después de la activación y, cuando expirase el periodo, dejarían de aplicarse también a esos nuevos UTXO.
Qué busca resolver y qué coste tendría
El objetivo declarado es dificultar que la cadena se use para almacenar datos arbitrarios de forma contigua, en especial mediante técnicas que el autor considera una carga para quienes operan nodos. La motivación pone el foco en el coste de guardar el conjunto UTXO y en la competencia por el espacio de bloque. Eso no convierte por sí solo cualquier dato en una transacción en algo prohibido: el diseño intenta cerrar vectores específicos y conservar los usos monetarios conocidos.
También hay contrapartidas. El límite a los bloques de control reduce el tamaño de los árboles de scripts de Taproot y podría condicionar diseños experimentales, como algunos que emplean gran cantidad de scripts. La desactivación de OP_IF y OP_NOTIF afectaría a ciertas construcciones de Tapscript. El documento reconoce escenarios muy poco habituales con transacciones prefirmadas en los que podrían aparecer problemas si se cumplen varias condiciones a la vez.
Ese debate técnico es distinto de otro que suele aparecer al hablar de seguridad de activos digitales. El reciente problema de semillas predecibles de Coldcard, por ejemplo, concernía a la generación de claves de un dispositivo; BIP 110 trata de las condiciones de validez que podrían aplicar los nodos a determinados gastos. Confundir la capa de consenso con la seguridad de una cartera conduce a conclusiones equivocadas.
Completa no significa activada
La especificación propone usar una variante de BIP9 con el bit 4 de señalización, un umbral del 55 % por periodo de 2.016 bloques y una altura máxima de activación de 965.664. Tras entrar en vigor, la duración prevista es de 52.416 bloques, aproximadamente un año. La secuencia prevista pasa por los estados DEFINED, STARTED, LOCKED_IN, ACTIVE y EXPIRED.
Por tanto, la información práctica para usuarios y desarrolladores es prudente: BIP 110 es una propuesta documentada, no una norma ya activa en Bitcoin. Quien mantenga software, herramientas de Taproot o aplicaciones que escriban datos en cadena puede revisar el texto y los vectores de prueba, pero no debe asumir que la red haya cambiado. La aceptación y la activación se verían en el consenso efectivo, no solo en el estado editorial de la BIP.
