S15 E50: Murch on Bitcoin Myths, OP

If you have ever typed a Bitcoin question into a search engine, you have probably met Murch without knowing it. Mark Erhardt (I kept calling him Mark on the livestream, the rest of the world calls him Murch) has spent more than a decade as the most reliable voice on Bitcoin Stack Exchange, where the questions are technical, the answers are long, and the person typing them is usually him. By day he is an engineer at Chaincode Labs. By Tuesday he is one of the hosts of the Bitcoin Optech podcast recap. A lot of people call themselves Bitcoin educators. Murch is the one who educates the developers.

So when I wanted to do an episode about the myths that Bitcoin Twitter repeats until they sound like physics, I knew who had to sit across from me. We prepared a list of ten talking points: ordinals as spam, Bitcoin Core as a captured institution, ossification, OP_CAT, drivechains, zero-conf, tail emission and the alleged death of Bitcoin in 2140. When I told him he was the person who is always technically correct, he answered with the modesty of a man who has written close to 2,000 Stack Exchange answers: "Well, I try."

We went live on August 14, 2024, with more than 800 people on X, about 50 on YouTube and exactly one brave soul on Twitch. By the two-hour mark the live count passed 1,000. What follows compresses 143 minutes of patient myth-busting into something you can read before your coffee gets cold (or before your unconfirmed transaction gets replaced).

Ordinal Glasses and Abraham Lincoln on a Fiver

I opened with the topic that had been setting Bitcoin Twitter on fire for a year and a half: are ordinal inscriptions spam, and does Bitcoin Core's refusal to filter them mean it has been compromised? The popular answer at the time was to run Bitcoin Knots, maintained by Luke Dashjr, and point your home miner at Ocean.

Murch began with his own bias, which I respect. He is in Bitcoin for digital cash. Credit cards leak your private information with every payment and are "super surveilled", so the internet is still missing a cash equivalent. That is what got him excited, and that is the lens through which he judges every change. So no, he is not a fan of inscriptions. "I don't think that Bitcoin's built to do that," he told me. But being unexcited is different from wanting to ban something.

His explanation of ordinals was the cleanest I have heard. Ordinals are a client-side interpretation: "you put on your ordinals glasses," and suddenly UTXOs carry serial numbers and imbued meaning that the rest of the network does not see. People who wear the glasses may stick out to surveillance, but he does not see a huge impact on fungibility.

The real question, in his view, is what you would have to break to stop it. Bitcoin is censorship-resistant money with scripting, and killing inscriptions means heavily restricting one of those two properties. His verdict was surgical: it is "not a price I'm willing to pay" just to stop people from drawing "Abraham Lincoln vampire slayers on fivers." Filters would not even work, because data can always be disguised as a P2WSH output, which looks like random hash data anyway. Given the choice, he would rather people write into witness data than pollute the UTXO set.

He also had a sharp word for the activists. The critics of ordinals have been very effective, because "the squeaky wheel gets the oil." But endlessly repeating the same position is "politics and not raising concerns," and it becomes a denial of service attack on developer attention. If you still believe there is no trade-off to be made, he thinks you can spend your time more effectively.

Nobody Is in Control (and That Is the Scary Part)

The "Bitcoin Core is captured" narrative got the least sympathy of the evening. Murch called it "a popular engagement bait" that feeds a knee-jerk reaction against anything perceived as power.

The reality, as he described it, is a loosely organized group of people who agree on little besides a process for releasing software together. If about 30 people with very different views all tell you no, you can conclude you might be wrong, or you can conclude it is a conspiracy. The work is public: GitHub comments, code reviews, the IRC meeting logs, the mailing list.

Maintainers cannot merge what has not been reviewed and supported, and one who tried would be reverted and removed. There is a release every six months, a multi-week testing and reproducible build process, and then the final filter: you. "We don't even have an auto update," he reminded me. Users have to want the new version, download it and run it.

What unsettles people, he suspects, is the absence of a boss. "It's a strange and frightening thing that there's actually nobody in control," with no benevolent central authority you can lobby to fix the world.

That set up the ossification myth: the cult belief, as I put it on air, that Satoshi gave us perfect technology and everything since has been destructive. Murch admires that the original codebase was only 10,000 to 12,000 lines and implemented a working proof of concept, but there is not much of that code left. Software lives inside operating systems, drivers and libraries that keep changing.

