Oddbean

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 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

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.

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.

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.

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.

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.

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?

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.

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.

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.

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?

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.

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

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.