OP_RETURN

Jana quiere adjuntar información a una transacción, no enviar otra cantidad a alguien. Por eso empieza una salida con OP_RETURN. Si alguien intentase gastarla, ejecutar esa instrucción haría fallar la comprobación del script, independientemente de la firma. El script de salida se llama técnicamente scriptPubKey. Importan la posición y la ejecución: el mismo byte dentro de los datos no es una orden que se esté ejecutando. Tampoco equivale un OP_RETURN en una rama no ejecutada a tenerlo al principio. No basta, pues, con buscar el nombre o el byte en cualquier lugar de la transacción. [1] [5]

Bitcoin Core clasifica la forma habitual como NULL_DATA. El nombre no significa que esté vacía. La función Solver exige OP_RETURN al principio y un resto que supere IsPushOnly, es decir, que solo contenga instrucciones para insertar datos. Puede llevar texto, un hash —una huella breve calculada— o un registro para otro protocolo. Esa clasificación no valida el significado del mensaje ni garantiza que entre en la cola del nodo. El registro tampoco atribuye automáticamente propiedad de un archivo, autoría o efectos jurídicos; esas afirmaciones necesitan otras reglas y pruebas. [3]

Los nodos mantienen el conjunto UTXO, las salidas aún no gastadas que pueden utilizarse. Cuando una salida comienza con OP_RETURN, saben que nadie podrá gastarla. IsUnspendable la reconoce y AddCoin no la añade a la caché UTXO. Se ahorra trabajo en ese estado operativo, no espacio en todo el historial: la transacción confirmada sigue en el bloque y los datos deben transmitirse y conservarse en sus copias históricas. Excluirla de UTXO no borra los datos. Si alguien asigna dinero a esa salida, tampoco es una recompensa para el minero. La cantidad es imposible de gastar y una firma posterior no la recupera. [2] [6] [1]

El consenso determina qué bloques considera válidos un nodo. La política local selecciona, en cambio, qué entra en su mempool, la cola de transacciones sin confirmar, y qué retransmite u ofrece para minar. Así protege sus recursos. Los operadores pueden elegir ajustes distintos: rechazar la retransmisión no significa que un bloque con esa transacción incumpla el consenso. Entrar en el mempool tampoco promete confirmación. La opción datacarriersize fija un presupuesto local de datos; no cambia por sí sola la validez de los bloques ni borra contenido confirmado. [8]

El antiguo valor predeterminado que suele citarse permitía 1 salida de datos con un script de hasta 83 bytes: normalmente 80 bytes de contenido más las instrucciones. Bitcoin Core 30.0 elevó datacarriersize a 100000 por defecto y permitió varias salidas de datos. El código resta la longitud de todo el scriptPubKey de cada salida de un presupuesto común. No cuenta solo el mensaje, ni incluye el campo exterior que indica la longitud del script. Los demás límites de la transacción siguen vigentes. Elegir 83 recupera el presupuesto anterior, pero no la regla de una sola salida. Son cifras de un cambio concreto de versión, no una ley inmutable de la red. [7] [4] [8]

Jana puede introducir el hash del documento en OP_RETURN en vez del archivo. Cuando muestre el original más adelante, otra persona podrá calcular su huella con el mismo método y compararla con el registro. Debe conservar los bytes exactos y el procedimiento: la huella no sustituye al documento. Una coincidencia no demuestra la veracidad del contenido, que Jana lo escribió ni cuándo lo creó exactamente. El registro público también puede relacionar identidades; aplicar un hash no garantiza privacidad. El coste depende de toda la transacción y de la demanda de espacio en bloques, no solo de la longitud del mensaje. [1] [8]

Hay una excepción importante y bien delimitada a los mensajes de aplicaciones. BIP 141 usa OP_RETURN en la coinbase, la transacción inicial del bloque, para el witness commitment: un vínculo criptográfico con los datos adjuntos necesarios para verificar las transacciones. El scriptPubKey correspondiente tiene al menos 38 bytes y empieza por 0x6a24aa21a9ed. Si varias salidas coinciden con el patrón, se elige el índice más alto, la última salida coincidente en el orden. Si el bloque no contiene datos witness, el compromiso es opcional. La red comprueba esa estructura concreta; no verifica por ello la verdad de cualquier texto detrás de OP_RETURN. [9]

Primero pregunta a qué cliente, versión y configuración se refiere el límite. Después hay que decodificar la transacción real y distinguir scriptPubKey de los campos que lo rodean al codificarlo en bytes. La prueba mempool_datacarrier.py ilustra los casos límite de la implementación; este artículo no la ejecuta. BIP 110 propuso restricciones adicionales de consenso, pero está cerrado y no es una regla activada por datacarriersize. Describir una versión antigua no promete que todos los nodos o versiones futuras se comporten igual. Un ajuste concreto y una confirmación real son informaciones distintas. [10] [8] [11]