Il datacarrier, in italiano trasportatore di dati, si riferisce alla possibilità di inserire dati nelle transazioni Bitcoin, e ai parametri per controllare tale possibilità da parte di un nodo.

La blockchain Bitcoin, ha potenziali utilizzi che vanno oltre i pagamenti.
Molti sviluppatori hanno cercato di utilizzare il linguaggio di scripting delle transazioni per sfruttare la sicurezza e la resilienza di Bitcoin in applicazioni come servizi di notarizzazione digitale, certificati azionari e smart contract.

I primi tentativi di utilizzare il linguaggio di script di Bitcoin per questi scopi prevedevano la creazione di output nelle transazioni che registravano dati sulla blockchain; ad esempio, per registrare un'impronta di un file in modo che chiunque potesse dimostrare l'esistenza di quel file in una data specifica facendo riferimento a quella transazione.

L'uso della blockchain di Bitcoin per archiviare dati non correlati ai pagamenti di Bitcoin è un argomento controverso.
Molti sviluppatori considerano tale uso abusivo e vogliono scoraggiarlo. Altri lo vedono come una dimostrazione delle potenti capacità della tecnologia blockchain e vogliono incoraggiare tale sperimentazione.

Coloro che si oppongono all'inclusione di dati non legati ai pagamenti sostengono che provochi un "gonfiore della blockchain", gravando coloro che gestiscono full node con i costi di archiviazione su disco per dati che la blockchain non era destinata a trasportare. Inoltre, tali transazioni creano UTXO che non possono essere spesi, utilizzando l'indirizzo Bitcoin di destinazione come un campo libero di 20 byte. Poiché l'indirizzo è utilizzato per i dati, non corrisponde a una chiave privata e l'UTXO risultante non può mai essere speso; è un pagamento falso. Queste transazioni che non possono mai essere spese non vengono quindi rimosse dall'UTXO set e causano un aumento continuo delle dimensioni del database UTXO definito bloat.

Nel 2014 con la versione 0.9 di Bitcoin Core, si è raggiunto un compromesso con l'introduzione dell'operatore OP_RETURN, non come sostegno condiviso all'archiviazione di dati nella blockchain, ma con una modifica OP_RETURN che crea un output provabilmente eliminabile, per evitare schemi di archiviazione dati - alcuni dei quali erano già stati implementati - che archiviavano dati arbitrari come immagini in output delle transazioni permanentemente spendibili, gonfiando il database UTXO di bitcoin.
OP_RETURN consente agli sviluppatori di aggiungere qualche decina di byte di dati non legati ai pagamenti a un output di transazione. Tuttavia, a differenza dell'uso di UTXO "falsi", l'operatore OP_RETURN crea un output esplicitamente e provabilmente ineseguibile, che non deve essere archiviato nell'UTXO set. Gli output OP_RETURN vengono registrati sulla blockchain, quindi occupano spazio su disco e contribuiscono all'aumento delle dimensioni della blockchain, ma non vengono archiviati nell'UTXO set e quindi non gonfiano la memoria pool UTXO e gravano sui full node con i costi maggiori in termini di memoria RAM.

La porzione di dati è limitata e rappresenta più spesso un hash, come l'output dell'algoritmo SHA256 (32 byte). Molte applicazioni aggiungono un prefisso davanti ai dati per aiutare a identificare l'applicazione.

Non esiste uno script di sblocco che potrebbe essere utilizzato per "spendere" un output OP_RETURN, che di solito è un output con un importo di bitcoin pari a zero, perché qualsiasi bitcoin assegnato a tale output è effettivamente perso per sempre.

Se un output OP_RETURN viene indicato come input in una transazione, il motore di validazione dello script interromperà l'esecuzione dello script di validazione e contrassegnerà la transazione come non valida.

Una transazione standard (quella conforme ai controlli IsStandard()) può avere solo un output OP_RETURN. Tuttavia, un singolo output OP_RETURN può essere combinato in una transazione con output di qualsiasi altro tipo.

Nel 2015 a partire dalla versione 0.10 sono state aggiunte due nuove opzioni da riga di comando in Bitcoin Core:

• datacarrier: L'opzione datacarrier controlla il relay e il mining delle transazioni RETURN, con il valore predefinito "1" per consentirle.
• datacarriersize: L'opzione datacarriersize richiede un argomento numerico che specifica la dimensione massima in byte dello script OP_RETURN (o più precisamente degli scriptPubKey che trasportano dati) e conseguentemente dei dati che possono essere inseriti in un output. il valore di default di 83 byte, che consente un massimo di 80 byte di dati RETURN più un byte dell'opcode RETURN e due byte dell'opcode PUSHDATA.

Questa dimensione impatta le transazioni che vengono distribuite dal nodo alla rete (relay) e per la costruzione del blocco da minare, ma non impatta la validità delle transazioni di un blocco (algoritmo di consenso).

Questa impostazione di default è cambiata nel tempo poiché l'uso di OP_RETURN è stato ed è dibattuto perché incorporare dati nella blockchain di Bitcoin ne aumenta le dimensioni senza supportare direttamente il trasferimento di Bitcoin e per alcuni questo è un uso improprio di Bitcon:

• v0.9.0 40 byte: con Bitcoin Core 0.9.0, il limite di dimensioni di OP_RETURN era impostato a 40 byte
• v0.11 80 byte: nel 2016, con la versione Bitcoin Core 0.11, il limite di dimensioni di OP_RETURN è stato aumentato a 80 byte.
• v0.12 83 byte: dalla versione Bitcoin Core 0.12, le regole di inoltro standard consentono un singolo output con OP_RETURN, che contiene qualsiasi sequenza di istruzioni push (o OP_RESERVED) dopo OP_RETURN a condizione che sia al massimo 83 byte.

Nel 2023 con l'introduzione Inscription, si ravviva la polemica sull'uso o presunto abuso della blockchain Bitcoin, sul quale debba essere una giusta dimensione.

Luke Dashjr, col dichiarato tentativo di filtrare le Inscription produce una patch per Bitcoin Core chiamata Ordisrespector, che segue quanto aveva già fatto con una versione di Bitcoin Core modificata chiamata Knots, con il parametro datacarriersize impostato a 42 byte dal 2016, ed estendendo il controllo di questa dimensione degli extra data nelle transazioni non solo le i dati di OP_RETURN (le Inscription non usano infatti OP_RETURN).