🟠 Bitcoin’s Data Problem — Simple Timeline 2009 — Bitcoin launches 💰 Bitcoin is designed primarily to move and record money. People soon discover they can also hide other data inside transactions. 2014 — OP_RETURN 📝 Bitcoin Core introduces a cleaner, less harmful way to handle small amounts of extra data that people were already putting into Bitcoin. The default limit eventually settles around 80 bytes. Bitcoin Core explicitly says storing arbitrary data in the blockchain is a bad idea. 2017 — SegWit 🔧 The Bitcoin network adopts SegWit. It solves real Bitcoin problems, but also gives witness data cheaper block space. That later becomes useful for storing arbitrary data. 2021 — Taproot 🔧 The Bitcoin network adopts Taproot. It improves Bitcoin’s transaction capabilities. But combined with witness data, it also opens a much easier path for storing large amounts of arbitrary data. 2023 — Ordinals 🖼️ People use that path to put pictures and other large data directly onto Bitcoin. A theoretical capability has become a real-world use. Some developers argue it should be restricted. Bitcoin Core does not close it. ⚠️ Governance Concern Bitcoin Core is not Bitcoin, but it is enormously influential. Fewer than 50 people regularly contribute code, and the top 15 contributors produce about 71% of it. Much of this small developer community receives funding from outside organizations. That does not prove malicious influence. But concentrated development + concentrated funding creates a legitimate capture/conflict-of-interest risk worth watching. 2025 — Philosophical Shift? ⚠️ Bitcoin’s foundational documents describe it as peer-to-peer electronic cash. During the OP_RETURN controversy, Bitcoin Core contributors instead emphasize that Bitcoin is defined by its users and can be used for non-financial purposes they may disagree with. Critics see this as a shift from protecting Bitcoin’s monetary purpose toward neutrality about how Bitcoin block space is used. 2025 — Bitcoin Core Version 30.0 🚪 Instead of making arbitrary-data policy tighter, Bitcoin Core goes the other direction. The default OP_RETURN limit jumps from about 83 bytes → 100,000 bytes, effectively removing the old OP_RETURN-specific limit. Bitcoin Core’s basic argument: “People can put the data elsewhere anyway.” But real life says friction matters 🚬 Higher cigarette prices → less smoking 🛍️ Bag fees → fewer bags 🚗 Tolls → less driving Some people find workarounds, but friction still reduces usage. Making something easier generally encourages more of it. Conclusion: Bitcoin probably cannot eliminate arbitrary data, but developers should continue looking for safe ways to discourage it rather than making arbitrary-data storage easier simply because it cannot be completely stopped. The old OP_RETURN restriction created useful friction. Bitcoin Core version 30.0 removed much of that friction. A defensible policy is: Keep OP_RETURN restrictive. Don’t make non-monetary data storage easier simply because determined users can find workarounds. 2025–26 — BIP-110 🛡️ BIP-110 proposes going much further by changing Bitcoin’s consensus rules to restrict several methods of storing large data. This is a separate issue, and it is not established that BIP-110’s benefits outweigh the risks of changing Bitcoin’s consensus rules.