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.