3
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?
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.
(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.
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...).
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 – 2017-01-19T02:30:25.277
1Yes. Are you referring to a different use of it? – Steve Ellis – 2017-01-20T03:02:30.317