Human nature insures there will never be a time when Bitcoin does not need to be defended and fought for. Complacency is an attack vector. Eternal vigilance is the price of liberty.

We got another BIP110 block! Roughnecks never sleep 💥

My opening statement from this debate: --------------------- BIP110 is a simple statement: "we reject Core 30’s proposed addition of data storage to bitcoin." Bitcoin is money. That is the starting point. If we lose sight of that, we lose the plot. The block size war was one of the defining moments in bitcoin history because it forced bitcoiners to answer a basic question: who is bitcoin for? Is it for large companies, exchanges, miners, and professional infrastructure providers? Or is it for ordinary people: pleb merchants, individual savers, and node runners, who need to verify the system for themselves? In 2017, bitcoiners answered correctly. We rejected the bigblock roadmap because it put bitcoin on a slippery slope: whenever blocks fill up, make them bigger; when they fill up again, make them bigger again. That path leads directly to centralization. It prices out ordinary node runners, turns validation into a professional activity, and recreates the trusted intermediaries bitcoin was designed to eliminate. But the bigblockers got one thing right: bitcoin must work as a payment system. Their mistake was thinking bigger blocks were the way to get there. The real path is conservative base-layer validation, combined with trustless off-chain protocols like lightning. That is how bitcoin can scale commerce while preserving decentralization. The current conflict over data spam is part two of the block size war. Once again, the question is whether we prioritize node runners and people using bitcoin as money, or whether we allow other interests to consume scarce block space and raise the technical, economic, legal, and moral cost of running bitcoin. The worst centralization pressure here is not merely that spam makes nodes more expensive (which it does). It is that arbitrary data storage creates the possibility of deeply harmful illegal material, including CSAM, being embedded in the chain. If that happens, fully validating archival node operators could be placed in the position of storing and distributing material they find morally abhorrent. Even if the legal analysis varies by jurisdiction, the social consequence is obvious: most decent people will not voluntarily run infrastructure that forces them into that position. Node running would become limited to large institutions with legal departments, specialized infrastructure, or people with no moral objection to hosting such material. That is an extreme centralization pressure, and it attacks bitcoin’s security model directly. So the answer should be the same as it was in 2017: the protocol must protect node runners first. Pleb merchants, especially in poorer parts of the world, must be able to run nodes and conduct business without trusted intermediaries. If they cannot, bitcoin will become dominated by large corporations, custodians, and professional infrastructure providers. That is why protocol changes should be rare and careful (unlike the removal of the opreturn filter). Unless a change is necessary to make bitcoin more useful as money, or to defend bitcoin against a serious threat, the default should be caution. But caution is not ossification. Bitcoin is not a museum piece. It is a living system in a hostile environment. If we pretend the current ruleset is perfect forever, bitcoin loses the ability to adapt to new attacks, incentives, and failure modes. Ossification only makes sense if the protocol is already perfect. It is not. BIP110 addresses a real vulnerability: the possibility that the developers of the dominant node implementation adopt an ideology that turns against the user community they are supposed to serve. When the people maintaining the main implementation make it harder to run a node, harder to use bitcoin as money, and easier to treat bitcoin as generic data storage, node runners have a responsibility to respond. This problem is made worse by a small number of influential developers who appear to have an effective pocket veto over consensus changes. They can support changes that create harmful unintended consequences, and then block or stall the fixes. That is an unhealthy level of centralization in the development process. Core v30 was a breaking point. Before it, there was a delicate balance between consensus and policy: consensus was permissive enough to allow future upgrades, while policy was restrictive enough to discourage abuse. Now we are told that policy does not matter, that spam transactions should be treated like real payments, and that node runners should simply accept the consequences. That argument is not serious. Core still maintains many policy limits. Nobody actually believes every possible transaction must be relayed and mined on equal terms. The question is not whether policy matters. The question is whose interests policy serves. BIP110 is therefore a vote of no confidence in the current leadership of Bitcoin Core. Mistakes happen. But refusing to admit a mistake, refusing to fix the damage, and blocking others from fixing it is far more dangerous than the original mistake itself. One side effect of that pocket veto is the bikeshedding treadmill. Leadership quietly opposes a fix, but instead of saying what would actually earn support, the discussion becomes endless nitpicking: this opcode, that activation path, this implementation detail. At some point, “review” stops being review and becomes a strategy for delay. Ultimately, the node network does not need permission from Core leadership to defend bitcoin. Especially not when Core itself introduced or normalized the harmful behavior in question. BIP110 is on track to activate with or without their blessing. And BIP110 is not merely defensive. I am very bullish on its activation because it breaks the consensus logjam, among other things. Bitcoin needs other improvements if it is going to destroy the fiat standard. We need better payment systems. We need better custody tools. We need mechanisms like covenants, vaults, and more powerful trust-minimized point-of-sale systems. But the current process makes every consensus change feel impossible, because if any mistake is made, we are told we must live with it forever. That is not conservatism. That is paralysis. BIP110 shows that bitcoin can fix mistakes. It shows that unintended consequences from prior upgrades do not have to become permanent vulnerabilities. It shows that node runners can still act when the dominant implementation fails them. So yes, I strongly support BIP110. It reestablishes payments as the primary use case of the bitcoin blockchain. It reasserts that bitcoin is money, not arbitrary data storage. It protects node runners from being pressured into storing or distributing morally abhorrent material. It reminds everyone that node runners - not developers, not corporations, and not miners - are ultimately in control of bitcoin. And it proves that bitcoin can adapt. Not recklessly, not casually, but when necessary: to defend its decentralization, its usefulness, and its purpose. Bitcoin survives because node runners enforce the rules. BIP110 is node runners enforcing the rules. Thank you.

IMO the issue isn't whether uncapping OP_RETURN technically reduces one specific workaround. It's that Core, with that change, announces a clear philosophical shift away from the long-standing stance that Bitcoin is money first, and keep it as simple/unfuckable as possible, not lower friction for non-monetary payloads just because a grifting minority already found ways to do it anyways. The old default policy (80 bytes) was a clear signal: "this isn't a subsidized database." Changing it in v30 normalizes and standardizes non-money use in the reference implementation. That's not neutral harm reduction, it's a clear pivot. It invites more boundary-pushing, makes it easier for newcomers/grifters to justify "but Core allows it," and adds very predictable social-layer infighting (which we’re seeing right now). You say my points repeat "false narratives" debunked over 1000s of hours. That doesn’t address the philosophical shift at all. Of course that feels like handwaving and appeal to technical authority. If this shift can’t be solidly explained and justified in layman’s (pleb) terms, then that’s a red flag to me. Why not keep resisting accommodation for data embedding instead of facilitating it? The backlash against core is a good faith immune response by people who care a lot and are not talking some VC narrative. It is the voice of maxis/plebs defending the ethos that drew most of us in. Core can push changes, but the community can (and will) push back hard when it smells like erosion of first principles.

⛏️ New Ocean Block Mined ⛏️ Block Height: 952057 Fees: 0.003 BTC Subsidy Fees: 3.128 BTC Difficulty: 138.96T Solver: Barefoot Mining mempool.guide/block/00000000…