The Impact of OP_RETURN Fill on Bitcoin Network Fees

[greysonz]

I can put any information in the op_return field of a Bitcoin transaction. Will the fee be different for these transactions? I mean, with a completely filled op_return field and with a completely empty one?

[Cookdata]

I can put any information in the op_return field of a Bitcoin transaction. Will the fee be different for these transactions? I mean, with a completely filled op_return field and with a completely empty one?

Yes. The fees will be different. An op_return transaction with 70 bytes of arbitrary data wiis not the same with 2000 bytes arbitrary data. The fee rate also determines the total fees for the transaction, you can decide to pay 2 sats/vbyte for each transaction and another person can decide to use 5 sats/vbyte. You with lower fee rate will pay small fee compare to higher sats.

[Zaguru12]

Will the fee be different for these transactions? I mean, with a completely filled op_return field and with a completely empty one?

It should be different because transactions fees are calculated based transaction size and without OP_RETURN field filled the transaction will will simply have the standard input and output data which will pay a minimum fee compared to same transaction with an inclusion of OP_RETURN. Each bytes adds to the transaction data so for a completely filled OP_RETURN filed it means the block is totally filled to 4MB for Segwit and 1MB for non Segwit since the limit for OP codes were removed from v30.0 Bitcoin Core and it can take any limit until the standard block weight limit

So let’s say you want to pay the same fee rate for both transactions (with the standard input and output of the transaction are the same) then a filled OP_Return filed will be more expensive in fees than an empty filed

[Accardo]

Fee rate relies so much on block space demand, regardless of Op return, payment or inscription, bitcoin transactions are not treated differently, the simple goal of every transacting on the blockchain is to hit a block space, basing on how much you're willing to pay for a fee. For the fact block space is limited, getting your transaction included is based on how much you're willing to bid in fees. Take for instance when demand for a block space increases, fee rate increases for every transaction including; normal payments with no Op return or inscriptions. However, in most occurrences as per increased demand in block space, transaction meant for only payment, pay less absolute fees than transactions with Op-return.

[Cookdata]

IEach bytes adds to the transaction data so for a completely filled OP_RETURN filed it means the block is totally filled to 4MB for Segwit and 1MB for non Segwit since the limit for OP codes were removed from v30.0 Bitcoin Core and it can take any limit until the standard block weight limit

I think you are mixing the segwit block increased with op_return relay policy. The segwit was years ago, the op_return relay policy increased the data carrier size from 83 bytes to 100kb when they released the Bitcoincore v30.0 which was last year and it's not a standard, it's a policy rule but you can increase it to any amount within the range of 0- 100kb. You can even disable it if you want.

[Zaguru12]

I think you are mixing the segwit block increased with op_return relay policy. The segwit was years ago, the op_return relay policy increased the data carrier size from 83 bytes to 100kb when they released the Bitcoincore v30.0 which was last year and it's not a standard, it's a policy rule but you can increase it to any amount within the range of 0- 100kb. You can even disable it if you want.

As far as I know there is no consensus limit restrictions for OP Return other than the overall block weight limits which is the only reason I stated the 4MB for Segwit and 1MB for non Segwit as the block weight limits.

The bitcoin core v30.0 policy is within the standardness rule which was earlier proposed to remove the earlier 83kb limit and it’s the rule that has it at currently 100kb AFAIK but no consensus limit restrictions.

[nc50lc]

I can put any information in the op_return field of a Bitcoin transaction. Will the fee be different for these transactions? I mean, with a completely filled op_return field and with a completely empty one?

Yes of course, OP_RETURN outputs count towards your overall transaction's size, thus can affect its absolute fee.

It's basic math, BTW:
Transaction's size, e.g.: 1000vB x fee rate, e.g.: 2sat/vB = 2000 satoshi fee.
Without an OP_RETURN output, the size should be lower like 130vB x 2sat/vB = 260 satoshi fee.

And your wallet should show you its calculated absolute fee based from the transaction's vSize and fee rate.
To be specific, tell which wallet are you using to send OP_RETURN?
Because most of those allow viewing the transaction before broadcasting.

[ABCbits]

Each bytes adds to the transaction data so for a completely filled OP_RETURN filed it means the block is totally filled to 4MB for Segwit and 1MB for non Segwit since the limit for OP codes were removed from v30.0 Bitcoin Core and it can take any limit until the standard block weight limit

OP_RETURN output isn't counted as witness data. So even if someone can get miner to include their TX that bypass default relay rule and standardness, the size of arbitary data on the OP_RETURN output is close to 1MB (not 4MB).

[cambio]

Yes, the total fee will be different. Bitcoin transaction fees are calculated based on the data size of the transaction in virtual bytes (vbytes), not the monetary value being transferred.

Every byte of data you add to the OP_RETURN output increases the total size of your transaction. An OP_RETURN output holding maximum permitted data makes the transaction larger than one with minimal or empty data. Because miners prioritize transactions based on fee rate (satoshis per vbyte), a larger transaction requires a higher total fee to achieve the same confirmation priority as a smaller one.