Qué pasó
El 9 de junio de 2025, Bitcoin Core fusionó el
pull request #32406, "policy: uncap
datacarrier by default", abierto por Greg Sanders el 2 de mayo. Eleva el tamaño por defecto de
datos OP_RETURN que un nodo acepta y retransmite, y permite más de una salida de ese tipo por
transacción. Las opciones -datacarrier y -datacarriersize sobreviven, marcadas como
obsoletas, así que quien opere un nodo y quiera el comportamiento anterior puede recuperarlo.
Es el segundo intento. El #32359 de Peter Todd, abierto el 27 de abril, eliminaba las opciones por completo y se cerró el 12 de mayo tras 206 comentarios. La versión que se fusionó es la más conservadora: cambia un valor por defecto en lugar de quitar un interruptor.
La discusión corrió en la lista de correo de desarrollo desde el 17 de abril, en un hilo abierto por Antoine Poinsot. Tres días antes de la fusión, 31 colaboradores publicaron una declaración sobre política de relay con el razonamiento. Luke Dashjr, que calificó la propuesta de "utter insanity" en la lista, no figura entre los firmantes, y Bitcoin Knots mantiene el límite anterior.
Qué cambia
Lo que difunde un nodo. Nada más.
La propia documentación de política de Bitcoin Core traza la línea en una frase: la política es un conjunto de reglas "in addition to consensus, enforced for unconfirmed transactions before submitting them to the mempool", y "Policy is not applied to transactions in blocks."
Una transacción que llevaba 200 bytes en un OP_RETURN siempre fue válida dentro de un bloque. El valor por defecto anterior solo significaba que un nodo estándar se negaba a pasarla a sus pares. Los mineros pueden aceptar transacciones por otras vías, y lo hacen: el pull request las nombra, el envío directo al servicio de un minero y las bifurcaciones de Core que nunca aplicaron el límite.
El efecto observado del filtro fue redirigir los datos en vez de impedirlos, a veces hacia un lugar peor. El mensaje de Poinsot en la lista da el caso que motivó esto: un diseño de puente que guarda sus datos en salidas Taproot ingastables "due to the standardness restrictions on the size of OP_RETURNs". Un OP_RETURN no le cuesta nada a un nodo. Una salida ingastable de ese otro tipo se queda en el conjunto UTXO indefinidamente.
Pieter Wuille, que dice haber defendido estos límites en el pasado, explicó su cambio de opinión en términos de adónde van las transacciones cuando la red pública las rechaza: empujar esa demanda fuera de la red abierta de relay "is far more damaging" que transportarla.
Qué no cambia
No permite nada nuevo. No se movió ninguna regla de consenso, no hay soft fork involucrado y
ningún nodo está obligado a adoptar el nuevo valor por defecto. -datacarriersize=83 restaura
el comportamiento previo en cualquier máquina cuyo operador así lo quiera.
No zanja el desacuerdo sobre si los datos no financieros pertenecen a los bloques. La declaración de relay es explícita en que "is not endorsing or condoning non-financial data usage".
Y no impide que lleguen datos a la cadena por otros medios. Las inscripciones nunca usaron
OP_RETURN: usan el witness, y ninguna configuración de datacarrier las tocó jamás.
Contexto
OP_RETURN se agregó en Bitcoin Core 0.9.0 en 2014 para darle a los
datos un lugar que los nodos pudieran descartar, y el valor por defecto de 83 bytes ha sido
política desde entonces. Siempre fue un compromiso: lo bastante chico para desalentar el
almacenamiento masivo, lo bastante grande para un hash de compromiso.
Las inscripciones de enero de 2023 lo esquivaron por completo, y el volumen que vino después hizo más difícil defender el propósito que le quedaba al filtro. Esta discusión trata de cuál debería ser un valor por defecto cuando aquello que filtra ya está entrando por varias otras puertas.