One macOS update tweaked a driver interface and Bitcoin Core stopped starting. "We can't just write software once and then use it for the next 20 years. That'll just not work." Bitcoin also went from managing a hundred bucks to securing serious money, and Lightning brought new needs around relay and replacements. A version from before Satoshi left might still sync in theory, but it would take years to catch up to the chain tip.

He used mempool full RBF as a live example. Over 95% of blocks were already including full RBF replacements, which was hurting compact block reconstruction and slowing block relay. After two and a half years of the option existing, the default would flip in the upcoming version 28. "It's just sort of the hand that we've been dealt at this point," he said, and the release adapts to the network that exists.

(That is exactly what Bitcoin Core 28.0 later shipped, with mempoolfullrbf=1 as the default.) Right before that segment, John Carvalho popped into the YouTube chat to announce that he loves Murch "even though he will not admit he loves me." If you want John's side of the zero-conf story, it is in my S15 E23 conversation with him.

OP_CAT and Making Sailors Love the Sea

This episode was sponsored by companies on opposite sides of the soft fork horse race: LayerTwo Labs, pushing BIP 300 drivechains, and StarkWare, pushing OP_CAT so its STARK proofs could come to Bitcoin. Naturally, I asked which one Murch expects to win. Drivechains got a polite pass. "I'm just generally not that excited about altcoins," he said, and bringing all of them to Bitcoin felt like onboarding a pile of new needs and directions.

OP_CAT, on the other hand, "seems to have a lot more momentum." What fascinates him is the contrast: an extremely simple code change with wide-ranging implications that are not fully understood. He saw the BIP get merged (now BIP 347; he thinks he merged it himself, maybe someone else did), but there was no activation proposal and little comprehensive analysis.

The demos so far looked like "look what I can do" use cases, such as Lamport signatures or ZK verification in script, with enormous block space footprints. Most of the debate lived in Telegram groups and X spaces, nearly impossible to index, and he asked for it to move to the mailing list or Delving Bitcoin, where experienced protocol developers might chime in.

Then came the moment where he asked me, very politely, not to misquote him. His words: "please don't quote me as Murch says OP_CAT comes next year. I'm saying that I think the conversation is not ready for an activation client right now." Noted, Murch. Quoted correctly.

I tried my own pro-CAT arguments: Satoshi removed it, but it was rewritten in roughly a dozen lines to address the old concerns, and it already runs on Bitcoin Cash and Liquid, so anyone can try to break it with real incentives. Murch took it from the top. Covenants are not a new idea, more like a 2010 or 2011 conversation, and he dislikes the term. He prefers "transaction introspection," which makes clear that CHECKSEQUENCEVERIFY and CHECKLOCKTIMEVERIFY were already introspection opcodes. Fear of recursive covenants is mostly misguided, because the receiver always chooses the output script.

His real advice for covenant fans came via a sailing metaphor. If you want sailors to build a ship, "you make them love the sea and not ask them to cut a tree." There are around seven competing proposals, little testing activity, and no Lightning-style working prototype like the one that existed on testnet before CHECKSEQUENCEVERIFY and SegWit activated. "Maybe pick a lane," build a movement, convince people. And who decides in the end? "The CEO of Bitcoin, of course," he deadpanned, before admitting the real answer is all of us, through a rough consensus that is hard to measure and harder to fake.

Taproot's Unopened Gifts and the Thirty Times Trap

Many Bitcoiners feel cheated by soft forks, I argued. SegWit was sold as a Lightning enabler and delivered a block size increase. Taproot was sold as a privacy upgrade and delivered inscriptions. Murch pushed back on both counts. Nobody had ordinals on the radar during the five years Taproot was discussed, and Casey Rodarmor could have done inscriptions with P2WSH anyway. (Casey told me his own version back in S13 E3.) Still, seeing Taproot used mostly for inscriptions "saddens me greatly."

The good stuff simply takes longer. MuSig2 needed two more years after activation to be formalized as a BIP, and the specs for key derivation and PSBT handling came even later. He is still excited about what Taproot allows: a wallet that costs the same as single-sig but has a fallback that lets your heirs spend your Bitcoin "if you croak," or complex contracts where everyone just signs off once the outcome is clear, keeping the script tree private. Cross-input signature aggregation was left out because it was years from ready, and it remains open research today.

