OP_RETURN sur Bitcoin : data carriers, nulldata et sorties impossibles à dépenser

Une sortie Bitcoin contient un montant et un script de verrouillage appelé scriptPubKey. Une sortie OP_RETURN, aussi classée nulldata, commence par l’opcode OP_RETURN et peut ensuite pousser une suite d’octets. Une fois la transaction incluse dans un bloc, ces octets sont publiquement enregistrés dans la sortie. Cette forme ne crée ni couche de données séparée, ni solde de jeton, ni message privé.

OP_RETURN est un opcode qui fait échouer l’exécution lorsqu’on l’atteint. Une tentative de dépenser une sortie dont le script commence ainsi ne peut donc pas satisfaire le script. Bitcoin Core la classe comme impossible à dépenser et peut l’omettre immédiatement de l’ensemble UTXO. La vérification figure dans le script.h de Bitcoin Core 31.1. Bitcoin Core 31.1 script implementation.

Une limite de data carrier ne compte pas nécessairement que les données de l’application. Le script de sortie brut comprend l’opcode OP_RETURN, l’instruction de push avec son encodage de longueur et le payload. Un payload de 80 octets peut former un script de 83 octets : un octet pour l’opcode, deux pour l’en-tête OP_PUSHDATA1 et 80 pour les données. Les anciennes références à « 80 octets » parlent souvent du payload, tandis que les nouveaux réglages peuvent mesurer le script entier.

Bitcoin Core 31.1 active -datacarrier par défaut. -datacarriersize vaut 100 000 octets et additionne les tailles des scriptPubKey bruts de toutes les sorties porteuses de données d’une transaction. Plusieurs sorties NULL_DATA partagent cette limite, qui inclut aussi l’opcode et l’encodage du push. Core 30.0 a remplacé l’ancienne limite de 83 octets de script par une limite agrégée de 100 000 octets et autorisé plusieurs sorties ; Core 31.1 conserve ces paramètres. Consultez les options de Core 31.1, l’implémentation de la politique et les notes de version 30.0.

Chaque nœud peut désactiver le relais des data carriers ou réduire sa limite locale. D’autres nœuds ou versions logicielles peuvent faire un autre choix. Le refus d’une transaction dans le mempool d’un nœud peut donc simplement refléter sa politique de relais, et non une interdiction du consensus. Bitcoin Core applique la limite de données lors du contrôle de standardness et vérifie séparément les règles de consensus lors de la validation des blocs. Core consensus transaction checks. See Bitcoin Core 31.1 mempool standardness implementation.

Une sortie OP_RETURN peut recevoir une valeur, mais celle-ci ne peut pas être récupérée et devient définitivement inutilisable. Les portefeuilles lui attribuent souvent zéro. Si 1 000 sats lui sont affectés, ils ne deviennent pas automatiquement des frais de mineur. Les frais restent égaux à la somme des entrées moins celle de toutes les sorties. Les octets du script consomment du poids de transaction et peuvent augmenter les frais à taux sat/vB égal. Consultez le guide des frais de transaction Bitcoin.

Bitcoin Core 31.1 accepte plusieurs sorties NULL_DATA standard, mais additionne leurs scripts dans la même limite par transaction. Répartir le payload ne crée pas de capacité supplémentaire et chaque sortie ajoute des données et du poids de bloc. Le relais dépend aussi du poids, des frais et d’autres règles de standardness. L’acceptation par un portefeuille ou un explorateur ne garantit pas la propagation sur tout le réseau.

Les données OP_RETURN se trouvent dans le scriptPubKey de sortie au moment où la transaction est créée. Les données witness de SegWit sont sérialisées séparément pour chaque entrée ; BIP 141 les décrit comme des données de pile associées à une entrée. Une dépense par chemin de script Taproot peut révéler le script et le bloc de contrôle dans le witness de l’entrée. Un logiciel Ordinals peut interpréter un format d’enveloppe révélé comme une inscription selon une convention applicative, ce qui diffère d’une sortie nulldata. Consultez BIP 141, BIP 341 et le guide [Ordinals et inscriptions Bitcoin](/learn/bitcoin-ordinals-inscriptions-satoshi-numbering-witness-data-explained).

Identifiez la version de Bitcoin Core et les options locales sur lesquelles vous vous appuyez. Calculez séparément la taille du script de sortie complet, le poids total de la transaction, la valeur de la sortie impossible à dépenser et les frais du mineur. Le consensus ne donne pas de sens à des octets arbitraires ; vérifiez aussi que le protocole ou le destinataire comprend le format. Les données inscrites sur la chaîne sont publiques : n’y mettez ni mot de passe, ni information personnelle, ni fichier confidentiel. Le guide des UTXO et du contrôle des pièces Bitcoin explique les sorties et la monnaie rendue.