Decoding the Gatekeeper Myth: Developers and Bitcoin's "Ecosystem" (Mid)
TechFlow Selected TechFlow Selected
Decoding the Gatekeeper Myth: Developers and Bitcoin's "Ecosystem" (Mid)
In this episode of the podcast, Jeffrey and Ajian dive deep into the misconceptions surrounding Bitcoin's "gas fees."
Navigating Web3 tides with focused insightsGuest: Jeffrey Hu, Head of Technology at HashKey Capital
A Jian, Senior Bitcoin Researcher and Contributor to BTC Study
Compiled by: HashKey Capital
In this episode of the podcast Hash Out 42, produced by HashKey Capital, two Bitcoin researchers delve into the complexities of Bitcoin network fees and the challenges of managing transaction volume and block size. In this chapter, Jeffrey, Head of Technology at HashKey Capital, engages in an in-depth discussion with Bitcoin researcher A Jian about common misconceptions surrounding Bitcoin's "Gas fee"—a term more appropriately applied to Ethereum’s transaction model. They emphasize that Bitcoin fees are based on transaction size rather than computational work, unlike Ethereum.
A key issue discussed is the congestion and high transaction fees caused by BRC20 tokens on the Bitcoin network. Recently, this trend has not only negatively impacted user experience but also significantly increased the UTXO set, potentially introducing uncertainty for Bitcoin’s long-term development—such as greater computational and storage demands.
The episode further explores the importance of running full nodes on the Bitcoin network. While operating a full node may offer no direct economic benefit, it plays a critical role in maintaining network integrity, resisting censorship, and enabling trustless validation of the blockchain. This is essential for safeguarding personal financial privacy and preserving the ability to conduct free transactions.
Additionally, the podcast continues analyzing the differences between soft forks and hard forks within the Bitcoin network, along with the role of miner voting in network upgrades. Using examples like BIP 148 and the SegWit upgrade, it illustrates how full node operators can exercise agency during contentious upgrades. The discussion highlights that running a full node grants users greater power and choice, contributing significantly to both network health and individual financial sovereignty.
Finally, the episode reaffirms Bitcoin’s philosophical essence. Unlike other cryptocurrencies that may cater to concepts of authority and centralized power, Bitcoin aims to limit power in order to protect individual freedom—making it uniquely positioned within the cryptocurrency landscape.
This episode of Hash Out 42 offers listeners interested in the technical and philosophical intricacies of Bitcoin a comprehensive and insightful learning opportunity.
Jeffrey Hu: We just touched upon transaction fees across the entire network, including how we determine whether a transaction gets included in a block. There was mention that gas might be relatively high. Lately, there's been a claim circulating that BRC20 has severely congested the Bitcoin network, causing Bitcoin's "gas fees" to skyrocket—upsetting developers and purists alike, possibly prompting actions like those we've discussed. Let me start here because this particular phrasing really raises my blood pressure. First off, the idea of “Bitcoin gas fee” is fundamentally incorrect—not just a minor terminology quirk. Bitcoin simply does not have a concept called Gas Fee. You can call it transaction fee, or just fee; any of these terms work. But using the word “gas” isn’t merely a naming confusion—it reflects a deeper misunderstanding, especially when compared to Ethereum. As A Jian mentioned earlier, Ethereum prices computation and even some storage usage in units of gas. On Bitcoin, however, fees are strictly determined by transaction size: how much on-chain footprint your transaction leaves, specifically its byte size when packed into a block. These are vastly different models. So I hope people understand that referring to Bitcoin fees as “gas” represents a significant misconception.
That said, there’s another widespread misunderstanding worth addressing—the belief that BRC20 has caused network congestion or high fees. It's true this reflects recent observable facts: blocks have grown larger, fees have spiked, and some users face difficulties transacting, which certainly harms user experience. However, from my perspective, what matters more—especially compared to traditional Bitcoin developer conservatism—is the dramatic growth of the UTXO set. That’s where the real trouble lies. Regarding block size increases, even if early this year an inscription led to a 4MB block that shocked many, I still see this as being within reasonable technical expectations. When SegWit activated via soft fork, such scenarios were already foreseeable—technically speaking, every future block could theoretically reach 4MB under extreme conditions. Similarly, situations involving large volumes of transactions filling up the mempool and driving up fees were also predictable.
But one thing wasn’t anticipated: the explosive growth of the UTXO set. To use the analogy I mentioned earlier—if normally you deposit money at a bank in $100 bills, operations run smoothly. But imagine instead distributing millions of pennies per transaction—that would place enormous strain on accounting and tracking systems going forward.
This seems to be something original developers didn't foresee, nor did they expect the UTXO set to grow so rapidly this year. From data I’ve seen, the UTXO set has nearly doubled since the beginning of the year. I wonder if A Jian has seen similar numbers or could clarify?
A Jian: A friend once shared some data with me on this topic, and today I updated it. Around April 21st this year, the Bitcoin network’s UTXO set contained approximately 86 million UTXOs, taking up about 5 GB. By November 25th—just over a month ago—it had grown to 140 million UTXOs, occupying 8.74 GB. So yes, correct—the UTXO set has roughly doubled since last year-end. Some listeners may not fully grasp why the UTXO set matters. Let me explain: Blockchain records all past transactions. This forms what we call blockchain data, which naturally grows over time. For example, the full Bitcoin blockchain now exceeds 500 GB, increasing slightly with each new block.
However, another crucial component exists: after processing all transactions on the chain, we arrive at a current state. On Bitcoin, this state is represented by the UTXO set. It shows all unspent outputs—how much bitcoin each holds and under what spending conditions. In short, the UTXO set captures exactly who can spend how much and under what rules, reflecting the cumulative result of all prior Bitcoin transactions.
Every time a new block appears, nodes perform two main tasks: download and store the block data locally, then validate each transaction within it. To validate transactions, nodes must check which previous UTXOs are being spent and create new ones. This process involves retrieving existing UTXOs, verifying provided credentials (signatures, etc.), checking compliance with spending conditions, and ensuring no inflation occurs—confirming validity. Crucially, validating requires searching through the UTXO set to find relevant entries, compute results, and update the state accordingly. Therefore, UTXO set bloat directly increases disk I/O overhead for nodes.
Searching through a massive UTXO set to locate specific outputs for processing consumes far more disk resources than simply storing raw block data. This is precisely why everyone pays close attention to state size growth. Some listeners may recall discussions around Ethereum’s “state explosion” or “state bloat”—this is the exact same issue. On Ethereum, each block contains transactions whose execution updates the global state: account balances, contract code, and internal states. Without knowing the latest state, you cannot verify subsequent blocks.
Bitcoin works similarly: without the most up-to-date UTXO set, you cannot validate the next block. Thus, disk resource consumption becomes a major operational cost for running a full node and continuing to independently verify the network. This is why I’m particularly concerned about recent developments.
Relatively speaking, a 3MB inscription doesn’t worry me too much. But phenomena like BRC20—and newer token issuance mechanisms we’re seeing now—I hesitate to even call them protocols, as that term feels extremely generous. As I’ve said elsewhere, their security assumptions are highly questionable. Regardless, BRC20 minting has objectively inflated the UTXO set. Other projects attempt to embed data by disguising it as digital signatures inside transaction outputs—practices that worsen UTXO bloat. This is actually worse than merely stuffing data onto the chain.
I feel deeply troubled lately—particularly over the past month and a half—because it seems we lack basic consensus or respect. Imagine visiting a public square filled with flower beds. Even without signs saying “Keep Off” or “Protect the Grass,” refraining from trampling them should reflect basic civic self-discipline.
Even if no rule explicitly forbids entry, shouldn’t you consider the impact of your actions? Why do so many seem indifferent? I suspect a core reason is that most people don’t run their own full nodes. They remain completely unaware of the underlying infrastructure and others’ contributions supporting the services they use. This awareness matters—if you knew your convenience relied on others’ effort, you might act more responsibly. But given today’s speculative, bubble-driven market environment, such appeals likely fall on deaf ears. It’s frustrating.
Jeffrey Hu: Actually, I recently heard another argument: why do inscriptions seem like a technological improvement over older methods like OP_RETURN? Developers weren’t as upset about OP_RETURN because Luke originally treated it as a bug, allowing more data to be written than previously possible with OP_RETURN-like techniques. Hence, less opposition. But based on what A Jian just explained, I think the real issue isn’t about data capacity. Rather, the mechanisms behind OP_RETURN versus current inscriptions differ fundamentally. Yes, OP_RETURN can carry substantial data and has been used to issue or transfer custom tokens. But there’s a critical difference: OP_RETURN outputs do not persist in the UTXO set.
The name itself reveals its function: when script execution reaches OP_RETURN, it immediately terminates—like returning from a subroutine in programming. Execution stops before completion, rendering the output permanently unspendable. Since it cannot be spent, it technically doesn’t qualify as a UTXO (Unspent Transaction Output). Consequently, later node implementations optimized away storing OP_RETURN outputs in the UTXO set altogether. This optimization—or modification—means such outputs impose no additional burden on nodes or the network. That’s why, in my view, OP_RETURN tends to generate less controversy and places lower stress on system performance.
A Jian: True. In fact, OP_RETURN-based approaches are largely interchangeable with current inscription methods for many purposes. Of course, ordinal NFT enthusiasts want to write complete media files to the chain in one go—a legitimate use case we won’t dispute here. But again, the crux isn’t merely about writing data on-chain; it’s about the impact on the UTXO set. Even if BRC20 switched to using OP_RETURN for data embedding, it wouldn’t solve UTXO inflation. The root problem remains: people adopted a flawed off-chain smart contract system. Honestly, BRC20 users arguably *should* switch to OP_RETURN—their current spending mechanism is economically inefficient, requiring two separate transactions to move funds. Switching to OP_RETURN could reduce costs significantly.
But anyway, the fundamental issue lies in adopting poor design patterns for layer-2 smart contracts. Interestingly, the creator of ordinals—who proposed tracking individual satoshis as a foundation for off-chain logic—is now launching a new fungible token protocol that fully tracks UTXOs. If widely adopted, such designs would avoid the problems created by BRC20. That would align better with community expectations. But judging from today’s landscape, I doubt we’ll see meaningful adoption anytime soon. The situation is dire.
Jeffrey Hu: Let’s shift to another misconception or myth: although A Jian emphasized running full nodes, many believe doing so serves little purpose beyond speeding up inscription minting or BRC20 transactions. Otherwise, they assume miners ultimately decide everything. So what’s the real significance of running a full node? Why should individuals care? Many fail to realize its importance. Just yesterday, I read an article claiming Bitcoin differs from Ethereum in that neither developers nor anyone else holds decisive power—code upgrades require miner voting. Even if developers push for upgrades, miners retain the right to refuse, fork, or block changes. What are your thoughts on this, A Jian?
A Jian: Earlier, Jeffrey mentioned soft forks vs. hard forks—backward-compatible vs. non-compatible upgrades. But let me step back. I want to remind all listeners: regardless of how we label them, upgrading a major cryptocurrency project like Bitcoin or Ethereum carries immense risk and difficulty. It involves extensive pre-coordination: defining upgrade content, aligning stakeholders, gathering input, and achieving synchronized activation across the network—meaning broad agreement to enforce new consensus rules or enable new features. This entire process is highly complex, energy-intensive, and inherently risky. Past success with forks doesn’t eliminate future risks—this applies universally to all major crypto projects.
Now focusing on Bitcoin: yes, miner voting plays a role in consensus upgrades. Major upgrades like SegWit and Taproot both involved miner signaling processes. But does that mean individual node operators are passive recipients—merely accepting proposals from developers or outcomes dictated by miners? No, absolutely not. Consider the SegWit upgrade. Technically, SegWit had been discussed since at least 2011—as noted in the third edition of Mastering Bitcoin. Yet actual activation didn’t occur until 2017. Between roughly 2015 and 2017, intense debates—even outright conflicts—erupted among developers, miners, and user groups.
One pivotal moment involved BIP 148—I forget the exact number, but likely BIP 148. Its proposal was simple: implement a client that enforces SegWit activation starting June 1st by rejecting any blocks not signaling readiness. Normally, SegWit activation relies on soft fork mechanics: miners signal support via a dedicated bit in their mined blocks. During a difficulty adjustment period (~2016 blocks), if sufficient miners (e.g., 80%) signal support, activation proceeds network-wide.
Initially, many miners—especially mining pools—adopted a wait-and-see attitude: “If others don’t commit, why should I?” They assumed their individual participation made no difference. But BIP 148 changed the game: any node running compliant software would automatically reject non-signaling blocks. If enough users adopted BIP 148 clients, miners refusing to signal would effectively be excluded—only blocks supporting SegWit would form the accepted chain. This created strong incentives for miner cooperation.
It was a vivid demonstration of what full node operators can achieve during contentious upgrades. Naturally, BIP 148 sparked debate: some supported it as necessary pressure; others criticized it for increasing network split risks. Ultimately, BIP 148 wasn’t widely adopted—but the episode proved that full nodes aren’t passive endpoints waiting for top-down decisions. As a node operator, you can actively influence outcomes, albeit with limitations. Such actions may carry aggression and threaten consensus stability, but they undeniably expand your agency beyond mere acceptance.
Let me add several points. Running a full node historically brought no clear economic reward to individuals. Recently—over the past six to twelve months—some users claim faster transaction propagation gives them advantages, sometimes translating into tangible gains. But this hasn’t been true for most of Bitcoin’s history. Yet we still rely on a decentralized network of full nodes to uphold core properties: resistance to censorship, trustless verification of the ledger, confidence in received payments, protection of financial privacy (preventing blockchain analysts from linking transactions to your IP or location), and low barriers to mining entry—an often overlooked point.
Imagine a world where only three nodes exist—all controlled by major miners. As a small miner, you’d stand no chance: they could withhold transactions from you, denying you fee income and making economic competition impossible. Full node accessibility thus supports fair mining access. That’s why developers continuously improve software efficiency, strengthen node protection rules, monitor behaviors that inflate blockchain or UTXO sizes, and strive to preserve full node feasibility—ensuring Bitcoin’s long-term viability and value retention.
So while running a full node rarely yields direct profit, it protects your financial privacy, enables trustless validation, prevents counterfeit bitcoin receipt, and contributes to the network—helping propagate transactions and blocks, accelerating validation, and lowering entry barriers for new miners. All valuable, yet unrewarded. And that’s exactly why we care so deeply about issues like today’s discussion: Will inscriptions cause unsustainable bloat? Are BRC20s beneficial or harmful? Clearly, if they only inflate the UTXO set, they’re doing harm.
Jeffrey Hu: Exactly. These elements are tightly interwoven—one change affects others. That’s my take. I’d like to add something: recently, I co-hosted a reading group with Yuance Lane for the third edition of Mastering Bitcoin. While reading, I realized early chapters challenged some long-held beliefs—particularly about full nodes. Like many, I used to think a Full Node meant a node storing the complete ledger. After all, “full” implies completeness. But the book clearly defines Full Node as Full Verification Node—hence the abbreviation.
In other words, it’s not just about passively storing data, but actively verifying all relevant transactions in full. This dramatically enhances personal fund security. By contrast, lightweight nodes (or light clients) request block headers from full nodes, fetch relevant transactions, and perform partial checks. But as A Jian noted, this introduces privacy risks. Full nodes might censor or selectively omit transactions. Worse, by analyzing your query patterns, they could link your activities into detailed user profiles—posing risks to your funds and transaction behavior.
Lightweight nodes also face censorship and filtering concerns. Suppose you want to send a BRC20 transaction, but the full node you rely on doesn’t support it. Solution? Run your own full node. Whether this motivates people today remains unclear, but it’s undoubtedly a benefit: no one can stop you from participating unless the network itself becomes prohibitively expensive to run. That’s my takeaway.
One final note regarding miners: due to their high hash power, people assume miners dominate the network. Another misconception involves 51% attacks—believing miners can then do anything. Not quite. Double-spending, for instance, only lets you reverse your own payments. Say I pay A Jian, then reorganize the chain to redirect those funds elsewhere. That alters only my transaction history—not the entire ledger. Rewriting arbitrary historical data would constitute a hard fork, not a double-spend. So contrary to myths, having >51% hash power doesn’t grant omnipotence, nor does 30% selfish mining guarantee control. Reality is far more constrained.
Alright, that concludes our expanded discussion on the meaning and value of running full nodes.
A Jian: One last point—one that might offend some. I know certain friends deeply internalize a reverence for power: the belief that strength justifies action, that power commands obedience or fear. This mindset prevails in much of human society. But Bitcoin is not built on worship of power. Quite the opposite: Bitcoin was conceived to *limit* power—to constrain all forms of authority—in service of preserving individual freedom. Bitcoin software wasn’t created to empower elites or concentrate influence. Its core philosophy resists the notion that “might makes right.”
This is precisely what makes Bitcoin precious. Not all cryptocurrencies share this ideal. Some openly embrace power worship—whether in the form of dominant entities or charismatic leaders. They don’t seek to limit extraordinary influence. Bitcoin does. It aims to eliminate single points of failure, resist censorship, and allow every full node to verify the blockchain at minimal cost—protecting financial privacy and ensuring freedom to transact. It seeks to defend personal property rights and individual ownership of wealth.
If you believe power entitles you to do anything, you’ll never truly appreciate Bitcoin. To you, Bitcoin may seem merely a tool for rapid wealth accumulation—and the power wealth brings. That may be a temporary side effect in certain historical moments. But in the hearts of Bitcoiners—those building and sustaining it—the envisioned world is nothing like that.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
