Spyware is valid software and we normally use antimalware to protect ourselves from them.

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.

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.

This argument again and again...

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

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.

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.

Make it a great payment system again 😉

if they're paying the fees then they're valid transactions my friend, stop censoring bitcoin users for your own ideologies

PSA: “Inscriptions” are exploiting a vulnerability in #Bitcoin Core to spam the blockchain. Bitcoin Core has, since 2013, allowed users to set a limit on the size of extra data in transactions they relay or mine (`-datacarriersize`). By obfuscating their data as program code, Inscriptions bypass this limit.

This bug was recently fixed in Bitcoin Knots v25.1. It took longer than usual due to my workflow being severely disrupted at the end of last year (v24 was skipped entirely).

Bitcoin Core is still vulnerable in the upcoming v26 release. I can only hope it will finally get fixed before v27 next year.

Who did this

What do you think about working social security systems like in Austria? Also socialism?

Agree. But where is libertarianism working? Well, let’s see about Argentina. This could be a good case study

Which one?

Libertarianism sounds beautiful and perfect in theory. Just as socialism sounds beautiful and perfect in theory.

Many relays are down. Why is that?

Tag 4️⃣des Einundzwanzig Kalenders🎄

In diesem Türchen gibt es 24h Hashrate zu gewinnen. Die Hashrate kommt von einem S9, der mit 420W läuft (ca 5 THs) und wird von der BTC-Solo-Mining Gruppe zur Verfügung gestellt.

Es wird nur eine BTC Adresse benötigt.

Die Hashrate muss für Solo-Mining verwendet werden, die BTC-Solo-Mining Community steht für Fragen rund um Solo-Mining immer zur Verfügung.