user-1: Why are OP_RETURN transactions discouraged? Are they paying less fees compared to other transactions?
Will it make any difference if same thing is done using version or locktime when data is either 1 or 2?
Example:
OP_RETURN
createrawtransaction '[]' '{"data":"32"}'

LOCKTIME
createrawtransaction '[]' 2

VERSION
Change source code and make this configurable although it's already 2 so don't need to change for this example: https://github.com/bitcoin/bitcoin/blob/7fcf53f7b4524572d1d0c9a5fdc388e87eb02416/src/primitives/transaction.h#L263

user101498: You can't achieve the same thing using the parts without consensus meaning of nSequence + nLockTime (like Lightning does for example). There is just not enough space: 48 "free" bits.
Changing the version is a bad idea, as it could be used to opt-in to a future soft fork which rules haven't been defined yet. Transactions with a version < 2 are also (and therefore) not standards.

user208: Whether OP_RETURN transactions are discouraged or not is a matter of opinion.
Personally, I think transactions should not store any data that isn't needed for the world to verify them, which is by definition the case for the data stored in OP_RETURNs. Either you're using it to use the blockchain as data storage (which is a ridiculously inefficient technology for the purpose it serves, and under sufficient fee pressure, very expensive), or you're using it to communicate something to the receiver which could have been done out of band instead.
So it isn't a critique on OP_RETURN itself - it's a critique on what you're trying to do with it. It would equally apply to trying to use locktime or version or sequence numbers for the same purpose: in my view, this is all just building technically inferior solutions that should use other approaches (not using the blockchain) entirely.
There is no price difference; the bytes in the OP_RETURN count for just as much as any other (non-segwit) bytes. So why is this concerning? The issue is that every transaction, even ones with outputs that don't make it into the UTXO set, have a cost to the network. Every full node has to download and process it. Transactions pay a fee, but that fee goes to miners, not to full node operators. There are various reasons for running a node, but all of them in one way or another relate to it enabling participation in the Bitcoin economy. They don't do it for dealing with your personal and/private data.
I don't think this is an issue in the long term - fee pressure will push (and to a large extent has pushed) out pointless uses of the blockchain to other systems. However, the Bitcoin ecosystem is still relatively young, and to not stifle its growth, I find it wise to discourage people from burdening nodes with transaction data that does not help the ecosystem.
That said, if for whatever reason you're going to be creating a data storage solution based on the blockchain anyway, by all means, use OP_RETURN. At least that way you're burdening the blockchain, and not the UTXO set.

-1: <p>Why are OP_RETURN transactions discouraged? Are they paying less fees compared to other transactions?</p>
<p>Will it make any difference if same thing is done using version or locktime when data is either 1 or 2?</p>
<p>Example:</p>
<p>OP_RETURN</p>
<pre><code>createrawtransaction '[]' '{&quot;data&quot;:&quot;32&quot;}'
</code></pre>
<p>LOCKTIME</p>
<pre><code>createrawtransaction '[]' 2
</code></pre>
<p>VERSION</p>
<p>Change source code and make this configurable although it's already 2 so don't need to change for this example: <a href="https://github.com/bitcoin/bitcoin/blob/7fcf53f7b4524572d1d0c9a5fdc388e87eb02416/src/primitives/transaction.h#L263" rel="nofollow noreferrer">https://github.com/bitcoin/bitcoin/blob/7fcf53f7b4524572d1d0c9a5fdc388e87eb02416/src/primitives/transaction.h#L263</a></p>
 101498: <p>You can't achieve the same thing using the parts without consensus meaning of <code>nSequence</code> + <code>nLockTime</code> (like <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#commitment-transaction" rel="nofollow noreferrer">Lightning does</a> for example). There is just not enough space: 48 &quot;free&quot; bits.</p>
<p>Changing the version is a bad idea, as it could be used to opt-in to a future soft fork which rules haven't been defined yet. Transactions with a version <code>&lt; 2</code> are also (and therefore) not standards.</p>
 208: <p>Whether OP_RETURN transactions are discouraged or not is a matter of opinion.</p>
<p>Personally, I think transactions should not store any data that isn't needed for the world to verify them, which is by definition the case for the data stored in OP_RETURNs. Either you're using it to use the blockchain as data storage (which is a ridiculously inefficient technology for the purpose it serves, and under sufficient fee pressure, very expensive), or you're using it to communicate something to the receiver which could have been done out of band instead.</p>
<p>So it isn't a critique on OP_RETURN itself - it's a critique on what you're trying to do with it. It would equally apply to trying to use locktime or version or sequence numbers for the same purpose: in my view, this is all just building technically inferior solutions that should use other approaches (not using the blockchain) entirely.</p>
<p>There is no price difference; the bytes in the OP_RETURN count for just as much as any other (non-segwit) bytes. So why is this concerning? The issue is that every transaction, even ones with outputs that don't make it into the UTXO set, have a cost to the network. Every full node has to download and process it. Transactions pay a fee, but that fee goes to miners, not to full node operators. There are various reasons for running a node, but all of them in one way or another relate to it enabling participation in the Bitcoin economy. They don't do it for dealing with your personal and/private data.</p>
<p>I don't think this is an issue in the long term - fee pressure will push (and to a large extent has pushed) out pointless uses of the blockchain to other systems. However, the Bitcoin ecosystem is still relatively young, and to not stifle its growth, I find it wise to discourage people from burdening nodes with transaction data that does not help the ecosystem.</p>
<p>That said, if for whatever reason you're going to be creating a data storage solution based on the blockchain anyway, by all means, use OP_RETURN. At least that way you're burdening the blockchain, and not the UTXO set.</p>
