I’m going to be on an ordinals panels as one of the people who is counter arguing the claim that they are good for bitcoin. I decided to brush up on the technicals on how inscriptions work. I am starting to see luke’s perspective on how it is exploiting a loophole in bitcoin’s anti-data-spam mechanisms.

## Storing data in Bitcoin, the “standard” way

The standard way you add “data” to bitcoin is by calling the OP_RETURN opcode. Bitcoin devs noticed that people were storing data (like the bitcoin whitepaper) in the utxo set via large multisig transactions. The problem with this is that this set is unprunable and could grow over time. OP_RETURN outputs on the other-hand are provably prunable and don’t add to utxo bloat.

Here’s an excerpt from the march 2014 0.9.0 release notes that talks about this:

> On OP_RETURN: There was been some confusion and misunderstanding in the community, regarding the OP_RETURN feature in 0.9 and data in the blockchain. This change is not an endorsement of storing data in the blockchain. The OP_RETURN change creates a provably-prunable output, to avoid data storage schemes – some of which were already deployed – that were storing arbitrary data such as images as forever-unspendable TX outputs, bloating bitcoin’s UTXO database.
Storing arbitrary data in the blockchain is still a bad idea; it is less costly and far more efficient to store non-currency data elsewhere.

Much of the work on bitcoin core has been focused on making sure the system continues to function in a decentralized way for its intended purpose in the presence of people trying to abuse it for things like storing data. Bitcoin core has always discouraged this, as it is not designed for storage of images and data, it is meant for moving digital coins around in cyberspace.

To help incentive-align people to not do stupid things, OP_RETURN transactions were not made non-standard, so that they are relayable by peers and miners, but with the caveat:

1. They can only push 40 bytes (later increased to 80,83, I’m guessing to support larger root merkle hashes since that is the only sane usecase for op_return)

Bitcoin also added an option called -datacarriersize which limits the total number of bytes from these outputs that you will relay or mine.

## Why inscriptions are technically an exploit

Inscriptions get around the datacarriersize limit by disguising data as bitcoin script program data via OP_PUSH inside OP_IF blocks. Ordinals do not use OP_RETURN and are not subjected to datacarriersize limits, so noderunners and miners currently have limited control over the total size of this data that they wish to relay and include in blocks. Luke’s fork of bitcoin-core has some options to fight this spam, so hopefully we will see this in core sometime soon as well.

Inscriptions are also taking advantage of features in segwit v1 (witness discount) and v2/taproot (no arbitrary script size limit). Each of these features have interesting and well-justified reasons why they were introduced.

The purpose of the witness discount was to make it cheaper to spend many outputs which helps the reduction of the utxo set size. Inscriptions took advantage of this discount to store monke jpegs disguised as bitcoin scripts. Remember, bitcoin is not for storing data, so anytime bitcoin-devs accidentally make it cheap and easy to relay data then this should be viewed as an exploit. Expect it to be fixed, or at least provide tools to noderunners for fighting this spam.

## Where do we go from here

The interesting part of this story is that people seem to attach value to images stored on the bitcoin blockchain, and they are willing to pay the fee to get it in the block, so non-ideologic miners and people who don’t care about the health and decentralization of bitcoin are happy to pay or collect the fee and move on.

Data should not get a discount, people should pay full price if they want to store data. They should just use op_return and hashes like opentimestamps or any other reasonable protocol storing data in bitcoin.

After going through this analysis I’ve come to the opinion that this is a pretty bad data-spam exploit and bitcoin devs should be working on solutions. Ideological devs like luke who actually care about the health and decentralization of the network are and I’m glad to see it.

A technical analysis of ordinal inscriptions and the history of fighting data spam in bitcoin

This is a long form article, you can read it in https://habla.news/jb55/1701876273423


From: nostr:npub15f0lnlxujj05a8cr7emhsz9cszcjalaq0su6rymvw22zuth0h9fs7cqrdx


So it’s a valid transaction! And why should we do something against valid transaction? Why is somebody right about how to use bitcoin and somebody is wrong? I don’t like Luke’s ideology against inscriptions.

