The reason the financial system is the way it is comes down to greed. Satoshi showed a fairer system is possible. Many voices in Bitcoin lost that vision. Even if it stays small but decentralized, the vision survives. Anyone centralizing it to accumulate more is acting in self-interest. Don’t trust them.

UPS-backed node and internet router. Running self-sovereign Bitcoin with my own Lightning node, managing channels, and ~1 PH of rented hashrate pointed to my node. That’s how Bitcoin stays decentralized.

Renting hashrate and pointing it to your own node feels right. Glad to contribute to more decentralized mining.

In my opinion, Adam Back has lost a lot of credibility. First, he was involved with Epstein, and now I’m hearing more and more about Blockstream actively working on smart contracts on sidechains, with long-term plans to potentially expand this technology to Bitcoin Onchain. This makes me question his motivations. I no longer trust that his opinions are purely based on what is best for Bitcoin. It increasingly seems that his views may be influenced by business interests, pushing additional use cases on Bitcoin through Blockstream and promoting his treasury company, even if those use cases may not actually benefit Bitcoin as money.

Many of the possibilities that are now used for spam were introduced with Taproot, with the promise that they would improve Bitcoin as a payment network. For a long time the argument was that these use cases simply needed time to develop. Now more than four years have passed and Taproot is still barely used for payments. It had enough time to prove its value. What we see instead is that a significant portion of blockspace is used for things that have little to do with Bitcoin as money, or a payment network. The issue is that Bitcoin evolves through consensus. Bitcoin ultimately becomes what its users use it for. If more activity revolves around NFTs, smart contracts, DeFi, or similar applications, the incentives around Bitcoin will inevitably shift in that direction. Bitcoin is built on trade-offs. Decentralization and scaling cannot both be maximized. Other applications have very different trade-offs than Bitcoin as decentralized money and a store of value. Once those use cases become large within the network, they also gain influence over its future direction. At that point it becomes much harder to steer Bitcoin back toward its role as money. If a large share of blockspace is already used for other purposes, that shift has already begun. That is the risk I see, and why I support moving Bitcoin back toward being primarily a store of value and payment network.

I see the problem that v30 is trying to address, but I completely disagree with the solution they chose. The concern is understandable: if users can bypass node relay rules by sending large OP_RETURN transactions directly to miners, that creates centralization pressure. Miners could start offering private submission channels for large data transactions. Over time, that weakens the public mempool and gives mining pools more gatekeeping power. After recognizing this issue, Core likely looked at different ways to handle it. In the end, they decided to align relay policy with consensus and completely remove the OP_RETURN size limit at the policy level. The idea was straightforward: if the standard relay path allows what consensus already allows, there is no incentive to route transactions around the network. Up to that point, I can follow the reasoning. But that is not the only possible solution. Why not go in the opposite direction? Instead of loosening relay rules, why not tighten consensus to 80 bytes? That would have: • Closed the bypass vector completely • Removed the incentive for direct miner submission • Kept the attack surface smaller • Avoided normalizing larger data embedding • Reduced legal and reputational risks • Made large-scale spam more expensive, since it would need to be split into multiple transactions In short, instead of expanding what is permitted at the policy layer, consensus could have been made stricter. So the real question is: Why was this option not seriously debated? Were there strong technical reasons against it, or was it simply not the direction they wanted to take?

Most nodes oppose the change in v30. Most nodes also oppose the change proposed in BIP110. So why not roll back both and slow down? Take the time to develop serious solutions. Let different teams propose different approaches. Evaluate them openly. Test them thoroughly. Compare the trade-offs honestly. Then, in one or two years, decide which path truly makes sense for Bitcoin. As long as Core refuses to reverse its change, I feel pushed toward supporting the fork. We clearly have a spam problem and spam harms Bitcoin in multiple ways. Ignoring it is not a strategy. Pretending it has no meaningful impact is the wrong approach. If the change were rolled back, I would be willing to give the process more time. I do not see this as an immediate emergency. But failing to address the issue and signaling that spam will simply be tolerated will only accelerate the problem. That is not a direction Bitcoin should move toward.

Thanks for the podcast. I agree with almost everything. One more specific point I would add: every additional development on Bitcoin increases complexity and with it the risk of errors. Each new layer makes us more dependent on developers, on how they interpret the code, and how they assess trade-offs. The more complex the system becomes, the harder it is for the network as a whole to evaluate changes and make sound decisions. At the same time, the attack surface grows, both technically and socially. Greater dependency also increases the risk of capture or undue influence. In that sense, a simple and clearly defined protocol is not stagnation. It is protection.

Fountain: Podcasts & Music

The Bitcoin Infinity Show • BIP-110 and the Fight for Bitcoin's Future with Hodlonaut | Bitcoin Infinity Show #191 • Watch on Fountain

Hodlonaut joins the Bitcoin Infinity Show to talk about his controversial decision to first support and then withdraw support for BIP-110, the prop...

View quoted note →