<p>Note that you should only do this, putting extra data into the block chain, if it is really necessary. The block chain has to be stored by every full node, so try not to take up all our hard drive space with unnecessary stuff whenever possible.</p>

<p>With that said, if you do want to add extra data to your transaction, then add an additional output to the transaction, for which the scriptPubKey has the following form:</p>

<pre><code>OP_RETURN {80 bytes of whatever data you want}
</code></pre>

<p>This transaction output is automatically un-spendable, and so will not be kept in the UTXO set. The other UTXOs from your transaction will still be safe.</p>

<p>For more info:</p>

<ul>
<li><a href="https://bitcointalk.org/index.php?topic=414886.0" rel="noreferrer">https://bitcointalk.org/index.php?topic=414886.0</a></li>
<li><a href="https://bitcoinfoundation.org/2013/10/core-development-update-5/" rel="noreferrer">https://bitcoinfoundation.org/2013/10/core-development-update-5/</a></li>
</ul>

<p>This will embed extra information into your transaction. Be aware, though, that the software that made the transaction and the software that reads the transaction have to be compatible in order for the user to be able to read the given information when the transaction is received.</p>

<p>You can see an example of a transaction that used OP_RETURN to encode extra information here: <a href="https://blockchain.info/tx/6dfb16dd580698242bcfd8e433d557ed8c642272a368894de27292a8844a4e75?show_adv=true" rel="noreferrer">https://blockchain.info/tx/6dfb16dd580698242bcfd8e433d557ed8c642272a368894de27292a8844a4e75?show_adv=true</a>.</p>

CC BY-SA 3.0
2014-11-09T19:00:57.233Z
You're doing it wrong, look again at the example transaction linked in the answer, the third output is the OP_RETURN and the entire output script is "OP_RETURN 68656c6c6f20776f726c64" (decoded: jhello world). There is no OP_DUP, OP_HASH160, keyID, OP_EQUALVERIFY or OP_CHECKSIG in an OP_RETURN output script. It's an unspendable output that contains the OP_RETURN opcode and up to 40 bytes of arbitrary data, nothing more or less, it's a separate output from any pay to pubkey hash or pay to script hash outputs in the same transaction.
stevenh512
CC BY-SA 3.0
2014-10-15T14:39:44.190Z
Note that receivers (other outputs of your tx), or people in general, won't automatically see this information. People would have to know about your particular tx and specifically decode it and view its raw contents, in order to be aware of your info.
RocketNuts
CC BY-SA 3.0
2014-10-15T15:17:19.457Z
Thanks, @RocketNuts, I will edit my answer to include the information you gave.
morsecoder
CC BY-SA 3.0
2014-10-16T06:21:53.270Z
Thank you very much for your reply. I'm sure this is the right way to do it, but I'm having some trouble with including data into the transaction object with OP_RETURN. I really appreciate you if you could help me with this.
Rasela Don
CC BY-SA 3.0
2014-10-16T12:34:44.463Z
Where are you getting stuck? Can you tell me what you've tried?
morsecoder
CC BY-SA 3.0
2014-10-17T08:40:48.350Z
std::vector<unsigned char> data;
*script << OP_DUP << OP_HASH160 << keyID << OP_EQUALVERIFY << OP_CHECKSIG << OP_RETURN << data;

I just send the required data like this. I could successfully make the transaction, but it doesn't go to the block chain. 
I could find the type of the transaction as follows.
"type": "nonstandard"
Rasela Don
CC BY-SA 3.0
2017-04-23T15:26:35.503Z
I think the size changed in 2015 from 40 to 80. Right?
Leandro
CC BY-SA 3.0
2017-04-23T22:57:07.830Z
@Leandro Fixed.
Nick ODell
CC BY-SA 4.0
2018-07-10T11:25:34.623Z
@Leandro Yes the size changed to 80 bytes
Erhard Dinhobl
CC BY-SA 3.0
2014-10-15T13:56:24.573Z
2017-04-23T22:56:24.060Z
2017-04-23T22:56:24.060Z
morsecoder
<p>I want to add some additional information to my specific transaction, so that I can send the additional information to blockchain.</p>

