OP_RETURN

Jana veut joindre une information à une transaction, pas envoyer une somme supplémentaire. Elle commence donc une sortie par OP_RETURN. Lors d’une tentative de dépense, exécuter cette instruction ferait échouer la vérification du script, quelle que soit la signature. Le nom technique du script de sortie est scriptPubKey. Sa position et son exécution comptent : le même octet à l’intérieur des données n’est pas une instruction exécutée. OP_RETURN dans une branche non exécutée n’équivaut pas non plus à OP_RETURN au début. Trouver le nom ou l’octet quelque part dans la transaction ne suffit donc pas. [1] [5]

Bitcoin Core classe la forme habituelle dans NULL_DATA. Ce nom ne signifie pas que la sortie est vide. La fonction Solver exige OP_RETURN au début, puis une suite passant IsPushOnly, donc uniquement des instructions d’insertion de données. Elle peut contenir du texte, un hash — une courte empreinte calculée — ou un enregistrement pour un autre protocole. Ce classement ne valide pas le sens du message et ne garantit pas à lui seul l’entrée dans la file du nœud. L’inscription n’établit pas automatiquement la propriété d’un fichier, son auteur ou un effet juridique ; ces affirmations demandent d’autres règles et preuves. [3]

Les nœuds entretiennent l’ensemble UTXO, les sorties encore non dépensées et disponibles. Pour une sortie commençant par OP_RETURN, ils savent déjà que personne ne pourra la dépenser. IsUnspendable la reconnaît et AddCoin ne l’ajoute pas au cache UTXO. Cela économise le suivi de cet état de travail, pas la place dans tout l’historique : la transaction confirmée demeure dans le bloc et les données doivent être transmises et conservées dans ses copies historiques. L’exclusion des UTXO ne les efface pas. Attribuer de l’argent à cette sortie ne rémunère pas non plus le mineur. La somme devient impossible à dépenser, sans qu’une signature ultérieure puisse la récupérer. [2] [6] [1]

Le consensus définit les blocs qu’un nœud juge valides. Sa politique locale choisit plutôt ce qui entre dans son mempool, la file des transactions non confirmées, ce qu’il relaie et ce qu’il propose au minage. Il protège ainsi ses ressources. Les opérateurs peuvent avoir des réglages différents : refuser de relayer une transaction ne signifie pas qu’un bloc la contenant viole le consensus. L’entrée dans le mempool ne promet pas non plus une confirmation. datacarriersize fixe un budget local de données ; cette option ne modifie pas à elle seule la validité des blocs et n’efface aucun contenu confirmé. [8]

L’ancien réglage par défaut souvent cité autorisait 1 sortie de données avec un script de 83 octets au maximum, généralement 80 octets de contenu plus les instructions. Bitcoin Core 30.0 a porté datacarriersize à 100000 par défaut et permis plusieurs sorties de données. Le code retranche la longueur de chaque scriptPubKey entier d’un budget commun. Il ne compte pas seulement le message et n’inclut pas le champ externe indiquant la longueur du script. Les autres limites de transaction restent applicables. Régler 83 rétablit donc le budget, pas l’ancienne règle de sortie unique. Ces chiffres décrivent un changement de version précis, pas une loi immuable du réseau. [7] [4] [8]

Jana peut mettre le hash de son document dans OP_RETURN plutôt que le document lui-même. Lorsqu’elle présentera l’original, on pourra recalculer son empreinte par la même méthode et la comparer à l’inscription. Elle doit conserver les octets exacts et la méthode : l’empreinte ne remplace pas le fichier. Une correspondance ne prouve ni la vérité du contenu, ni que Jana en est l’autrice, ni la date précise de création. Un enregistrement public peut aussi relier des identités, et une donnée hachée n’est pas automatiquement privée. Le coût dépend de toute la transaction et de la demande d’espace dans les blocs, pas seulement de la longueur du message. [1] [8]

Il existe une exception importante, précisément définie, aux messages applicatifs ordinaires. BIP 141 utilise OP_RETURN dans la coinbase, la transaction initiale du bloc, pour le witness commitment : un lien cryptographique avec les données jointes nécessaires à la vérification des transactions. Le scriptPubKey correspondant mesure au moins 38 octets et commence par 0x6a24aa21a9ed. Si plusieurs sorties correspondent, l’indice le plus élevé l’emporte, donc la dernière sortie correspondante dans l’ordre. Sans données witness dans le bloc, le witness commitment est facultatif. Le réseau vérifie ici une structure définie ; il ne vérifie pas pour autant la vérité de n’importe quel texte après OP_RETURN. [9]

Demandez d’abord de quel client, de quelle version et de quelle configuration il s’agit. Il faut ensuite décoder la transaction réelle et distinguer scriptPubKey des champs qui l’entourent dans l’encodage en octets. Le test mempool_datacarrier.py illustre les cas limites de l’implémentation ; cet article ne l’exécute pas. BIP 110 proposait d’autres restrictions de consensus, mais c’est une proposition close, pas une règle activée par datacarriersize. Décrire une ancienne version ne garantit pas le même comportement de tous les nœuds ou des versions futures. Un réglage et une confirmation effective sont deux informations différentes. [10] [8] [11]