Im fine when he “fixed” it in Knots, but why should we “fix” it in Core?

Let people decide, give them both implementations and see which wins


if you pay for an uber but shit in the back seat, is it a valid use of a taxi? do you expect you shit not be removed?

if you pay for dinner but graffiti the bathroom walls, is it a valid use of a restaurant? do you expect your graffiti to persist?


Most of the decisions that go into “what is a valid transaction” are based around data size, spam prevention, and performance. If we make it easier to spam then thats not a feature it’s a bug.


These days,  in  China ,Damus is blocked by the firewall of the evil CCP and can't log in to Damus, the evil CCP.
nostr:npub1sg6plzptd64u62a878hep2kev88swjh3tw00gjsfl8f237lmu63q0uf63m
nostr:npub1sg6plzptd64u62a878hep2kev88swjh3tw00gjsfl8f237lmu63q0uf63m


you are assuming that inscriptions are a feature, not a bug. devs are simply fixing bugs. there was a bug in 2010 that allowed the creation of 184 billion btc. that txn at the time was considered a valid txn but again, this was a bug in the software so devs went ahead and fixed it.

just because you can fit 20 people in a car that seats 5 doesn’t mean you should. you can go ahead, but i’d rather not.


Remember, bitcoin is not for storing data, so anytime bitcoin-devs accidentally make it cheap and easy to relay data then this should be viewed as an exploit.

"bitcoin is not for storing data, so anytime bitcoin-devs accidentally make it cheap and easy to relay data then this should be viewed as an exploit"

This is a highlight created on https://highlighter.com


Data should not get a discount, people should pay full price if they want to store data.

"Data should not get a discount, people should pay full price if they want to store data"

This is a highlight created on https://highlighter.com


This 👌🏼👌🏼👏🏼👏🏼

They want to censor free markets.. 🤣🤣🤣

Good luck to them 🤣🤣


This is a real complex problem. Like smoking/liquor/drugs, attacking it on the regulation front will eventually fail, because humans always find a way, and it will only make it more desirable.

We are better off working diligently on killing demand rather than choking supply, By educating people on how dumb the idea is, how it is eventually against their interest, etc etc.

While I personally don’t want to store this data and don’t want to continue to see it fill the blockchain with crap, and increase tx fees. I don’t think filtering/censoring either at the template level or the blockchain level is the right way forward.

Either roll back the update completely. Or put the investment in making people understand why this is dumb to do.


This argument again and again...

The 2010 bug with 93 billion BTC was also valid...


MAX_OP_RETURN_RELAY is a policy parameter in Bitcoin Core and it's set to 83, limiting what gets relayed.

For non-standard transactions, what is the maximum size for OP_RETURN? Knots clearly has a lower policy but does not reject blocks that violate its policy.


For me it’s not spam. It’s a valid use case within the current rules of bitcoin. Not to forget that I get more sats from mining.

Bitcoin has already a spam protection. It’s called transaction fee. No one can “spam” Bitcoin forever because it costs a lot of money and the outcome is zero.


But wizard pic degens don't take that route as they don't get a discount then. Or so is their excuse.


That was a hard bug because it was against the social consensus rules of bitcoin.

Today the case is different, because we don’t have a consensus that bitcoin transactions should not used for inscriptions.

Changing the limits will change exactly nothing. Most miners are profit oriented and they would extremely stupid to change bitcoin in a way they get a smaller reward.

What really happens with such an update is a soft network split. Your node no longer accepts and forwards inscriptions, but others will. This means your mempool differs from others. This can lead to problems when it comes to calculating transaction fees. Because your node doesn’t see all the high fee transactions miners see.


Do you know when/were this panel can be watched?


Hear me out: what if each jpg contained utility such as an advanced reading copy of an ebook, sold for $20 or so, which then the buyer could sell or lend to another user? If BTC can accommodate the Lightning Network, could digital collectibles, that have value that can’t be inflated, possibly be an asset thx


