<p>I think I get it now. So Blockchain.info's wallet use to have a field for adding custom messages via a public note field. </p>

<p><a href="https://i.sstatic.net/irNWz.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/irNWz.png" alt="enter image description here"></a>
(<a href="https://blog.blockchain.com/2014/05/09/tutorial-how-to-send-bitcoins-using-our-web-wallet/" rel="nofollow noreferrer">https://blog.blockchain.com/2014/05/09/tutorial-how-to-send-bitcoins-using-our-web-wallet/</a>)</p>

<p>This was "potentially" creating lot of un-spendable outputs. Ie bloating the blockchain in a bad way. </p>

<blockquote>
  <p>"Yes, please don't create lots of unspendable scriptPubKeys. There are
  more prunable ways of embedding messages into transactions. And there
  are even better ways of associating messages with transactions, so
  only people involved with the transaction can read the message (if
  that's desired).</p>
  
  <p>In other words, lets figure out how to do this the right way. The way
  you're doing it now will stop working as soon as the network upgrades
  anyway (0-value outputs are nonstandard as of the 0.7 release)."</p>
</blockquote>

<p>(<a href="https://bitcointalk.org/index.php?topic=40264.msg1162402#msg1162402" rel="nofollow noreferrer">https://bitcointalk.org/index.php?topic=40264.msg1162402#msg1162402</a>)</p>

<p>When the OP_RETURN drama eventually passed, this allowed any kind of meta data to be stored on the blockchain to the tune of 80 bytes in a "friendlier" way. </p>

<p>Coloredcoin (and others) then made extensive use of this but because it uses the OP_RETURN code, this means that transactions are not stuck in limbo in UTXO and in addition, they can be removed or "pruned" with no detrimental effect. </p>

<p>In summary, adding non-bitcoin/ledger related data to the blockchain is only frowned upon by the people in the "use the bitcoin blockchain only for financial data" camp. With OP_RETURN, it is not such a big deal now because it can be pruned and keeps the people who want to put meta data on the blockchain happy. </p>

CC BY-SA 3.0
2017-01-20T03:39:16.040Z
2017-01-20T03:39:16.040Z
cloudnthings
<p>Using an OP_REUTRN output is prunable. Writing data directly into a output's scriptPubKey is not prunable. Pruning outputs allows for the UTXO set to shrink and be efficiently used, where as non-prunable outputs will forever create bloat and slowdown the set traversal(e.g. during block verification).</p>

<blockquote>
  <p>Don't they set a precedent?</p>
</blockquote>

<p>In my opinion, the default core rules are more the precedent than how outside protocols choose to use them. They have already been tweaked a couple of times(e.g. 40 bytes, 80 bytes, prunable...).</p>

CC BY-SA 3.0
2017-01-19T02:30:25.277Z
do you mean: scriptPubKey: OP_RETURN {zero or more ops} where "OP_RETURN immediately marks the script as invalid, guaranteeing that no scriptSig exists that could possibly spend that output. Thus the output can be immediately pruned from the UTXO set even if it has not been spent." –
cloudnthings
CC BY-SA 3.0
2017-01-20T03:02:30.317Z
Yes. Are you referring to a different use of it?
Steve Ellis
CC BY-SA 3.0
2017-01-18T20:23:59.800Z
2017-01-18T20:23:59.800Z
Steve Ellis
<p>It seems that adding data to OP_RETURN is frowned upon and considered as bloating the blockchain. </p>

<p>Blockchain.info wallet also had a short stint where users could include data into the OP_RETURN field before it was pulled.</p>

<p>I like that fact that this field exists but can also understand the arguments against putting random data in there. </p>

<p>Coloredcoin makes extensive use of OP_RETURN so does this mean that coloredcoin's actions are frowned upon by the community? Don't they set a precedent? </p>

<op-return><colored-coins>
Colored coin adds meta data to OP_RETURN. Why isn't this frowned upon?
cloudnthings
# Colored coin adds meta data to OP_RETURN. Why isn't this frowned upon?

(Asked by: username_0 on 2017-01-15)

It seems that adding data to OP\_RETURN is frowned upon and considered as bloating the blockchain.

Blockchain.info wallet also had a short stint where users could include data into the OP\_RETURN field before it was pulled.

I like that fact that this field exists but can also understand the arguments against putting random data in there.

Coloredcoin makes extensive use of OP\_RETURN so does this mean that coloredcoin's actions are frowned upon by the community? Don't they set a precedent?

**Tags:** op-return, colored-coins


---

## 2 answers

### Answer by username_0 on 2017-01-20. Score: 1

I think I get it now. So Blockchain.info's wallet use to have a field for adding custom messages via a public note field.

[![enter image description here](https://i.sstatic.net/irNWz.png)](https://i.sstatic.net/irNWz.png)
(<https://blog.blockchain.com/2014/05/09/tutorial-how-to-send-bitcoins-using-our-web-wallet/>)

This was "potentially" creating lot of un-spendable outputs. Ie bloating the blockchain in a bad way.

> "Yes, please don't create lots of unspendable scriptPubKeys. There are
> more prunable ways of embedding messages into transactions. And there
> are even better ways of associating messages with transactions, so
> only people involved with the transaction can read the message (if
> that's desired).
>
> In other words, lets figure out how to do this the right way. The way
> you're doing it now will stop working as soon as the network upgrades
> anyway (0-value outputs are nonstandard as of the 0.7 release)."

(<https://bitcointalk.org/index.php?topic=40264.msg1162402#msg1162402>)

When the OP\_RETURN drama eventually passed, this allowed any kind of meta data to be stored on the blockchain to the tune of 80 bytes in a "friendlier" way.

Coloredcoin (and others) then made extensive use of this but because it uses the OP\_RETURN code, this means that transactions are not stuck in limbo in UTXO and in addition, they can be removed or "pruned" with no detrimental effect.

In summary, adding non-bitcoin/ledger related data to the blockchain is only frowned upon by the people in the "use the bitcoin blockchain only for financial data" camp. With OP\_RETURN, it is not such a big deal now because it can be pruned and keeps the people who want to put meta data on the blockchain happy.


---

### Answer by username_1 on 2017-01-18. Score: 0

Using an OP\_REUTRN output is prunable. Writing data directly into a output's scriptPubKey is not prunable. Pruning outputs allows for the UTXO set to shrink and be efficiently used, where as non-prunable outputs will forever create bloat and slowdown the set traversal(e.g. during block verification).

> Don't they set a precedent?

In my opinion, the default core rules are more the precedent than how outside protocols choose to use them. They have already been tweaked a couple of times(e.g. 40 bytes, 80 bytes, prunable...).

> **Comments:**
> **username_0**: do you mean: scriptPubKey: OP_RETURN {zero or more ops} where "OP_RETURN immediately marks the script as invalid, guaranteeing that no scriptSig exists that could possibly spend that output. Thus the output can be immediately pruned from the UTXO set even if it has not been spent." –  
> **username_1**: Yes. Are you referring to a different use of it?  

---

