OP_RETURN en Bitcoin: portadores de datos, nulldata y salidas no gastables
Aprende cómo OP_RETURN registra datos públicos, por qué la salida no se puede gastar, cómo difiere la política de retransmisión de Bitcoin Core 31.1 del consenso y qué cambia frente a las inscripciones en witness.
En esta guíaOP_RETURN coloca datos en el script de bloqueo
Resumen breve
OP_RETURN permite adjuntar datos públicos al script de salida de una transacción de Bitcoin. Bitcoin Core considera no gastables las salidas cuyo script empieza por OP_RETURN y las excluye del conjunto UTXO. Los límites actuales de retransmisión son política de cada nodo, no un límite de payload impuesto por el consenso a toda la red.
OP_RETURN coloca datos en el script de bloqueo
Cada salida de Bitcoin contiene un importe y un script de bloqueo llamado scriptPubKey. Una salida OP_RETURN, también clasificada como nulldata, empieza por el opcode OP_RETURN y puede insertar después una secuencia de bytes. Al incluirse la transacción en un bloque, esos bytes quedan registrados públicamente como parte de la salida. La forma OP_RETURN seguida de datos es un esquema; no crea una capa de datos separada, un saldo de tokens ni un mensaje privado.
Por qué la salida no se puede gastar otra vez
OP_RETURN es un opcode que falla si la ejecución lo alcanza. Un intento de gastar una salida cuyo script empieza por ese opcode no puede satisfacer el script. Por eso Bitcoin Core clasifica esa salida como no gastable y puede omitirla del conjunto UTXO sin conservar una moneda que nunca podrá gastarse. La implementación se puede consultar en el script.h de Bitcoin Core 31.1. Bitcoin Core script implementation.
El script ocupa más que el payload
Cuando un nodo aplica un límite de portador de datos, el tamaño no es necesariamente el de los bytes de la aplicación. El script de salida completo incluye el opcode OP_RETURN, la instrucción para insertar datos, su codificación de longitud y el payload. Un payload de 80 bytes puede producir un script de 83: un byte de opcode, dos del encabezado OP_PUSHDATA1 y 80 de datos. Por eso las guías antiguas que dicen «80 bytes» suelen referirse al payload, mientras que las opciones nuevas pueden contar el script completo.
Política predeterminada de datos en Bitcoin Core 31.1
Bitcoin Core 31.1 activa -datacarrier de forma predeterminada y establece -datacarriersize en 100.000 bytes. La opción mide el tamaño agregado de los scriptPubKey sin procesar de todas las salidas portadoras de datos de una transacción. Varias salidas NULL_DATA comparten el límite y cuentan también el opcode y la codificación de inserción. Core 30.0 sustituyó el límite antiguo de 83 bytes de script por uno agregado de 100.000 y permitió varias salidas; Core 31.1 conserva ese valor. Consulta las opciones de Core 31.1, la implementación de política y las notas de Core 30.0.
Compara datos OP_RETURN en una salida con datos witness en una entrada; ocupan campos distintos y siguen reglas diferentes
La retransmisión y el consenso responden a preguntas distintas
Cada nodo puede desactivar la retransmisión de datos o reducir su límite local; otros nodos y versiones pueden usar otra configuración. Que un nodo rechace una transacción en su mempool puede significar que su política local no la retransmite, no que el consenso la prohíba. Bitcoin Core aplica el límite de datos en la comprobación de transacciones estándar y comprueba por separado las reglas de consenso al validar bloques. Core consensus transaction checks. See Bitcoin Core 31.1 mempool standardness implementation.
El valor de la salida se pierde; la comisión se calcula aparte
Una salida OP_RETURN puede llevar un valor, pero no se puede recuperar y queda permanentemente inutilizable. Las carteras suelen asignarle cero. Si se asignan 1.000 sats, no se convierten automáticamente en comisión del minero. La comisión sigue siendo la suma de entradas menos la suma de todas las salidas. Los bytes del script ocupan peso de transacción y pueden aumentar la comisión a una misma tasa sat/vB. Consulta la guía de comisiones de Bitcoin.
Dividir datos en varias salidas no multiplica el límite
Bitcoin Core 31.1 permite varias salidas NULL_DATA estándar, pero suma sus tamaños de script dentro del mismo límite por transacción. Dividir el payload entre salidas no amplía el cupo y cada salida agrega datos y peso de bloque. La retransmisión también depende del peso de transacción, las comisiones y otras reglas de estándar de cada nodo. Que una cartera o explorador acepte la transacción no garantiza que se propague en toda la red.
OP_RETURN no es una inscripción en witness de Taproot
Los datos OP_RETURN están en el scriptPubKey de una salida al crear la transacción. Los datos witness de SegWit se serializan por separado para cada entrada; BIP 141 los describe como datos de pila por entrada. Un gasto por ruta de script de Taproot puede revelar el script y un bloque de control en el witness de entrada. El software Ordinals puede interpretar una estructura reconocida como inscripción según una convención de aplicación, distinta de una salida nulldata. Consulta BIP 141, BIP 341 y la guía de [Ordinals e inscripciones de Bitcoin](/learn/bitcoin-ordinals-inscriptions-satoshi-numbering-witness-data-explained).
Comprueba la política, el valor y la privacidad antes de usarlo
Identifica la versión de Bitcoin Core y la configuración local en que confías. Calcula por separado el tamaño del script de salida completo, el peso total de la transacción, el valor asignado a la salida no gastable y la comisión del minero. El consenso no da significado a bytes arbitrarios; confirma además que el protocolo o destinatario reconoce el formato. Lo escrito en la cadena es público: no guardes contraseñas, datos personales ni archivos que deban ser privados. Para entender salidas y cambio, consulta la guía de UTXO y control de monedas de Bitcoin.
Preguntas frecuentes
Q1¿El consenso de Bitcoin limita OP_RETURN a 80 bytes de datos?
No. Los 80 bytes describen un ejemplo de política de estándar antiguo para el payload, no un límite universal de consenso. Bitcoin Core 31.1 usa por defecto un máximo agregado de 100.000 bytes de script de datos; cada nodo puede configurarlo de otra forma.
Q2¿Un OP_RETURN más grande aumenta la comisión?
Puede hacerlo. Los bytes del script añaden peso, por lo que la comisión puede subir a una tasa sat/vB dada. Los sats asignados a la salida no gastable se pierden por separado y no son la comisión del minero.
Q3¿OP_RETURN y una inscripción Ordinals son lo mismo?
No. OP_RETURN está en un script de salida y hace que esa salida no se pueda gastar. Una inscripción Taproot típica coloca contenido en datos de ruta de script del witness de entrada, que Ordinals interpreta según sus propias convenciones.