On SegWit, he called the "surprise block size increase" story a rewriting of history. It was a compromise born from a schism, combining a malleability fix, a witness discount that improved the input and output cost balance, and a bit more capacity. And because he could not resist: "the witness is part of the transaction, if we're still not done with that debate."

Would he ever raise the block size? Peter Todd had told me he would prefer bigger blocks to drivechains. Murch thinks we still have low-hanging fruit, from Lightning to Ark, payment pools, ecash and Fedimint. But he would not rule out an eventual increase, especially if quantum-safe signatures arrive at "a thousand to several thousand bytes" each, versus 64 bytes for a Schnorr signature. That would mean a hard fork or an extension block, which some describe as a "forced soft fork."

What he rejects is a small bump as a scaling plan. We agreed the Bitcoin Cash camp were not idiots for setting a 32 MB limit, just people with a different vision. But a factor of 30 "is inherently uninteresting. It doesn't solve the problem. It kicks the can down the road." He wants Bitcoin to scale 1,000x or 10,000x, and believes a 30x increase early on would only delay that. Keeping block space tight was a deliberate choice that forced ingenuity.

No Free Lunch in Privacy

I brought up the MimbleWimble Extension Block on Litecoin, which Charlie Lee explained to me back in Season 11, and asked whether something like it could ever reach Bitcoin. Murch remembered being genuinely excited when MimbleWimble first came out, for its interesting trade-off between privacy and scripting and for cut-through, where chains of spent transactions collapse into just the first inputs and the last outputs.

But he does not expect a serious Bitcoin proposal. With confidential amounts, you can no longer easily see the total supply, and the fixed supply "has been one of the core tenets of the Bitcoin community." Any privacy paradigm that weakens supply auditability runs into the people who care most about number go up. He admitted he had not tried MWEB himself, but said experimentation on other chains is healthy, and we should "pick the cherries and put them back to Bitcoin."

He was also candid that privacy research is not his focus, and he refused to name a favorite privacy coin. He found Bitcoin early enough to skip the altcoin phase entirely. What he wanted was honesty about costs. Bitcoin is "definitely not best in class" on privacy, address reuse and exchange on-ramps make it worse, and "there's no such thing as a free lunch." Privacy coins give you more private transactions inside a smaller anonymity set and a smaller network effect.

Coinjoins give you good unlinking, but also label your coins differently. "Obviously I don't think privacy is a crime," he added, but the mixing costs block space and money. He believes the future of Bitcoin privacy lives mostly in second layers and UTXO sharing schemes like Lightning, where, after a multi-hop payment, it is already fairly hard to track where an on-chain payment came from.

Miners Are Not Servants

I pointed out a feature of Bitcoin I love: block rewards come out as fresh coins with no history, so if you want truly private Bitcoin, mine it. Murch liked the point, then admitted the thing that keeps him up at night. "One of the things that lately keeps me awake at night is there is too few people that are building block templates."

He has no silver bullet. Stratum V2 is coming, but making pools adopt it is another matter, and it creates new problems: a miner could earn from a pool without contributing the work it should, for example by including fewer transactions, which requires template checks and statistical analysis to catch. He had also been discussing time warp and timestamp attacks on Delving Bitcoin as part of the Great Consensus Cleanup work.

None of this is easy to exploit, but it becomes accessible when a few parties control most of the hash rate. He even gave the "Core is compromised" crowd partial credit: the instinct to watch the network is right, just don't base conclusions on "a few screenshots that someone took out of context."

On activation politics, he described mining as having become an operations research problem for companies that are not always invested in the Bitcoin idea. Yet working with miners is the safest way to deploy a soft fork, because a hash rate majority enforcing new rules means fewer reorgs and fewer fights over validity. He thinks the 2017 user-activated soft fork has been romanticized: the UASF code never actually enforced anything, because miners activated SegWit before its deadline. It remains a tool, but "probably a tool that will only work once," and it would be silly to burn it on ordinary upgrades that everyone wants. Treating miners as servants won't help.

I credited Paul Sztorc for reminding everyone what a colluding miner majority can do. Murch answered that Bitcoin itself already assumes an honest, self-interested hash rate majority, and if that fails, the system is "permanently uninteresting." His open question about drivechains was whether a majority of all miners would need to be malicious, or just a majority of those participating in a given sidechain. He said plainly that he had not looked at drivechains in a long while and did not hold strong opinions.

