My take on this extra data is unconventional. To me, the inscription garbage is just an extreme form of monetarily inefficient transactions.

#Bitcoin rewards monetary efficiency. The smaller you can make your transaction, the less it’s going to cost you. The larger your transaction, the more it costs in sats/vByte. This pressures users to adopt space-saving features, such as SegWit or Taproot.

Even so, some people choose less space-efficient formats because they value it for some reason. For example, multisig transactions are less space-efficient than single-sig. Those extra signatures take space. Multisig enjoyers are willing to pay the additional cost because they value the multisig feature.

But value is subjective. Whether multisig is “worth it” is entirely up to the individual. The way Bitcoin adjudicates these differences in preference is with the fee market. You express your desire for space-inefficient transactions by footing more of the security budget (fees to miners).

Inscriptions are merely the most extreme form of inefficient transaction. They’re still monetary transactions. Sats still moved. But they moved in a particular way that the sender assesses is worth the additional cost.

To me, there’s no *categorical* difference between legacy address transactions, single-sig SegWit, multisig, and inscriptions. They’re just differently efficient with respect to bytes and money movement.

The beauty of the Bitcoin fee market is that it rewards patience and punishes inefficiency. You can pay for scarce block space with either time or money. You can wait until the pool clears, or you can pay to be first in line.

Bitcoin is a self-regulating system that automatically ejects low-value use cases thanks to NgU. Satoshi Dice is no more because its design is no longer efficient due to the market value of block space. The same thing should happen to inscriptions in the fullness of time.

Reply to this note

Please Login to reply.

Discussion

Your first lines are not unconventional, I agree...

But you continue with arguing Bitcoin will selfregulate to enforce smallest transactions due to cost efficiency?

To argue it is up to the user what is worth transmitting on chain, and that the user should have the freedom to transmit larger transactions than minimally needed (multi sig).

But the core problem is the blockchain size is a performance aspect, just as block size is.

And the bigger the blocks I've or blockchain the less decentralized Bitcoin will become (potentially)..

So as I have learned from the blocksize war decentralized is the most important feature.

Thus we have to limit the blocksize and blockchain to a minimal but workable size.

So functional requirements (multi sig) ahould be allowed, while adding pictures is not functional (and some will disagree to that since it was very profitable to do so for a while).

So we can't surpass the need to define what is allowed/makes sense. And better error to the low side to extent it if needed.

To state Bitcoin is a self regulating system based on efficiency ignores bad actors that can spend endless money to disrupt Bitcoin ?

To be absolutely clear: I am NOT advocating for an increase in block size. I agree that that would be bad.

Releasing the OP_RETURN size limit does not increase block size. It doesn’t even change what’s valid on chain. It just means that the OP_RETURN portion of a transaction can be larger, and still transmitted by nodes before confirmation.

A person wanting to use OP_RETURNs to store data can already store as much as they want (within the block size limit of course). The consensus rules don’t place a limit on this (to my knowledge). So you could already, today, make an enormous OP_RETURN and mine it yourself, or pay a miner out-of-band (like slipstream).

The hullabaloo over the OP_RETURN limit is about node *policy*, not consensus. It is the current policy of Bitcoin core nodes not to retransmit certain valid transactions. For example, zero-fee transactions are automatically discarded as spam.

In this vein, transactions with OP_RETURNs larger than 80 bytes are dropped by Bitcoin core nodes, even though they’re legit transactions on the consensus level. The change being discussed is removing that *policy* limit.

Not increasing block size, but does increase blockchain needed to download during the sync of a node ?

Still a not wanted negative I think.

No, the block size limit is the same no matter the purpose of the bytes. Bigger OP_RETURN has no effect on data *transmission*, but it does improve data *storage* since nodes can safely drop them.