Don’t agree with the loose usage of the word “ideological”, but I agree with everything else. If a transaction is technically valid only because it exploits a loophole, the closing of that loophole does not equal censorship in my opinion.


The SegWit discount of 4x is arbitrary though.

Pre-SegWit nodes see SegWit transactions as anyone-can-spend "unsigned" transactions, so they don't know of signatures and the weight thereof. They do count the bytes of OP_RETURN though as it's not segregated.


I’m going to be on an ordinals panels as one of the people who is counter arguing the claim that they are good for bitcoin. I decided to brush up on the technicals on how inscriptions work. I am starting to see luke’s perspective on how it is exploiting a loophole in bitcoin’s anti-data-spam mechanisms.

## Storing data in Bitcoin, the “standard” way

The standard way you add “data” to bitcoin is by calling the OP_RETURN opcode. Bitcoin devs noticed that people were storing data (like the bitcoin whitepaper) in the utxo set via large multisig transactions. The problem with this is that this set is unprunable and could grow over time. OP_RETURN outputs on the other-hand are provably prunable and don’t add to utxo bloat.

Here’s an excerpt from the march 2014 0.9.0 release notes that talks about this:

> On OP_RETURN: There was been some confusion and misunderstanding in the community, regarding the OP_RETURN feature in 0.9 and data in the blockchain. This change is not an endorsement of storing data in the blockchain. The OP_RETURN change creates a provably-prunable output, to avoid data storage schemes – some of which were already deployed – that were storing arbitrary data such as images as forever-unspendable TX outputs, bloating bitcoin’s UTXO database.
Storing arbitrary data in the blockchain is still a bad idea; it is less costly and far more efficient to store non-currency data elsewhere.

Much of the work on bitcoin core has been focused on making sure the system continues to function in a decentralized way for its intended purpose in the presence of people trying to abuse it for things like storing data. Bitcoin core has always discouraged this, as it is not designed for storage of images and data, it is meant for moving digital coins around in cyberspace.

To help incentive-align people to not do stupid things, OP_RETURN transactions were not made non-standard, so that they are relayable by peers and miners, but with the caveat:

1. They can only push 40 bytes (later increased to 80,83, I’m guessing to support larger root merkle hashes since that is the only sane usecase for op_return)

Bitcoin also added an option called -datacarriersize which limits the total number of bytes from these outputs that you will relay or mine.

## Why inscriptions are technically an exploit

Inscriptions get around the datacarriersize limit by disguising data as bitcoin script program data via OP_PUSH inside OP_IF blocks. Ordinals do not use OP_RETURN and are not subjected to datacarriersize limits, so noderunners and miners currently have limited control over the total size of this data that they wish to relay and include in blocks. Luke’s fork of bitcoin-core has some options to fight this spam, so hopefully we will see this in core sometime soon as well.

Inscriptions are also taking advantage of features in segwit v1 (witness discount) and v2/taproot (no arbitrary script size limit). Each of these features have interesting and well-justified reasons why they were introduced.

The purpose of the witness discount was to make it cheaper to spend many outputs which helps the reduction of the utxo set size. Inscriptions took advantage of this discount to store monke jpegs disguised as bitcoin scripts. Remember, bitcoin is not for storing data, so anytime bitcoin-devs accidentally make it cheap and easy to relay data then this should be viewed as an exploit. Expect it to be fixed, or at least provide tools to noderunners for fighting this spam.

## Where do we go from here

The interesting part of this story is that people seem to attach value to images stored on the bitcoin blockchain, and they are willing to pay the fee to get it in the block, so non-ideologic miners and people who don’t care about the health and decentralization of bitcoin are happy to pay or collect the fee and move on.

Data should not get a discount, people should pay full price if they want to store data. They should just use op_return and hashes like opentimestamps or any other reasonable protocol storing data in bitcoin.

After going through this analysis I’ve come to the opinion that this is a pretty bad data-spam exploit and bitcoin devs should be working on solutions. Ideological devs like luke who actually care about the health and decentralization of the network are and I’m glad to see it.


