0

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

Improve this question

2 Answers 2

Reset to default
1

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.

Improve this answer
2
  • Thanks. Just realised that there is a huge difference in size (4 bytes vs 80 bytes) if we compare OP_RETURN with other two. Also locktime is only useful if it's between 0 and last block, version is limited to 1 and 2 for standard transactions. Still not sure why are OP_RETURN transactions discouraged? A 40 byte OP_RETURN tx and a normal segwit tx of 40 byte should be considered same by full nodes? Both are paying fees for block space.
    – user103136
    Commented Aug 30, 2021 at 9:03
  • OP_RETURN scriptPubKeys should be prefered to carry data because they can be easily identified and pruned. The UTXO database space is a much scarcer resource than the block chain one.
    – Antoine Poinsot
    Commented Aug 30, 2021 at 9:32
4

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.

Improve this answer
3
  • I can understand UTXO set argument however 'burdening the blockchain' is beyond my understanding. Bitcoin halving reduces rewards in every 210,000 blocks. So Bitcoin needs transactions and fees to survive in long term. If a project increases Bitcoin transactions and fees, it's net positive and should be encouraged. Full node has to verify everything so how does it matter what is being verified?
    – user103136
    Commented Aug 30, 2021 at 14:00
  • If people start using blockchain transactions for activity that doesn't contribute to the bitcoin economy (e.g. aren't related to economic activity that involves BTC moving), that's an opportunity cost for others who do. This is mostly a worry about systems like omni and counterparty which parasitically use the blockchain for economic activity of competing systems. Early on - and perhaps not anymore - they posed a very real threat IMO to bitcoin by pricing out real BTC activity.
    – Pieter Wuille
    Commented Aug 30, 2021 at 14:15
  • 2
    @Prayank's argument seems like planning for failure to me. Yes Bitcoin needs fees to survive in the long term. But at least for me Bitcoin will have failed if the only way it can get those fees is through OP_RETURNs. High value transactions, Lightning channel opens and closes, whatever other L2 protocols need from the blockchain will be competing in the success case. And those use cases would price out the OP_RETURN use case. I don't think Bitcoin will be economically significant long term if OP_RETURNS are helping to prop up transaction fees.
    – Michael Folkson
    Commented Aug 30, 2021 at 14:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.