The OP_RETURN opcode (or null_data) is used as a mechanism to store arbitrary data on-chain.
Clearly, nulldata field is useful for a number of use cases - generally speaking for transaction metadata which can be used to implement colored coins (tokens) and other applications like storing hashes of PR articles.
Currently, up to 256 bytes can be included per Peercoin transaction.
In comparison, up to 220 bytes can be included in BitcoinCash transactions, 80 bytes in Bitcoin (core) transactions, and 520 bytes in Bitcoin-SV transactions.
Max size of OP_RETURN has already been increased in Peercoin, with RFC0008.
Ordinals embed image related data into the Bitcoin blockchain using the input field in Taproot transactions, the witness. Unlike the OP_Return scriptPubKey format, which some people may think is designed for arbitrary data, this Taproot input related data therefore receives the witness discount enabled with the SegWit upgrade in 2017. In addition to this, there is no consensus rule limiting the size of Taproot inputs and therefore the arbitrary data can take as much space as one wants (up until the blocksize limit of 4MB). In order to store large amounts of data before Taproot, one may have had to use multiple transactions or multiple inputs. Indeed, before Taproot there was a rich history of embedding all kinds of weird data into the blockchain. However, there are still policy rules and therefore these very large transactions will not be relayed by the node network and they must be sent directly to the miner.
Recently usage of “Ordinals”, a system where one can embed image data into the Bitcoin blockchain has increased. In this brief piece, based on blockchain data, we analyze the growth of the Ordinals system. Up until 7 February 2023, we have identified over 13,000 of these transactions, which take up 526MB of Bitcoin blockspace.
From: Ordinals Data | BitMEX Blog
If anyone cares to learn more I believe this is the go-to link:
Ordinals are seen as exploit by Bitcoin core developers, and they kinda are. Bitcoin developers never wanted arbitrary data on-chain, and for this reason, the OP_RETURN max size is so limited. Now, thanks to taproot and ordinals users can upload up to 4MB of data per transaction - filling the block entirely.
Thanks to ordinals, NFTs are coming back to Bitcoin (yes indeed, NFTs have originated on Bitcoin) and unlike NFTs on Ethereum (and clones) those are real NFTs. Real NFTs because the .jpg itself has been uploaded on the chain rather than just an unverified link to external data storage.
Non-fungible tokens (NFTs) hit the market 2016 when the Bitcoin-based Counterparty token protocol was at peak of its popularity. The first use case of gaming related NFTs have been crypto-collectible trading card games. Projects like Age of Chains and Rare Pepes have been using the Counterparty protocol to issue Bitcoin based blockchain trading cards as NFTs as early as 2016. NFTs are best thought of as collectible art pieces, and each one is associated with a unique digital token to prove its rarity.
Given that we are adopting Taproot with v0.12 and that Taproot enables uploading a full block’s worth of arbitrary data on-chain why don’t we simply allow (effectively) unlimited OP_RETURN max size in order to prevent users from using this ugly ordinals exploit and simply use OP_RETURN.
We have already experimented with this in 2017 and the Peercoin Library project. It has worked well.
Peercoin, unlike Bitcoin does not have a fee market and the fee is burned so this makes sense. Blockchain is a database, if users want to upload monkey pictures on it why not allow them? They have to pay the fee.