I spent three months last year auditing the Coinbase transaction validation logic for a Bitcoin Core-based wallet. I traced the exact code path that handles the first transaction in every block — the miner’s reward. That’s when I stumbled upon BIP-110. A proposal that had been sitting in the Bitcoin-dev mailing list archive since 2020, with zero activity after 2023. It’s a soft fork that aims to restrict the output format of Coinbase transactions. A restrictive change, not an expansion. In a community that prides itself on permissionless innovation, this is a paradox. Why would anyone want to limit what miners can do with their block reward? The answer lies in the trade-off between flexibility and predictability. But the real story isn’t the technical detail. It’s the fact that BIP-110 never came close to activation. It’s a tombstone in the graveyard of Bitcoin upgrades, and it tells us something uncomfortable about the state of Bitcoin governance.
Context: The BIP-110 Proposal
Bitcoin Improvement Proposal 110 was first drafted in 2016 by Luke Dashjr. It proposed a rule change to the structure of Coinbase transactions — the first transaction in each block that creates new bitcoins. Currently, miners can include arbitrary data in the Coinbase transaction’s output script. This flexibility has been used for everything from block explorers labeling to timestamping messages. But it also creates a vector for spam, blockchain bloat, and potential attacks on wallet software that assumes a standardized format. BIP-110 would enforce a set of constraints: the output script must be a standard pay-to-public-key-hash or pay-to-script-hash, with a single output. No OP_RETURN, no multi-sig, no data anchoring. The proposal is a soft fork, meaning it would restrict the set of valid blocks, making nodes that upgrade reject non-compliant blocks. The rationale is to simplify validation, reduce the surface area for bugs, and make Coinbase transactions more predictable for light clients. However, the proposal never gained traction. It remains in DRAFT status. The Bitcoin Core maintainers never merged it. The social consensus never materialized.
Core: The Technical Trade-Off Matrix
Let me break down the trade-offs using the framework I apply to every protocol change I audit. I call it the Theoretical Trade-off Matrix. For BIP-110, we have four axes: security, predictability, miner autonomy, and network efficiency.
Security: Current Coinbase transactions can contain arbitrary scripts. This is a known attack surface. For example, a malicious miner could craft a Coinbase output that exploits a bug in a wallet’s parsing logic. In my audit of a light client, I found that the code assumed a single output with a standard locking script. A non-standard Coinbase could cause a null pointer dereference. BIP-110 would eliminate that class of bugs. But it also removes the ability to use Coinbase outputs for emergency patching — for example, if a critical vulnerability required a miner to signal a message via the blockchain. The trade-off is a tighter security guarantee at the cost of a fallback mechanism.
Predictability: Wallet software, especially for hardware wallets, benefits from knowing the exact structure of the Coinbase output. If the format is standardized, they can optimize parsing and reduce code complexity. During my work on a Bitcoin Core fork for a corporate client, I spent weeks debugging a transaction indexing issue caused by a non-standard Coinbase. The fix was trivial, but the time lost was real. BIP-110 would make this a non-issue. However, the proposal’s rigidity could also make the protocol brittle. If a future need arises — say, a new type of address — the Coinbase format would need another soft fork to adapt. The trade-off is short-term simplicity versus long-term adaptability.
Miner Autonomy: This is the elephant in the room. Miners currently have the freedom to choose the output script. They can use it to signal support for a proposal, to embed a message, or to optimize their own payout structure. BIP-110 would centralize that decision to the protocol developers. Miners would lose the ability to vote with their Coinbase. This is a deeply political point. The Bitcoin community has historically valued miner autonomy as a check on developer power. By restricting that freedom, BIP-110 shifts the balance. The trade-off is that the protocol becomes more deterministic, but at the cost of a critical feedback mechanism.
Network Efficiency: Standardized Coinbase outputs could reduce the size of the blockchain marginally. But the real efficiency gain is in validation. Nodes can skip the complex script evaluation for Coinbase outputs if they know the format is fixed. This is a minor optimization, but in a network with hundreds of thousands of nodes, every millisecond matters. The trade-off is that the optimization is marginal, while the implementation risk of a soft fork is non-trivial.
Contrarian: The Blind Spot
The conventional wisdom is that BIP-110 failed because it was unnecessary. The community didn’t see a pressing need. But that’s a surface-level analysis. The real reason is that Bitcoin’s governance has ossified. Post-ETF approval, the stakeholders are no longer cypherpunks and miners; they are institutional custodians, asset managers, and corporate treasuries. These actors want one thing: stability. Any change to the base layer is a risk to their balance sheets. They will oppose any proposal that could cause a chain split, even a soft fork. BIP-110, despite being a net positive for security, was a non-starter because it required a social consensus that no longer exists. The irony is that the very success of Bitcoin — its adoption by Wall Street — has made it impossible to improve. The protocol is trapped in a amber of its own making. The market doesn’t care about your technical purity. It cares about liquidity. And liquidity demands stability. BIP-110 is a casualty of that demand.
But there is a deeper blind spot. The proposal’s failure also reveals a flaw in the BIP process itself. The BIP process is designed for technical meritocracy, but it assumes that the community can reach consensus on technical grounds. In reality, the process is now gamed by political interests. Any proposal that touches miner revenue or transaction processing is subject to intense lobbying. BIP-110, by restricting miner autonomy, was seen as a threat to the mining lobby. The same lobby that fought against SegWit’s activation. The same lobby that now benefits from the ETF status quo. The lesson is that Bitcoin’s governance is not a technical function; it’s a social contract mediated by power. Consensus is a social contract, not a mathematical proof.
Takeaway: The Vulnerability Forecast
BIP-110 is a case study in governance paralysis. The next soft fork will only happen if there is a security catastrophe — a bug that threatens the entire network’s value. Until then, Bitcoin’s protocol will remain frozen. The technical debt will accumulate. The flexibility that miners enjoy will become a liability as new attack vectors emerge. I predict that within five years, a vulnerability in Coinbase transaction handling will be exploited, causing a temporary disruption. The community will then scramble to implement a fix, but the cost in lost trust will be high. The lesson is that ossification is not a feature; it’s a slow-moving bug. Code is law, but bugs are reality. Zero-knowledge isn’t mathematics wearing a mask. It’s a governance failure waiting to happen. Bitcoin’s future upgrades will be limited to non-controversial, security-only patches. The vision of a living, evolving protocol is dead. We are now maintaining a legacy system.
