Can bitcoin be destroyed?
Since bitcoin’s launch in 2009, it has faced sustained attacks aimed not only at destroying it outright, but at controlling, diluting, or neutralizing its disruptive potential. Early hostility came from governments and central banks who dismissed bitcoin as a weapon for criminals while quietly studying its undeniable incentives. By 2011–2013, law enforcement crackdowns, exchange seizures, and prosecutions, most notably Silk Road, were framed as crime prevention but also served to associate bitcoin with illegitimacy in the public mind.
Banks and Wall Street initially mocked bitcoin. Major financial institutions publicly derided it while funding blockchain alternatives designed to preserve centralized control. JPMorgan, Goldman Sachs, and others alternated between calling bitcoin a fraud and quietly building exposure because they understood the threat bitcoin posed. This pattern, public skepticism paired with private adoption, has been interpreted by many as narrative warfare meant to suppress retail adoption while institutions accumulated bitcoin knowing that they would attempt to control it years later with traditional financial products.
Regulatory pressure intensified over time. Agencies such as the SEC, CFTC, Treasury, and the Federal Reserve used uncertainty, selective enforcement, and compliance burdens to slow adoption without banning bitcoin outright. De-banking campaigns, mining restrictions, and ESG-driven attacks reframed bitcoin as environmentally destructive, despite evidence of its role in energy grid stabilization.
These efforts functioned less as technical critiques and more as reputational and political pressure. Some of the most consequential attacks came from within. The 2015–2017 block size wars exposed attempts to alter bitcoin’s trajectory under the banner of “scaling.”
Funding concentration, corporate influence, and control over the Bitcoin Core developers shaped outcomes that many viewed as capture attempts rather than organic consensus. The Bitcoin Improvement Process (BIP), while nominally open, became increasingly opaque to non-developers. Critics argue that restricting block size entrenched fee markets and Layer‑2 dependencies at the cost of on-chain usability.
The current attack on bitcoin comes from within the Bitcoin Core development community. I describe that in the post below. Bitcoin persists and as proven itself to be anti-fragile up to this point in time. It has survived bans, forks, propaganda, and capture attempts without altering its core monetary properties.
The future success of bitcoin is dependent on an open and ongoing dialogue and inspection around Bitcoin Core and Bitcoin Knots' proposed changes to bitcoin policy and feature set in an effort to always favor its monetary advantage. The mantra should be to "maintain not change." Bitcoin will survive as long as it remains trustless, decentralized, secure and is finite in the number of tokens that can be issued. your text here...
The OP_Return wars.
I hesitated adding this post because it gets a bit technical and might not seem important. However, in light of an earlier post regarding man's inability to rule himself, I thought it would have some relevance. The only guarantees in life are God's prophecies and promises.
Bitcoin has undergone a number of threats over the years. Interestingly, most of them have come from within the bitcoin community; more specifically the developers who work on the open source software called Bitcoin Core. The personal interests of certain Bitcoin Core developers has needlessly expanded bitcoin's attack surface. In fact, I believe many young developers seeking to "improve" bitcoin either don't fully understand or don't care about the problem Satoshi's bitcoin solved; and this is dangerous on many levels. In fact, Michael Saylor says that the way to destroy bitcoin is to hire the best developers and tell them to make bitcoin better. Click here to hear it.
For example, the OP_RETURN Pull Request #32406 that went into effect in October 2025. This change encourages spam on the bitcoin blockchain. In other words, it invites non-monetary data to be put on the bitcoin blockchain. This is counter to what Satoshi envisioned, which was a permissionless p2p monetary system that is outside the control of any individual or entity.
This change occurred in v30 of Bitcoin Core's software and removed the 83 byte limit on data outputs and increased it to 100,000 bytes. Opponents of this change are concerned that the additional bloat to the blockchain will increase costs for nodes runners who will need more memory if they want to continue to run a full copy of the bitcoin blockchain. Years down the road this change will deter some individuals from running a node due to the high costs required. This is detrimental to individual sovereignty and hurts bitcoin's unique decentralized nature, as potentially fewer nodes will be enforcing bitcoin's rules and relaying transactions.
These naive developers have needlessly opened the door to future government attacks on bitcoin for ANY reason that government deems it valid. For example, when Bitcoin Cash split from bitcoin (called a fork), the OP_RETURN outputs were increased to the exact same limits as the change Bitcoin Core devs made in v30: 100,000 bytes. Shortly after that happened, child pornography showed up on Bitcoin Cash's blockchain. Opponents of this identical 100,000 byte increase by Bitcoin Core developers fear that child pornography and other dangerous data, like malware, will flood bitcoin's blockchain. This will give governments an excuse to shut down node runners relaying this data, or worse yet, make bitcoin illegal in certain jurisdictions.
Here are some questions that need to be asked and answered by Bitcoin Core developers and the bitcoin community:
Is the OP_RETURN change in Core v30 a solution to a problem that does not exist?
Did Bitcoin Core devs misread the bitcoin community on this issue?
Do Bitcoin Core devs know and understand what the Creature from Jekyll Island is?
Did the process Bitcoin Core devs follow create distrust among the bitcoin community?
Should changes to policy and feature set be handled differently moving forward?
Does being able to better predict what is included in a bitcoin template actually hurt miners and open the door to censorship?
Is giving miners less choice over template configurability, as a result of Bitcoin Core v30, good for miners and the overall health of the protocol?
Should Bitcoin Core devs have shilled their devotion to spam on other blockchains?
Should the market and hash rate determine what the next template should be?
Would a cleaner pre-mine mempool with an OP_RETUTN limit of 83 bytes be healthier for bitcoin's future as a decentralized monetary protocol?
Should the Bitcoin Core devs have simply done nothing regarding the OP_RETURN limits?
What, if any, current or future incentives did or will certain Bitcoin Core devs receive by giving future governments an opportunity to crack down on bitcoin for any reason because of the proliferation of offensive non-monetary content on the blockchain?
Time will tell how this all shakes out. In the meantime, I would encourage anyone who owns bitcoin to run a node and hold their bitcoin in self storage in a cold wallet that is air-gapped. The good news is that there is a bitcoin software version called Bitcoin Knots, that gives node runners the ability to configure the OP_RETURN limits to a more realistic limit of 40 to 83 bytes. It was started by Luke Dashjr.
In the next section, I have some links to resources that cover a wide range of related topics. Regarding running your own node, it is not difficult to do. Here are some more specific links on this topic:
https://www.youtube.com/watch?v=9JKpA7gqbW0
https://www.youtube.com/watch?v=QeCIVUH89KY
https://www.youtube.com/watch?v=zT4NuAaH3EM
https://www.youtube.com/watch?v=UxhSelzMcAs
https://www.youtube.com/watch?v=FZ-nD9hSaeg
The solution - Knots BIP 110.
Bitcoin Knots’ BIP-110 (“Reduced Data Temporary Softfork”) treats the recent wave of non-monetary blockchain use as a technical attack on bitcoin’s role as pristine money, and it counters it at the consensus layer, not just as a mempool/relay preference. The core idea is simple: shrink the bandwidth available for arbitrary non-monetary data, both where “inscriptions” hide it (inputs/witness) and where metadata is explicitly parked (outputs/OP_RETURN). See the proposal overview at bip110.org and the technical breakdown at Study Knots.
Ordinals/BRC-20/NFT-style inscriptions largely ride on SegWit/Taproot witness space, benefiting from witness handling and the practical “discount” that makes stuffing data there cheaper than bloating legacy transaction bytes. BIP-110 targets those vectors by making large witness-embedded payloads invalid via tight caps on data pushes and witness elements (256 bytes max), alongside Taproot-specific restrictions intended to block common inscription encodings (including limits around annex/control-block/script patterns). The result isn’t philosophical “censorship;" it’s a concrete rule change that says: if you want to store files, find another way to do it.
On the output side, BIP-110 limits new output scripts to 34 bytes, with a narrow exception: OP_RETURN can carry up to 83 bytes. This is designed to preserve ordinary payments (standard script templates fit) while preventing output scripts from becoming data containers. It also reasserts OP_RETURN’s historical purpose: small tags, commitments, references, not megabytes of arbitrary content.
In a near-future where AI agents perform high-frequency monetary transactions, bitcoin needs to remain a cheap-to-verify, cheap-to-run, hard-to-censor settlement network. Spam-driven blockspace auctions distort the fee market, crowd out real payments, and push users toward custodians, reintroducing trust, surveillance, and censorship. Worse, persistent bloat raises node costs, increases verification burden, and threatens decentralization and long-term security.
BIP-110’s premise is that less is more. Bitcoin survives by staying small, strict, and monetary, so anyone, including millions of autonomous agents, can verify and settle value without asking permission. Ultimately, you will have to come to your own conclusions about bitcoin's protocol. If you are new to bitcoin and don't fully understand the problem bitcoin solves, I would encourage you to visit this post.