Zero-Conf Was Always Just a Promise

With almost two hours gone, I picked the two remaining topics I suspected John Carvalho was waiting for: zero-conf and tail emission. Murch started from the cypherpunk origin story. Digital cash projects failed in one of two ways: a central point of failure that got shut down, or no solution to double spending. Bitcoin's answer is blocks, an absolute order of transactions published on a regular cadence, which become harder to rewrite with every confirmation.

Accepting unconfirmed transactions for small purchases made sense when block space was abundant. But a coffee payment is destined to be priced out of the base layer. For much of the past year the mempool barely cleared, and paying $2 in fees on a $5 coffee makes no sense. BIP 125 opt-in RBF had existed for about eight years, with roughly a third of transactions signaling by his rough recollection, and the network had now shifted to full replacement in practice.

Businesses can build risk heuristics, and some have done it successfully. "There never at any point really was a promise by the Bitcoin network that unconfirmed transactions are going to be reliable." A recipient can fight back with a high-fee CPFP child, but there are no guarantees, "and please don't claim that there is."

I called it the best explanation of the full RBF fight I had heard, and mentioned Bitrefill's argument that impatient users would leave for other coins. (For the full boxing match, see Peter Todd vs Sergej Kotliar in S14 E4.) Murch sees RBF as a better way to bid for block space: aim for the second projected block, then bump as your deadline approaches. He credited Gloria Zhao's package RBF work and Chaincode's cluster mempool project for making those replacements more incentive-compatible. And his response to "then use Litecoin or BCH" was grown-up and slightly melancholic: "We're trying to build something new. We have to make trade-offs."

2140 Is the Wrong Date to Panic About

Tail emission, popularized in Bitcoin by Peter Todd's blog post arguing that lost coins offset a small perpetual issuance, got the most numerate answer of the night. The subsidy started at 50 BTC and fell to 3.125 BTC with the April 2024 halving. It will drop below 1 BTC per block in the early 2030s, and the total of all remaining subsidies falls below a single Bitcoin around the year 2100. "So frankly, 2140 is completely uninteresting," he said, because by then blocks earn one satoshi of new coins. The subsidy stops mattering in about 40 years, not 120.

The good news hidden in all those inscriptions is that fee markets work. 3.125 BTC is equivalent to about 312.5 sats per vbyte across a full block. Fees around the runes launch briefly exceeded the subsidy, and months of roughly 100 sat/vB fees were worth about one Bitcoin per block. As the subsidy halves, the fees needed to replace it shrink too. He still wants research on anti-fee-sniping and on whether a permanent backlog will hold, noting that the famous instability papers assumed infinitely large blocks and a mempool that clears every block.

He agreed with Peter Todd on one thing: a permanent subsidy would be "academically much easier" to reason about. He does not think that is enough to break one of the movement's core memes. Lost coin estimates of 3 to 5 million are speculation, and people get better at not losing assets that grow in value. His conclusion is the sanest thing I have heard on the subject: "if in 12 years there's not enough block space demand to be on par with the block subsidy, probably Bitcoin was not very successful." It is not keeping him awake at night.

Then we disagreed, which I enjoyed. I called the "holding is using" meme silly, since holders don't pay for security today. Murch, while insisting he is not an economist, defended holding as a real use case that sets the market price and therefore the value of the mining reward. "I don't think it's a silly meme," he said, before teasing me for getting "spicy towards the end." We ended up agreeing that you also have to actually use the thing.

Before we wrapped, I asked where people should find him. He wants more good questions on Stack Exchange, and more experts to adopt their own topics: wallet developers answering questions tagged with their wallet, privacy researchers covering coinjoin threads, and Lightning developers whose answers have been lost in Slack. You can even ask and answer your own question to seed the archive, because it is "a very visible and somewhat permanent archive."

He also pointed listeners to the Optech newsletter, its weekly podcast recap with Mike Schmidt, and the underrated topics index. He co-hosts BitDevs in New York on the last Thursday of the month, and recommended Chaincode's learning resources, Mastering Bitcoin's third edition (which he proofread for Dave Harding), Kalle Rosenbaum's Bitcoin Development Philosophy and Grokking Bitcoin, and Resistance Money, the peer-reviewed book by three philosophers who used Stack Exchange in their research. He had not found a mistake up to chapter nine.