Because that was against bitcoins socal contract which says there will never be more than 21 Million Bitcoin.

What is the social contract about inscriptions? That’s why we are discussing the topic.


So, Whirlpool and Paynym is also a bug?
https://x.com/Diverter_NoKYC/status/1732337726924448102


very good point. thank u for this


not even sure what this means but cool


I let you see it in real time, the fees are rarely staggered.

https://orangepill.ovh


It’s nearly a 10 BTC difference but okay 👌🏻

Feel free to censor transactions because you don’t like how people use bitcoin my node will never do so


It's not arbitrary, it was picked because it makes spending inputs cheaper than creating new outputs.


If we want activity to move away from Bitcoin mainchain then  we should support the development of Bitcoin sidechains.


Unrelated…. What client did you use to write this? It looks good. I need to write my longer posts like that so they don’t take up so much space.


Cool. Thank you.


Bit of a shell game post here or this has gone over my head (very possible). You’ve just stated ordinals were not the intention but have not shown how they harm bitcoin. I understand they increase fees and lower node count since the storage needs are higher and fewer people can run that cheaply. There is a claim that is not healthy for bitcoin, but we would end up there anyway only with what you call “real” transactions over time, with more adoption. And if so, is higher “real” transaction use also bad for bitcoin health? Or wouldn’t we?


From: nostr:npub1u8lnhlw5usp3t9vmpz60ejpyt649z33hu82wc2hpv6m5xdqmuxhs46turz


Great read! Thanks for the additional context on this!


> since that is the only sane usecase for op_return

What about bip47, omni and whirlpool?


Cogent explanation. Typo s/monke/monkey/


I think you should probably start preparing to get over it.


The write transaction is the right to free speech , who are you to classify something is spam or useless information, today ordinals are illegal tomorrow every transaction on btc is illegal if it does not go through some 3rd party AML rules
Right to transaction is right to free speech which is what Bitcoin is all about.


The "4x" is arbitrary. The discount in general not.

With "arbitrary" I mean there is no scientific reason why exactly this number is the correct one.


Find a solution and there will be a workaround. Best you can do is soft-fork the witness discount away.


"bitcoin a peer-to-peer electronic cash system". It's an e-cash system, not a decentralized monkey-jpeg storing system.


It isn't arbitrary, it's the smallest whole number where we cross that threshold of making inputs cheaper


❤ Ordi


⬆⬆⬆⬆⬆ This


I’m going to be on an ordinals panels as one of the people who is counter arguing the claim that they are good for bitcoin. I decided to brush up on the technicals on how inscriptions work. I am starting to see luke’s perspective on how it is exploiting a loophole in bitcoin’s anti-data-spam mechanisms.

## Storing data in Bitcoin, the “standard” way

The standard way you add “data” to bitcoin is by calling the OP_RETURN opcode. Bitcoin devs noticed that people were storing data (like the bitcoin whitepaper) in the utxo set via large multisig transactions. The problem with this is that this set is unprunable and could grow over time. OP_RETURN outputs on the other-hand are provably prunable and don’t add to utxo bloat.

Here’s an excerpt from the march 2014 0.9.0 release notes that talks about this:

> On OP_RETURN: There was been some confusion and misunderstanding in the community, regarding the OP_RETURN feature in 0.9 and data in the blockchain. This change is not an endorsement of storing data in the blockchain. The OP_RETURN change creates a provably-prunable output, to avoid data storage schemes – some of which were already deployed – that were storing arbitrary data such as images as forever-unspendable TX outputs, bloating bitcoin’s UTXO database.
Storing arbitrary data in the blockchain is still a bad idea; it is less costly and far more efficient to store non-currency data elsewhere.

Much of the work on bitcoin core has been focused on making sure the system continues to function in a decentralized way for its intended purpose in the presence of people trying to abuse it for things like storing data. Bitcoin core has always discouraged this, as it is not designed for storage of images and data, it is meant for moving digital coins around in cyberspace.

