El cheque en blanco de 100.000 bytes: Bitcoin Core v30, OP_RETURN y la rebelión de Knots

1. Ochenta y tres bytes de tregua

Durante años, la política predeterminada de Bitcoin Core retransmitía y minaba transacciones con un máximo de 83 bytes de datos OP_RETURN en una sola salida. OP_RETURN marca los datos adjuntos como demostrablemente no gastables. El tope y la salida única eran reglas de estandarización, no de validez de bloques.^[1][11]

La regla nunca fue consenso. Bitcoin Core define la política de mempool o retransmisión como normas adicionales aplicadas a transacciones no confirmadas antes de admitirlas. Son locales, configurables y no se aplican a transacciones dentro de bloques. Una transacción no estándar para un nodo aún puede ser minada, y retransmitirla no equivale a respaldar su contenido.^[8]

La disputa sobre datos precedía a 2025: el hilo de #32406 mencionó una propuesta anterior de filtrado de inscripciones que no se fusionó. En abril de 2025, bitcoin-dev reabrió el debate sobre elevar o eliminar el límite predeterminado de OP_RETURN.^[3][10]

2. La lista de correo se satura

El hilo creció tanto que Bitcoin Optech, en su boletín del 02-05-2025, renunció a resumirlo por completo y presentó el argumento que consideraba más sólido de cada lado.^[10]

A favor de levantar el límite, Pieter Wuille argumentó que las políticas de estandarización difícilmente impiden la confirmación de transacciones con datos generadas por entidades con amplia financiación, capaces de remitirlas de forma directa a los mineros. Añadió además que los bloques suelen estar llenos tanto si contienen datos arbitrarios como si no, de modo que el volumen total de datos que un nodo debe almacenar resulta prácticamente idéntico en ambos casos.^[10]

En contra de la propuesta, Jason Hughes advirtió que elevar el límite facilitaría el almacenamiento de datos arbitrarios en los ordenadores de los nodos completos, y que parte de esa información podría resultar sumamente objetable —incluyendo material ilegal en la mayoría de las jurisdicciones— sin importar si el nodo cifra o no su almacenamiento.^[10]

El 27-04-2025, Peter Todd formalizó la discusión en una solicitud de incorporación. Titulada 'Eliminar límites arbitrarios en salidas OP_Return (datacarrier)' y registrada bajo el PR #32359, proponía suprimir las restricciones y las opciones -datacarrier en su totalidad, razonando que ya eran eludidas mediante envíos directos a mempools de mineros como Slipstream de MARA o bifurcaciones sin filtros como Libre Relay. La propuesta se cerró sin fusionar el 12-05-2025, pero su premisa central perduró en un compromiso posterior.^[9]

3. Concept NACK: el repositorio entra en erupción

El 02-05-2025, el colaborador de Bitcoin Core Gregory Sanders (GitHub: instagibbs) abrió la solicitud de incorporación #32406, 'policy: uncap datacarrier by default'. La propuesta aumentaba el parámetro predeterminado -datacarriersize para admitir hasta 100.000 bytes de datos en OP_RETURN —prácticamente el tamaño máximo de una transacción—, autorizaba múltiples salidas de OP_RETURN por transacción de forma predeterminada y mantenía las opciones -datacarrier únicamente como ajustes en desuso sujetos a eliminación futura.^[3][11]

El hilo acumuló Concept ACKs y NACKs. Un mantenedor recordó las normas del repositorio: discutir el parche, no Bitcoin en general, y criticar ideas, no motivos. El rechazo más tajante provino de Luke Dashjr, mantenedor de Bitcoin Knots:^[3][5]

Concept NACK. Ya hemos pasado por esto en múltiples PR. Enviarlo como spam con diferencias menores irrelevantes no cambiará la locura y malicia fundamentales del concepto.^[5]

— Luke Dashjr

Sanders, autor de la propuesta, rehusó considerar el límite tradicional como un pilar estructural indispensable. Cuando un comentarista sostuvo que las restricciones a los portadores de datos existen primordialmente para proteger la capa peer-to-peer y la mempool, su respuesta fue contundente:^[4]

Simplemente no es cierto. La única motivación de la regla es inducir a las personas a no almacenar datos arbitrarios en la cadena cuando se pueda evitar.^[4]

— Gregory Sanders

4. Dos clientes, valores predeterminados opuestos

La solicitud de incorporación #32406 se fusionó el 09-06-2025. El resumen técnico de Bitcoin Optech documentó las claves: el valor predeterminado de -datacarriersize ascendió de 83 a 100.000 bytes —el límite de tamaño máximo de una transacción—, se levantó la restricción de una sola salida OP_RETURN por transacción, el límite pasó a aplicarse de forma agregada a la suma de todas esas salidas y las opciones -datacarrier quedaron en desuso de cara a versiones futuras.^[3][11]

El 13-10-2025 se publicó Bitcoin Core versión 30.0 con la nueva política en sus notas de versión: -datacarriersize se eleva a 100.000 por defecto, lo que en la práctica elimina el límite al alcanzarse antes el tamaño máximo de transacción, y puede revertirse mediante -datacarriersize=83 para restablecer el comportamiento previo. Las notas especifican que ahora se permiten múltiples salidas de datos para retransmisión y minería, aplicando el límite al tamaño agregado de todas ellas.^[1][2]

El código citado de Bitcoin Knots v28.1 ya contenía valores opuestos. Su cabecera de política limita OP_RETURN a 42 bytes —40 de datos más opcode— y activa el cómputo completo de métodos de datos conocidos. Su inicialización ofrece -datacarriercost para añadir peso de mempool y -corepolicy para fijar valores similares a Core, incluido -datacarriersize=83.^[12][7]

Los dos clientes ofrecían así políticas locales distintas sin cambiar el consenso. Peter Todd, cuya propuesta más amplia había cerrado semanas antes, indicó a los discrepantes que existía una implementación alternativa:^[3][6]

Aquí tenemos un buen consenso entre los desarrolladores razonables que contribuyen activamente a Bitcoin Core de que este cambio es una buena idea. En segundo lugar, aquellos que sigan en desacuerdo con este cambio son bienvenidos a ejecutar una bifurcación alternativa como Knots.^[6]

— Peter Todd

5. La guerra que nadie podía ganar

Lo que la disputa nunca afectó fue el consenso. Ninguna regla de validez de bloques cambió en ninguno de los clientes: las políticas de retransmisión y minería se mantuvieron como configuraciones locales aplicadas únicamente a transacciones no confirmadas, de modo que una transacción rechazada como no estándar por un nodo podía ser minada por cualquier minero que la aceptara. Retransmitir datos tampoco implicó validarlos moral o legalmente: la mempool es solo un área de tránsito, no el registro definitivo.^[1][8]

Las etiquetas tampoco zanjaron la disputa. Los calificativos de 'spam' y 'censura' se mantuvieron como posturas de parte y no como hechos objetivos: Optech optó por presentar los argumentos más sólidos de cada bando sin dictar sentencia, y los canales de elusión señalados en el PR #32359 —el envío directo a mineros mediante servicios como Slipstream de MARA— demostraron que los valores predeterminados eran sugerencias sorteables para emisores con recursos, no barreras infranqueables.^[9][10]

La disputa dejó un mercado de valores predeterminados. Participantes afirmaron que había migración de Core a Knots, pero el hilo no aportó una métrica concluyente. Las versiones citadas codificaron respuestas opuestas —100.000 bytes en Core 30.0 y 42 en Knots v28.1—, de modo que los operadores podían expresar su preferencia mediante el software y la configuración.^[3][12]