His parting message was the most human thing anyone from Bitcoin Core could say to a crowd that thinks they are puppets: "we're regular humans just trying to do good." Building decentralized systems is messy, nobody is the dictator, and if you want to be informed, as he put it earlier in the show, "you have to inform yourself." You can follow him at @murchandamus, and if you want to see how a core contributor's path can start, my talk with Hernan Marino about becoming a Core dev is a good companion. As for me, I will keep playing contrarian when it helps people think for themselves, even when the one who ends up wrong is me.

Listen to Murch on Spotify, Apple Podcasts, YouTube, and More

Watch on YouTube

Time stamps:

00:00:41 – Introduction of Murch
00:01:41 – Discussion on Bitcoin Myths
00:02:07 – Ordinal Inscriptions Debate
00:06:12 – Concerns Over Ordinals and Fungibility
00:08:42 – Censorship and Data Insertion
00:10:18 – Bitcoin Core's Development Process
00:11:31 – Public Nature of Bitcoin Core Discussions
00:12:49 – Community Perception of Developers
00:16:35 – Radicalization in Bitcoin Perspectives
00:18:28 – Diverse Interests in Bitcoin
00:20:21 – Censorship Resistance and Decentralization
00:22:27 – Ossification and Software Maintenance
00:24:29 – Evolving Software Ecosystem
00:26:08 – Lightning Network and Transaction Confirmation
00:27:49 – Community Engagement and Feedback
00:28:54 – Default Behavior Changes in Bitcoin Core
00:31:29 – Scaling Bitcoin: Layer 2 Solutions
00:33:11 – Protocol Development Momentum
00:35:57 – Concerns About Opcode Activation
00:39:00 – Covenants and Transaction Introspection
00:43:56 – Discussion on Community Perception
00:45:01 – Arguments for Covenants
00:48:55 – Politics of Bitcoin Development
00:52:46 – Challenges of Soft Fork Activations
00:53:57 – Secondary Effects of Taproot
00:56:12 – Potential of Taproot
01:00:17 – Complexity of Bitcoin Upgrades
01:02:35 – Future Block Size Considerations
01:05:57 – Discussion on Block Size Politics
01:06:51 – Digital Cash vs. Store of Value
01:08:03 – Scaling Solutions Debate
01:09:33 – Lightning Network Advantages
01:11:06 – Introduction to Hodling.ch
01:11:49 – MimbleWimble Extension Block Experiment
01:13:12 – Post-Taproot Era Prospects
01:14:12 – Privacy vs. Scripting Trade-offs
01:15:41 – Bitcoin’s Supply and Privacy Concerns
01:17:01 – Future of Privacy Protocols
01:21:58 – Trade-offs in Privacy Solutions
01:26:39 – The Role of Mining for Privacy
01:27:16 – Concerns Over Mining Centralization
01:28:00 – Mining Pool Adoption Challenges
01:29:24 – Consensus Vigilance
01:30:38 – The Role of Miners in Protocol Development
01:34:48 – Historical Context of Miners and Validators
01:35:27 – Economic Majority Concept
01:40:40 – Drivechain and Network Security
01:42:07 – Zero Confirmation Transactions
01:43:00 – Historical Overview of Bitcoin's Double Spending Solution
01:47:36 – Future of Small Payments on Bitcoin
01:48:51 – Lightning Network as a Solution
01:50:14 – Full RBF and Unconfirmed Transactions
01:53:16 – User Experience with RBF
01:57:26 – Trade-offs in Bitcoin Development
01:58:50 – Concerns Over Block Subsidy
02:01:14 – Transaction Fees vs. Block Subsidy
02:04:18 – Research Needs for Bitcoin Incentives
02:06:57 – Tail Emission Debate
02:09:35 – Long-term Outlook for Bitcoin Demand
02:10:02 – Value Preservation vs. Network Security
02:12:47 – Discussion on Bitcoin Use Cases
02:13:48 – Role of Bitcoin Stack Exchange
02:15:51 – Encouragement to Contribute
02:17:05 – Bitcoin Optech Group Newsletter
02:19:03 – Listening to the Optech Newsletter Recap
02:20:00 – Appreciation for the Conversation
02:20:47 – Challenges in Decentralized Systems
02:21:49 – Recommended Bitcoin Literature
02:22:56 – Closing Thoughts on Bitcoin