Bitcoin Core vs Knots: Why Developers Are Fighting Over a Coming Change - Ep. 918
🎯 Summary
Podcast Summary: Bitcoin Core vs Knots: Why Developers Are Fighting Over a Coming Change - Ep. 918
This episode of Unchained, hosted by Laura Shin, dives deep into a significant, ongoing technical and philosophical debate within the Bitcoin development community: the conflict between the Bitcoin Core development philosophy and the approach taken by developers associated with Bitcoin Knots, primarily centered around how to handle data storage and “spam” on the blockchain.
The core of the dispute revolves around the OP_RETURN opcode, which allows arbitrary data to be embedded in Bitcoin transactions. The current policy limits this data size (around 83 bytes), a limit established in 2014 to discourage inefficient data storage while allowing necessary application metadata.
1. Focus Area
The discussion centers on Bitcoin Protocol Governance and Technical Policy, specifically the tension between spam filtration (discouraging non-payment data) and censorship resistance (allowing any valid transaction data). The immediate catalyst is the rise of data-heavy applications like Ordinals/BRC-20 tokens (image/asset spam) which utilize novel methods (like inscribing data in Taproot scripts) to bypass existing filters.
2. Key Technical Insights
- OP_RETURN vs. Inscriptions: The debate highlights the difference between data placed in the designated
OP_RETURNfield (which has a small, enforced policy limit) and data hidden in other parts of the transaction structure, such as Taproot scripts (Inscriptions), which can utilize more block space and potentially cause greater strain. - UTXO Set Bloat: A major concern raised by the Core side is that inefficient data storage methods (like older methods that created extraneous UTXOs) bloat the Unspent Transaction Output set, significantly increasing the cost and time required for nodes to sync the blockchain (IBD). While Inscriptions don’t cause UTXO bloat directly, they still consume block space and strain node resources.
- Policy vs. Consensus: The discussion clarifies that current limits on
OP_RETURNare often policy enforced by nodes, not strict consensus rules enforced by miners. This distinction is crucial when discussing how easily these limits can be bypassed by determined actors.
3. Market/Investment Angle
- Merchant Adoption Risk: The “spam” side argues that high transaction fees driven by data usage crowd out genuine payment use cases, potentially harming merchant adoption of Bitcoin and the Lightning Network.
- Layer-Two Protocols: The debate touches on how different types of data storage (including anchors for Layer-2 solutions like BitVM/Citrea) interact with the base layer, suggesting that overly restrictive filtering could inadvertently block necessary infrastructure for future scaling solutions.
- Developer Hostility as a Filter: Chris Guida suggests that historically, developer hostility toward non-payment use cases (as noted by Vitalik Buterin) has been an effective, albeit indirect, mechanism for pushing data-heavy projects onto alternative chains.
4. Notable Companies/People
- Bitcoin Core Developers: Represented by the philosophy of maintaining strict focus on Bitcoin as peer-to-peer electronic cash, prioritizing node efficiency and discouraging data storage.
- Bitcoin Knots Developers/Proponents (Chris Guida): Advocate for a more permissive stance, arguing that strict filtering risks censorship and that the current spam methods are not as destructive as claimed, or that the proposed fix (lifting the OP_RETURN limit) is worse than the disease.
- Adam Back (CEO of Blockstream): Represents the view that the proposed change by Core (lifting the OP_RETURN limit) is a pragmatic response to the reality that data is already being stored inefficiently elsewhere (Inscriptions), and making the designated field larger is less harmful than encouraging the current “worst” methods.
5. Regulatory/Policy Discussion
While not explicitly focused on government regulation, the discussion is fundamentally about self-governance and protocol policy. The conflict highlights the difficulty in achieving consensus on what constitutes acceptable use of decentralized, public infrastructure, mirroring broader debates about platform governance and acceptable content.
6. Future Implications
The outcome of this debate will significantly shape the future utility of the base Bitcoin layer. If Core’s proposal passes, it may legitimize and potentially encourage more data storage on-chain by making the designated OP_RETURN field much larger, possibly shifting Bitcoin’s perceived primary function further away from pure payments. If the Knots/anti-spam side prevails, it reinforces the hard-line stance against non-payment data, potentially forcing more complex applications onto Layer 2s or entirely different blockchains.
7. Target Audience
This episode is highly valuable for Bitcoin Core Developers, Blockchain Engineers, Protocol Architects, and Crypto Analysts who need a deep understanding of the technical trade-offs and philosophical divides influencing Bitcoin’s evolution.
🏢 Companies Mentioned
💬 Key Insights
"...when they filter for that, then suddenly the number of Knots nodes that they're connected to drops by like 90%."
"when nodes are controlling a large number of IP addresses, which would indicate that these nodes are actually one entity, sort of almost like the concept of a Sybil attack."
"It's like we all agreed in 2018 that is the max. If you want to build something that uses more than that, you need to get everyone's permission. You can't just go do it, or you're a jerk."
"Let's just not redefine Bitcoin."
"So I need to understand something... what do you think is the actual support for Knots, and how do you figure that out?"
"Well, I'm saying it's Bitcoin that decided. When we said 80 bytes is the amount of data that you can put in a transaction, that was the decision."