To help incentive-align people to not do stupid things, OP_RETURN transactions were not made non-standard, so that they are relayable by peers and miners, but with the caveat:

1. They can only push 40 bytes (later increased to 80,83, I’m guessing to support larger root merkle hashes since that is the only sane usecase for op_return)

Bitcoin also added an option called -datacarriersize which limits the total number of bytes from these outputs that you will relay or mine.

## Why inscriptions are technically an exploit

Inscriptions get around the datacarriersize limit by disguising data as bitcoin script program data via OP_PUSH inside OP_IF blocks. Ordinals do not use OP_RETURN and are not subjected to datacarriersize limits, so noderunners and miners currently have limited control over the total size of this data that they wish to relay and include in blocks. Luke’s fork of bitcoin-core has some options to fight this spam, so hopefully we will see this in core sometime soon as well.

Inscriptions are also taking advantage of features in segwit v1 (witness discount) and v2/taproot (no arbitrary script size limit). Each of these features have interesting and well-justified reasons why they were introduced.

The purpose of the witness discount was to make it cheaper to spend many outputs which helps the reduction of the utxo set size. Inscriptions took advantage of this discount to store monke jpegs disguised as bitcoin scripts. Remember, bitcoin is not for storing data, so anytime bitcoin-devs accidentally make it cheap and easy to relay data then this should be viewed as an exploit. Expect it to be fixed, or at least provide tools to noderunners for fighting this spam.

## Where do we go from here

The interesting part of this story is that people seem to attach value to images stored on the bitcoin blockchain, and they are willing to pay the fee to get it in the block, so non-ideologic miners and people who don’t care about the health and decentralization of bitcoin are happy to pay or collect the fee and move on.

Data should not get a discount, people should pay full price if they want to store data. They should just use op_return and hashes like opentimestamps or any other reasonable protocol storing data in bitcoin.

After going through this analysis I’ve come to the opinion that this is a pretty bad data-spam exploit and bitcoin devs should be working on solutions. Ideological devs like luke who actually care about the health and decentralization of the network are and I’m glad to see it.


So if I got this right; essentially what you’re saying is that if they want to store these jpegs, they need to pay the full price and put it in the prunable allocated space?


I think the problem is that even if we educate not to do it, it still leaves that door open to the enemies to exploit


It’s nearly a 10 BTC difference but okay 👌🏻

Feel free to censor transactions because you don’t like how people use bitcoin my node will never do so


For me it’s not spam. It’s a valid use case within the current rules of bitcoin. Not to forget that I get more sats from mining.

Bitcoin has already a spam protection. It’s called transaction fee. No one can “spam” Bitcoin forever because it costs a lot of money and the outcome is zero.


Sounds arbitrary to me. Why not use a decimal number ;)

Ok, TIL. Will read up on the details ...


You don't want to use floats for money


🤔
You and nostr:npub1utx00neqgqln72j22kej3ux7803c2k986henvvha4thuwfkper4s7r50e8 have made me reconsider some things but I’m not wholly convinced. This whole mempool vs valid block thing is mind melting as a newb.


That's why data is stored on the genesis block by satoshi himself?


Bitcoin is supposed to be a free market. I agree that data should not be discounted, then people will just pay the full price to store the BRC20 json. It's their freedom and it's good for the system. It's market economy, please don't run it with a central agent like core and like a planned economy. $luke BRC20 is on BTC now, how irony is that?


Bitcoin white paper is titled:

Bitcoin: A Peer-to-Peer Electronic Cash System

Storing pictures on blockchain is miss-use of the system

99.9% nodes want efficient use of their resources and it costs them money to buy 2Tb hdd to store pictures they do not want

I dont want to financially support people who create additional costs for me

I switched to BitcoinKnots because of that and all bitcoiners running nodes should do and do it immediatelly

Soon noded will require hdd > 1Tb and then many nodes will drop off line so inscriptions are actually a very dangerous attack on bitcoin


Genesis block cannot be mined, it must be manually created, so it's not the same thing.


asdf