CC BY-SA 3.0
2014-10-15T08:37:38.457Z
possible duplicate of [How to send bitcoin with a message attached](http://bitcoin.stackexchange.com/questions/19893/how-to-send-bitcoin-with-a-message-attached)
knaperek
CC BY-SA 3.0
2014-10-15T15:22:10.907Z
I don't think this is a duplicate, this question relates to adding the extra info into the block chain, the other is just trying to make an associated message with a transaction, such as in a "bitcoin:" URI.
morsecoder
<bitcoind><op-return>
How to add additional information to transaction?
Rasela Don
# How to add additional information to transaction?

(Asked by: username_0 on 2014-10-15)

I want to add some additional information to my specific transaction, so that I can send the additional information to blockchain.

**Tags:** bitcoind, op-return

> **Comments:**
> **username_1**: possible duplicate of [How to send bitcoin with a message attached](http://bitcoin.stackexchange.com/questions/19893/how-to-send-bitcoin-with-a-message-attached)  
> **username_2**: I don't think this is a duplicate, this question relates to adding the extra info into the block chain, the other is just trying to make an associated message with a transaction, such as in a "bitcoin:" URI.  

---

## 1 answers

### Answer by username_2 on 2014-10-15. Score: 12

Note that you should only do this, putting extra data into the block chain, if it is really necessary. The block chain has to be stored by every full node, so try not to take up all our hard drive space with unnecessary stuff whenever possible.

With that said, if you do want to add extra data to your transaction, then add an additional output to the transaction, for which the scriptPubKey has the following form:

```
OP_RETURN {80 bytes of whatever data you want}

```

This transaction output is automatically un-spendable, and so will not be kept in the UTXO set. The other UTXOs from your transaction will still be safe.

For more info:

* <https://bitcointalk.org/index.php?topic=414886.0>
* <https://bitcoinfoundation.org/2013/10/core-development-update-5/>

This will embed extra information into your transaction. Be aware, though, that the software that made the transaction and the software that reads the transaction have to be compatible in order for the user to be able to read the given information when the transaction is received.

You can see an example of a transaction that used OP\_RETURN to encode extra information here: <https://blockchain.info/tx/6dfb16dd580698242bcfd8e433d557ed8c642272a368894de27292a8844a4e75?show_adv=true>.

> **Comments:**
> **username_4**: Note that receivers (other outputs of your tx), or people in general, won't automatically see this information. People would have to know about your particular tx and specifically decode it and view its raw contents, in order to be aware of your info.  
> **username_2**: Thanks, @username_4, I will edit my answer to include the information you gave.  
> **username_0**: Thank you very much for your reply. I'm sure this is the right way to do it, but I'm having some trouble with including data into the transaction object with OP_RETURN. I really appreciate you if you could help me with this.  
> **username_2**: Where are you getting stuck? Can you tell me what you've tried?  
> **username_0**: std::vector<unsigned char> data; *script << OP_DUP << OP_HASH160 << keyID << OP_EQUALVERIFY << OP_CHECKSIG << OP_RETURN << data;  I just send the required data like this. I could successfully make the transaction, but it doesn't go to the block chain.  I could find the type of the transaction as follows. "type": "nonstandard"  
> **username_3**: You're doing it wrong, look again at the example transaction linked in the answer, the third output is the OP_RETURN and the entire output script is "OP_RETURN 68656c6c6f20776f726c64" (decoded: jhello world). There is no OP_DUP, OP_HASH160, keyID, OP_EQUALVERIFY or OP_CHECKSIG in an OP_RETURN output script. It's an unspendable output that contains the OP_RETURN opcode and up to 40 bytes of arbitrary data, nothing more or less, it's a separate output from any pay to pubkey hash or pay to script hash outputs in the same transaction.  
> **username_5**: I think the size changed in 2015 from 40 to 80. Right?  
> **username_6**: @username_5 Fixed.  
> **username_7**: @username_5 Yes the size changed to 80 bytes  

---

