Users are unable to send large OP_RETURN transactions. Nodes will not relay large OP_RETURN transactions to other nodes.
The user will need to wait until new blocks are found and resubmit their transactions at a later time.
It is not the case that the only parameter that needs to be set is datacarriersize to fully support large OP_RETURNs, there are actually 3 other parameters that should be configured.
You can reproduce this issue and see the problem yourself by producing many transactions with > 90KB+ OP_RETURN transactions where you chain together many unconfirmed large OP_RETURN utxos. Once it reaches greater than 101 KB (See: Bitcoin SV Source), then your transaction will not propagate in the network or return an error outright.
Please note: BitIndex has correctly configured these limits, so you will not run into this problem with Datapay or Bitpipe or other services using BitIndex to broadcast transactions. However, if other nodes are not configured correctly, then you will not see your large OP_RETURNs appear in other nodes and explorers until new blocks are discovered.

Additional Details

(Feel free to skip this section and jump below to see that parameters that need to be configured)
In order to support large OP_RETURNs there are actually a total of 4 parameters to ensure your Bitcoin SV node can fully support large OP_RETURNs.
It is commonly believed that only the parameter that needs to be configured is just datacarriersize. This is adequate only for a single OP_RETURN of up to 100,000 bytes.
There are in fact there are 3 other parameters that must be configured to support larger than 100,000 bytes when transactions are chained together.
When the mempool is full of large OP_RETURNs and there are many chained transactions that are themselves large OP_RETURNs (ie: up to 100 KB in size) then the Bitcoin Node will start rejecting transactions as overflowing the built-in limits, requiring users to resubmit their transactions at a later time when blocks are found.
Without further ado, the parameter settings follow below and links to the Bitcoin SV code base to see how they are used internal to the node.


Do not accept transactions whose size with all in-mempool ancestors exceeds <n> kilobytes (default: 101 KB)
Do not accept transactions if any ancestor would have more than <n> kilobytes of in-mempool descendants (default: 101 KB)
Keep the transaction memory pool below <n> megabytes (default: 300) This must be set to at least the size of limitdescendantsize * 1000 * 40. Ex: -maxmempool=4000
Note: Incorrectly, configuring this parameter and the Bitcoin node will fail to start and log an error.
Maximum size of data in data carrier transactions we relay and mine (default: 223). Ex: -datacarriersize=100000


As we have seen above, it is not sufficient to only set datacarriersize=100000 to fully support large OP_RETURNs. This parameter controls a single transactions OP_RETURN size, but we will run into issues with multiple unconfirmed transactions are chained together and then we hit the 101KB built-in limit.
In order to fully support, increase the parameters datacarriersize, limitancestorsize, limitdescendantsize, and maxmempool to suitable values for your node.
Putting it all together: ( up to 4 GB mempool )
bitcoind -maxmempool=4000 -limitancestorsize=100000 -limitdescendantsize=100000 -datacarriersize=100000


No one has reviewed this piece of content yet