Unlimited NULL_DATA max size

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.

1 Like

I think it’s a bad idea for multitude of reasons, first of all current transaction fees are way too low to be a reasonable deterrent to flooding peercoin blockchain with junk that at best would be useless and at worst a criminal offense.

increase of blockchain size and rate of its increase will inevitably lead to reduction of users who would be able to run a full node and provide security to proof of stake consensus increasing centralization and reducing proof of stake difficulty.

i am generally against storing any data on blockchain itself, there’s simply no need, just store ipfs hash and be done with it. blockchain is replicated to every node forever and it’s one thing to store an url or ipfs hash to questionable content, but totally different when whole content is stored and redistributed as part of immutable blockchain.

just think this through, please.


i agree with you, but storage cost is very cheap. i don’t think large blockchain size could be issue.
There should be function to run QT WALLET with filtering this NFT data…

we have minters who run very low powered nodes, like raspberry pi of first generation.

you can’t filter this data and remain a full node. you won’t be able to create blocks with partial information.

1 Like

You have missed my point, 4MB blocks are coming anyway thanks to ordinals. Storing data in OP_RETURN outputs is far more civilized.

1 Like

you seem to think that storing data in addresses is the same as storing the data as a single blob in op_return.

Since the blockchain is best suited for verifying authenticity and as a “single point of truth”, it only requires verifiable hashes of the data. Provided that the data is made available off-chain it can always be verified by the chain hash. I agree that IPFS or other similar storage networks provide a good solution for storing the actual data and that on-chain storage should be discouraged in favour of these alternatives. The blockchain should only be used minimally for verification.


I would advocate, we launch/issue data token for storing blockchain data hosting on separate blockchain but that contain linked to Peercoin hash. Data token can be used for next levels of dapps like social media, NFT, GENOME data etc…
total wikipedia is about 21.23 GB…
If we have own own space then no one can censor us. just like how wikipedia is censoring us on their domain…

Ordinals is a standard for Taproot chains now. People will use it on Peercoin. No one will make a new NFT standard based on OP_RETURN. Luckily Peercoin does not have the witness discount.

This clusterfuck is exactly why I pushed for using the code from Bitcoin Cash instead.

Personally I think we should make a consensus rule that limit Taproot inputs to 100kB.

1 Like


1 Like