Title: S15 E50: Murch on Popular Bitcoin Myths
Podcast: Bitcoin Takeover Podcast (host: Vlad Costea)
Guest(s): Murch (Mark Erhardt, Chaincode Labs)
Published: 2024-08-16
Duration: 2:23:33
Episode URL: https://bitcoin-takeover.com/audio/?name=2024-08-16_s15_e50__murch_on_bitcoin_popular_myths.mp3
Audio: https://bitcoin-takeover.com/audio/media/2024-08-16_s15_e50__murch_on_bitcoin_popular_myths.mp3
Transcript: CORRECTED. Base: local Whisper medium.en transcript with automatic speaker diarization, reconciled against a full local small.en (float32, VAD) re-transcription with word timestamps, the YouTube auto-captions of the livestream and an older local whisper-tiny transcript (three-way comparison over the whole episode). Spots where the decoders disagreed were checked against the audio; 13 doubtful or garbled stretches were re-transcribed locally from short audio clips with medium.en float32, and about 40 more were resolved where the small.en pass and the captions agreed (including the hallucinated phrase removed at 01:10:30 and stretches restored at 00:36:47, 00:47:32 and 02:03-02:06). Speaker turns were checked with a full-episode local speaker-embedding scan (TitaNet reference voices for Vlad and Murch, 1.5 s windows at 0.75 s hop) and re-split by hand, including Murch's short replies at 00:01:38 and 00:02:04, the turns at 00:18:28, 00:38:04, 00:41:00, 00:48:55, the "bigger videos" exchange at 01:02:30, the tail-emission/zero-conf exchange at 01:42:36-01:43:01, the Stack Exchange exchange at 02:14:25-02:14:33 and the closing at 02:21:55-02:22:23. Names and jargon were checked against the title, the show notes and the web: Murch, Chaincode Labs, Bitcoin Stack Exchange, Hodling.ch, SideShift.ai, LayerTwo Labs, StarkWare, Bitcoin Knots and Luke Dashjr, Ordinal Inscriptions, runes, BRC-20, OP_CAT, OP_CTV, ANYPREVOUT, LNHANCE, OP_INTERNALKEY, OP_TXHASH, TAPLEAF_UPDATE_VERIFY, CheckSequenceVerify, covenants, drivechains and Paul Sztorc, MuSig2, PSBT, Guix builds, Ava Chow, Andrew Poelstra, Fedimint, Ark and payment pools, Rootstock, mempoolfullrbf and BIP 125, zero-conf, cluster mempool, tail emission, the Great Consensus Cleanup and timewarp, Lamport signatures, Delving Bitcoin, Bitcoin Optech, Bitaxe, NerdMiner, OCEAN mining, Mimblewimble extension blocks, Matt Corallo, Kalle Rosenbaum's Grokking Bitcoin, learning.chaincode.com, Fiverr. Light clean verbatim: ums, false starts and stutters removed; factual slips by speakers are kept as spoken. Intro music omitted. Remaining doubtful words are marked [unclear: best guess].
================================================================================

[00:00:41] Vlad Costea: Hello there and welcome to the Bitcoin Takeover Podcast. I am Vlad and this is season 15, episode 50 with Murch. If you don't know who Murch is, it means you haven't spent any time at all googling stuff about Bitcoin and ending up on the Bitcoin Stack Exchange website. Because for the past 10 years, he has been maybe the most active contributor, the person who answers all the questions, and they're usually technical. And he's also an engineer for Chaincode Labs. And I must also mention that this episode is sponsored by Hodling.ch, SideShift.ai, LayerTwo Labs, and StarkWare. And after this introduction, I got to give it to Murch because he's an excellent contributor to Bitcoin. A lot of people claim to be Bitcoin educators, but he's actually educating the developers and the builders and the people who are trying to do something great in the space. So welcome, Murch.

[00:01:38] Murch: Thank you for having me.

[00:01:41] Vlad Costea: So the purpose of our discussion today is to talk about Bitcoin myths and misconceptions and ideas that people discuss very liberally on Twitter and they take for granted without actually considering whether or not it's true or technically correct.

[00:01:59] Vlad Costea: And you're the person who's always technically correct.

[00:02:04] Murch: Well, I try. Thank you, though.

[00:02:07] Vlad Costea: OK, we have a list of, I think, 10 topics. The first one, I don't think this is at the top of the list, but it's the first one that we established we're going to mention. It's Ordinal Inscriptions, whether or not they're spam, whether or not Bitcoin Core is captured, because I've seen this accusation before that Bitcoin Core is compromised and therefore you should only use Bitcoin Knots, which is maintained by Luke Dashjr.

[00:02:35] Murch: Yeah. Well, personally, I'm most interested in Bitcoin as an implementation of digital cash. So looking at the Internet as one of the main focus areas of human commerce these days, it is really obvious that something like cash is missing. Credit cards are kind of weird. You leak your private key every time you make a payment. And they are super surveilled. And really, there's just no good cash equivalent on the Internet. So this is what got me excited on Bitcoin. And that's what I work on. That's what I keep in mind when I think about what should happen in Bitcoin.

[00:03:21] Murch: So I'm a little surprised when people think that having a nuanced opinion on new things happening on Bitcoin means that you're carrying water for that. Anyway, I think that the critics of ordinals have been very effective at raising their concern. Often in human society, the squeaky wheel gets the oil and they've definitely been the squeaky wheel. But if you're just endlessly repeating the same position, at some point, that's politics and not raising concerns. And it's a dust attack on developer attention. So I think that the conversation at some point just fell out of focus because it was overdone.

[00:04:21] Murch: So I'm not a big fan of ordinals or inscriptions. I don't think that Bitcoin's built to do that. Like, as I said, my main interest is digital cash. I'm not particularly concerned that digital baseball cards don't have enough support for trading that or whatever. Most of that can be done with central market makers. It's just not a focus area or interest of mine. So maybe if we just distinguish a little bit what we're even looking at, ordinals is essentially a client side validation protocol. You put on your ordinals glasses and then you can see some imbued additional meaning on UTXOs.

[00:05:08] Murch: And some people think that's really cool. And they sort of assign a serial number to UTXOs or rather the perceived satoshis in a UTXO that then traverses UTXOs according to their arbitrary rules, how satoshis supposedly move between UTXOs. I think that's sort of a good analogy. Just like when you put money into an ATM, the ATM might register the serial numbers and with the bank deposits and so forth, you can sort of keep track of dollar bills at certain points. And there are certainly other societies where that sort of thing happens extensively.

[00:05:57] Murch: But I think most people don't really care about ordinals. And therefore, yes, people that act on this ordinal glasses perspective, they might stick out from the perspective of surveillance because they behave differently. But other than that, I don't really see it having a huge impact on fungibility, which is one of the concerns often raised. And beyond that, Bitcoin is a censorship resistant money with scripting capabilities. And the only way that I see that you could break ordinal use and especially inscriptions is by heavily restricting either the censorship resistance or the scripting capabilities.

[00:06:42] Murch: So my question is just, what trade off are you willing to make? What price are you willing to pay in order to get rid of inscriptions and ordinals? It's, in my opinion, not a price I'm willing to pay either of those two to get rid of some people drawing Abraham Lincoln vampire slayers on Fiverr. It's just the current fad. It's raised the block space demand for a bit. Now blocks based demand is down. Yesterday, transactions between two and three sats per vbyte were clearing. Yes, blocks are full.

[00:07:21] Murch: But that was something that we've been expecting for the last 10 years that eventually there would be a lot of demand for Bitcoin. And that's why projects like the Lightning Network and other scaling technologies have been the focus of Bitcoin developers. So basically, my point is, if you're still harping on ordinals are spam and we need filters and so forth, I think you're not engaging with the arguments that are being made about it. You're just sort of ignoring the nuance of the topic and you're acting as if there is no trade off to be made.

[00:07:57] Murch: And really, I think you can spend your time more effectively. Is that maybe a good answer so far? Any questions, comments?

[00:08:10] Vlad Costea: Well, there is this community meme which says that if you run your node using Bitcoin Knots and you mine with your Bitaxe or with your NerdMiner using OCEAN mining, then you're basically circumventing all of this what they call spam and you're going to be able to save Bitcoin. And to which extent is this realistic? Are they really filtering or can there be other ways to insert data without using the ordinals protocol that cannot be censored?

[00:08:42] Murch: Yeah, I think it's not possible to completely prevent putting data on the blockchain. In the worst case, if you don't do anything else, people can just write to pay-to-witness-script-hash outputs. The pay-to-witness-script-hash output is mostly a hash of a script. So it's random, pseudo random data. And if you just write other stuff there, nobody can really tell that it's other stuff rather than a script hash. So in the worst case, they're just going to use other parts of Bitcoin to write stuff there.

[00:09:23] Murch: And I don't see how we can prevent it. And I'd rather they write it to witness data than to the UTXO set. So frankly, I just don't think that the expectations that people have that we just magically wave our wand and make ordinals or inscription stop is reasonable. And I guess that feeds into the Bitcoin Core's captured narrative, which I've been also seeing a bit. I think it's a popular engagement bait. It sort of feeds into this common knee jerk reaction to authority or power. Like Bitcoin Core is the most popular node implementation.

[00:10:09] Murch: So now they're at the top of the perceived power pyramid or whatever. So people are against them, especially Bitcoiners. And so on the one hand, I think Bitcoin Core is just a loosely organized group of people that collaborate to release software together. We don't agree on much else other than that we have this process to release software together. And if these diverse 30 people tell you all, no, I guess you can have two reactions there. One is, oh, I might be wrong. Or you'd go, oh, it's a conspiracy.

[00:10:51] Murch: And I guess that's a bit of a personal preference, which of the two you go then. But it's a little silly. It's a huge time sap on people. We're working in public. You can go read our GitHub comments. You can read our code reviews. You can see what code we're writing ourselves. All of that is public. Our IRC meeting is public. We publish the logs to websites. You don't have to even turn on IRC to read up what we've been discussing in our meetings. We contribute to the mailing list.

[00:11:26] Murch: Our entire communication is public. The power that we have is that we write the code for changes that we want to see in the code, sorry, in the software. And sure, that's the only power that people only ever have is making things happen. But if you don't like the software we're creating, just stop using it, I guess. Or write your own or use Knots. If by all means that's a better choice for you personally. But just because people have a genuine disagreement on what trade-offs are the correct ones to make doesn't mean that Bitcoin Core is captured.

[00:12:14] Murch: It's a strange and frightening thing that there's actually nobody in control, no benevolent central authority that can save you and make that decision for you and fix the world. And that you can lobby. Bitcoin Core contributors are not politicians. A lot of them are actually not particularly keen on engaging on social media all day. So yeah, I just find it kind of weird and laughable, this allegation that Bitcoin Core is captured.

[00:12:49] Vlad Costea: Well, to me, it's interesting because they associate the idea of development with a few names. They look at the list of maintainers and they say, oh, look, we have Gloria Zhao, we have Ava Chow. Oh, they rhyme, by the way. We have this assembly of people and we can blame them for anything that we want to happen and doesn't happen. And I've seen in the case of Ordinal Inscriptions that a bunch of people basically, they even set up a domain name and a website and they said Bitcoin Core is captured dot com or whatever.

[00:13:21] Vlad Costea: And they said because of these people who refuse to integrate into the core client, what we want there to be and which something which is already available in Bitcoin Knots, then Bitcoin is basically compromised. And then they make up these conspiracy theories and they look into the people who finance Bitcoin Core development and they say, you know, these are the people who are trying to destroy Bitcoin. And therefore, these are just puppets that are orchestrating this grand conspiracy. I don't know. It just comes back to that whole Blockstream X Bilderberg situation that's been posted on Reddit.

[00:14:02] Murch: I mean, people like to know why something is happening. And it's often easier to just, if it's hard to explain, because we basically have this decentralized process. People just work on the things that they perceive to be important or interesting. And maybe also a word on the maintainers. The maintainers themselves don't decide what goes into Bitcoin. They can only choose from the things that have been written and proposed as pull requests to Bitcoin Core. They can only merge stuff that has been sufficiently reviewed and has gotten some community support among the core contributors.

[00:14:47] Murch: And if any of the maintainers were to go and just merge something that doesn't have this perceived support, it would be reverted. They would be removed as a maintainer. And between something getting merged to the core code base and a release, there is usually only a release every half year. There's a multi-week process from cutting the release branch to finishing up testing, building the binaries, signing the binaries, making Guix builds where other people confirm that the binary was built from the source code that they also see.

[00:15:27] Murch: It's not like they merge something into the Bitcoin Core repository and suddenly everybody is running it. We don't even have an auto update. If there's a new release, first users have to perceive this as something they want, go download it themselves, hopefully verify the binary, then run it. And so at no point does a maintainer unilaterally decide what goes into Bitcoin Core. It's way more complicated and nuanced than that.

[00:16:01] Murch: What power do these people have? Well, they have the power to contribute to the thing that they think is important and worth doing. And you have that same power. So if you want something else to happen, contribute to that, release your own client or open a pull request. And then if lots of people don't like it, maybe release your own client with that feature or accept that the other contributors don't think the same way you do.

[00:16:35] Vlad Costea: Well, I guess that's the problem, because for some people, it's hard to accept that there are these people whom they perceive as their servants or something who are not agreeing with them 100%. And there's this process of radicalization that we see sometimes with people who see some sort of quest for purity in something and they perceive some external factor as the impure element that they must eradicate from the network. And then they ask everyone else to agree with them. And if they don't, they're going to create their own small cult where everyone is in tune with each other and everyone else is possibly a shitcoiner.

[00:17:16] Vlad Costea: I don't know. Speaking of shitcoins, check out SideShift.ai. If someone chooses to pay you in stablecoins or something that you're not interested in and you can't convince them to send you BTC, then you can effectively do the swap on SideShift. They're going to take care of everything that you're dumping and make sure that they're not at a loss. And the fees are pretty low. So go to SideShift.ai. They also have an integration for Rootstock. So if you have some BTC and you want to get some rBTC on the Rootstock sidechain, you can actually do that with SideShift without the peg-in mechanisms that require you to run a node.

[00:17:56] Vlad Costea: So SideShift.ai, they're really cool. Check them out. And I was going to ask you right now, because it seems like we are at the edge of this argument, because you mentioned what a maintainer does and what a core contributor does. And it all sounds like you're making changes to the client, right? But at the same time, these changes are made without activating anything new. So I think it's useful to get into the conversation. I'm not sure which point from our list this was, but it was about...

[00:18:28] Murch: I would like to push it back a little more because I had a couple more things that I wanted to say about the previous topic. I mean, a lot of people really like the Bitcoin as a number go up technology, as a savings technology, for example. Some people like it as digital cash, as private money. And so, for example, there's a conflict between those people too. Michael Saylor may say, don't talk about privacy features and don't work on privacy features because he's interested in number go up technology. And some other people are super interested in privacy.

[00:19:04] Murch: So just like ordinals, people want to have their graffitis on UTXOs and other people want to make cheap payments. There's just various different perceptions of what Bitcoin is to people. And Bitcoin is a lot of different things to different people. And who are we to choose what is allowed and not allowed? I mean, if we're going to start censoring certain use cases, I think we're going to very quickly see our censorship resistance go. And censorship resistance is one of the most important properties of Bitcoin because we can't really have decentralization without privacy.

[00:19:47] Murch: We can't have censorship resistance without decentralization. All of that is sort of interwoven. If you start twiddling on the gears here and there, you might just make it all implode. For example, I'm not sure if we would have number go up technology without privacy and decentralization. That just doesn't ring true to me. So we have this very complex system of interests and things people want out of Bitcoin. And it sort of happens to work right now. It's somehow in balance. But if we shift it too much in one direction or another direction, it might just swing and topple.

[00:20:35] Murch: As we said, there's no central authority that we can run to and make them save us if we fail. If we sink Bitcoin, it's just gone. It's probably going to not be replaced by another second Bitcoin, because there's already 20,000 other altcoins to choose from that all have various trade-offs. And I just don't see another one come into such a network effect as Bitcoin has right now. So I guess we don't have to love what other people want out of Bitcoin. But if you want something out of Bitcoin, maybe try to understand that other people also want something out of Bitcoin, and it doesn't always perfectly align.

[00:21:15] Murch: If you think ordinals are destroying Bitcoin, you might find this answer very unsatisfactory. But yeah, I guess I answered that earlier already. I think it's something that blows over. And it's also something that sort of simulates how Bitcoin will change later anyway, where block space will be very expensive. We've had a test run at that now. I think we're much better set up than in 2017 when we had a lot of block space demand the last time. So I guess progress. And to the people that say, yeah, but it got expensive too early.

[00:21:56] Murch: Well, I also, I'm unhappy that I didn't buy more Bitcoin when I was younger. We have to deal with what we have on our plate. Life is not always a bowl of cherries. Yeah. Okay. Sorry. So you were trying to transition us to the topic of features in decline or changes to decline and how that relates to protocol changes? Or was that the topic?

[00:22:27] Vlad Costea: Yeah. And how this relates to the idea of falsification, because even in a situation where we agree that we're not adding anything new, there's still a need for developers to maintain the code. And that sounds conflictual to some people. They think, oh, you just leave it alone. There is actually a cult within the Bitcoin community that believes that Satoshi gave us the perfect technology and everything else that's been added since is destructive.

[00:22:57] Murch: Yeah. I mean, Satoshi had this brilliant idea and one of the most impressive things is that the original code base was something like 10 to 12,000 lines of code actually implemented a proof of concept version of that idea.

[00:23:17] Murch: It certainly couldn't do all the things or resist all the attacks or threats or potential ways. This could run out of memory or fail or not scale well as it can today. There's not a ton of code left from that time. A lot of things have been improved since then. So there's a few things here. One is in order to run any computer software, you need hardware to run it on. You need an operating system to hook into. You have all sorts of drivers. You have all sorts of libraries that need to be present on your computer in order to run software on it.

[00:24:04] Murch: And this is an evolving ecosystem. So when you write software, it might be perfect the first time, but even if nothing in the code itself was wrong the first time, it has to live in a different environment over time. And that means that you need to adapt your software to survive in the changing environment around it. So very clearly we can't just write software once and then use it for the next 20 years. That'll just not work. And now, sure. So we have an argument why there is maintenance necessary for software because whatever.

[00:24:45] Murch: Apple comes out with a new version of Mac OS and suddenly Bitcoin Core doesn't start anymore because they slightly tweaked the interface on one of their drivers. It happened a couple of releases ago. Well, [unclear: we've got that motivated]. But then there's also just other things like society is changing. More and more people are using Bitcoin. We're not just writing software to manage a hundred bucks anymore. People have very significant amounts of money stored in Bitcoin. And the security standards, the review standards, things have evolved. We have different needs of our software over time.

[00:25:33] Murch: So clearly software needs to adapt to its users needs. Otherwise it'll get replaced or become outdated. Now all of that is only client stuff so far.

[00:25:49] Murch: That motivates maybe why you would sort of keep the same feature set alive in software. But also, for example, lightning came around and now maybe we need to be able to have a transaction confirmed within a certain amount of time. There's a use case that is extremely important for people that want to use the lightning network. And the lightning network has been helping us scale payments on top of Bitcoin. And I would say it's a very popular and well adopted technology. Clearly it's not ready for prime time and 8 billion users, but it's come a very long way since 2015, since the white paper came out.

[00:26:34] Murch: So now maybe we need to be able to properly relay transactions that got cycled out or have to have better mechanisms for replacements. So this is something that affects how we interact with unconfirmed transactions and how we relay those across the network. And clearly we can't just take Satoshi's code from 2010 and run that. Most of that, I think there is a version that was created before Satoshi left that would still sync to the network in theory, but it's just so horribly inefficient at processing the blockchain that it would take years to catch up to the chain tip.

[00:27:23] Murch: So we are still compatible with the original protocol and we're still working on the same project. It's just that we've made some progress in the last 14, 15 years and we have higher standards and our feature set is expanding to address more and more use cases and needs.

[00:27:49] Vlad Costea: At this point, I want to give a shout out to two of the people in the chat on YouTube. There is John Carvalho, the Bitcoin Error Log, who says, I love Murch, even though he will not admit he loves me, smiley face. Or, oh, they are wrong, but they are speaking like they know, but they don't. I'm not sure exactly what he was referring to. Maybe he was making some commentary, but there's also [unclear: Vake] in the chat and he says, big Murch fan, I would buy his merch.

[00:28:20] Murch: Yeah.

[00:28:22] Vlad Costea: If you put out t-shirts, let [unclear: Vake] know.

[00:28:24] Murch: Okay. Yeah, I think maybe that's a good segue. I'm sure John Carvalho is heavily invested in the latest releases, a choice to release mempoolfullrbf. We've had a ton of conversations about that in the past years. And I think that it's nuanced. For example, there is definitely a loss in information if you can't explicitly state whether a transaction is intended to be replaced in the future or not. On the other hand, I see that the network has adopted mempoolfullrbf to an extent where over 95% of the blocks clearly are including mempoolfullrbf, sorry, Full RBF replacements.

[00:29:17] Murch: And it is affecting block relay. It's slowing down block relay because the compact block reconstruction is failing at a much higher rate because nodes have fewer of the transactions that actually got included in the blocks. And after two and a half years of having the option, it seems like the default is supposed to change because this is how the network behaves now at an emergent behavior. And so, for example, in the upcoming release in a few weeks in version 28, the Bitcoin Core node will now change its behavior to by default allow replacements, even if the original transaction had not signaled.

[00:30:04] Murch: And we do see quite a bit of use of Full RBF replacements, especially by ordinals people, for example, for their PSBT bids. And so we see miners include them because they earn more money that way. And that sort of breaks the expectation that the BIP 125 signaling will be respected by the network.

[00:30:32] Murch: Maybe not something that everybody wanted, but it's just sort of the hand that we've been dealt at this point. And we're adapting the Bitcoin Core release to fit the current realities. So yeah, as I said, the environment is changing. What people use Bitcoin for and what they need out of Bitcoin is not a static thing in time. And that's how software needs to evolve. I'm sure he may have responded again.

[00:31:06] Vlad Costea: That's a very beautiful statement, because I got to segue into another ad, but also Paul Sztorc liked my tweet and liked the tweet about this livestream, so I guess he's watching right now. And I got to say that this show is very aspirational in the sense that I didn't just look for products and services that want to be promoted. I looked for companies that are trying to build stuff on Bitcoin. So we have these two paths of scaling Bitcoin. One of them is by LayerTwo Labs, and they're trying to push this BIP 300 to have drivechains. We can also talk about that one if you want. I'm curious to know your opinion. And the other one is StarkWare, which is a big fan of OP_CAT. Right now they have these Starks, which are zero knowledge rollups, which they are doing on Ethereum. And they want to bring that technology to Bitcoin. Their claim is that if they do have that technology on Bitcoin, users will be able to sync full nodes in a few seconds by verifying a zero knowledge proof. And there's also going to be some scalability and privacy benefits. But on the other hand, you have drivechains which want to do everything that is popular within the entire crypto industry on dedicated sidechains.

[00:32:21] Vlad Costea: So you can have Bitcoin backed Zcash privacy. You can have a big block sidechain. You can have an assets chain, which is going to deal with everything concerning tokens. And so on and so on. And I'm curious what you think about this.

[00:32:38] Murch: I'm just generally not that excited about altcoins. And bringing all the altcoins to Bitcoin feels like a way to onboard a lot of new needs and different directions to the project that I'm just not very excited about. I guess I'm not a big supporter.

[00:33:11] Vlad Costea: Okay, so from these two proposals for soft forks, which one do you think is more likely to get implemented? Is it OP_CAT, which concatenates transactions? Or is it BIP 300, which allows you to build sidechains?

[00:33:24] Murch: I think that OP_CAT seems to have a lot more momentum right now. The interesting thing there is, I guess, that it is an extremely simple code change that has very wide ranging implications that are not fully understood yet, in my opinion. I am aware that there's a lot of people that have been talking a lot more about that. But I would encourage those conversations to percolate to, like, some of the more visible media, like some of the conversation should perhaps end up in the mailing list or in Delving Bitcoin or other, at least blog posts where people can sort of read up on the state of the debate and catch up on how much of the concerns have been addressed, what sort of threat analysis and feature analysis or benefit analysis has been made.

[00:34:29] Murch: Currently, it seems to be mostly distributed conversations in Twitter spaces and Twitter conversations, which I find extremely hard to catch up on and index. So I think that, yeah, there seems to be a lot of excitement around OP_CAT and a variety of people have demonstrated some, well, a lot of, look what I can do sort of use cases like Lamport signatures with OP_CAT or being able to do a ZK proof in OP_CAT. And my understanding is that even though these are theoretically possible, the blockchain footprint, the blockspace footprint of implementing these in script, even with OP_CAT would be enormous and it would be probably fairly hard to vet what is exactly going on.

[00:35:20] Murch: So, yeah, I'm glad that people are thinking about scaling and about protocol development. I think that there's in both directions a bit of a need to get closer to each other. It feels to me that a lot of the new energy for protocol development is coming out of developers that have not historically been involved in Bitcoin Core development, where there used to be a lot of the protocol development being done. It's not that protocol development can only come out of Bitcoin Core, but rather there's a lot of expertise in Bitcoin Core contributors that is somewhat untapped at this point because the conversation seems to happen in Telegram groups and Twitter conversations, where I think a lot of these protocol developers don't necessarily follow.

[00:36:21] Murch: So on the one hand, I think the people that have worked on previous protocol development initiatives would be interested in catching up, but the information is not accessible to them. And on the other hand, it would be great if they did also chime in and shared their expertise on this. And so I don't really have a strong opinion whether or not OP_CAT is a good idea. I think the conversation is progressing. I saw the BIP... I merged, I think I merged the BIP, maybe someone else did. But for example, there is no clear proposal for an activation.

[00:37:04] Murch: There's not that much debate yet that comprehensively addresses the benefits people see and concerns people see. So, yeah, I think there's a little bit of this hard work, this research work, this establishing enough information and a body of supporting data that can be used to have a proper conversation about whether or not this is a good idea. That's sort of still in progress, I think. So to all the people that have been saying that OP_CAT is coming this year, currently, I don't see that. Maybe if they provide this or if the conversation progresses to that point, that could, I guess, be feasible.

[00:37:54] Murch: But if anything, I think it'll be next year at best.

[00:38:00] Vlad Costea: OK, that's still something. Next year, we might get OP_CAT.

[00:38:04] Murch: Okay, please don't quote me as "the Murch says OP_CAT comes next year." OP_CAT comes next year. I'm saying that I think the conversation is not ready for an activation client right now. I think that there's some consensus building required. That's how I want to be quoted, please.

[00:38:22] Vlad Costea: Yeah, yeah. So I'm trying to understand what is so special about OP_CAT right now, because after we activated Taproot, we had this conversation that we need cross input signature aggregation and some other stuff that was popular around that era. And it's funny that we call it an era because it was only three years ago. And the conversations have shifted. I think it was Jeremy Rubin who first came up with the idea of a covenant and that we might need this. He pushed very hard to have CTV activated.

[00:38:53] Vlad Costea: He got some backlash from the community because he went for activation via speedy trial. And maybe it wasn't the criticism about the code per se, but his willingness to pursue an activation so quickly after the community had agreed previously very hardly to do Taproot and there was no resistance to that one. It was just that nobody knew how to pursue it. And I think, sorry, go ahead. My question is, what are the arguments on the side of OP_CAT? Because if I understand correctly, this was first written by Satoshi Nakamoto in the original version of Bitcoin.

[00:39:34] Vlad Costea: It's not a covenant software per se, but it can be used to build a covenant. It's been rewritten entirely and it's about 12 lines of code right now. And the purpose of rewriting it has been to eliminate the concerns that Satoshi might have had 10, no, it was longer than 10 years ago, 14 years ago when he removed that opcode. And it's also available on Bitcoin Cash and Liquid. So if anyone wants to try to break it or test some edge cases, I think you can do it without wasting any BTC.

[00:40:11] Vlad Costea: So for anyone out there's an incentive. Of course, I'm not sure how much liquidity there is on Bitcoin Cash and Liquid, but still, you can try to build some stuff and see if it breaks. If you want to do some testing outside of a testnet on something which has real incentives. And I guess, on the other hand, you have drivechains. And they're not active on any network right now as far as I'm aware. They're just on Signet. And they do integrate more human politics. So it's not a large change at the code level.

[00:40:48] Vlad Costea: It's a large change in the way that we're going to interact in order to make these sidechains work. Can you correct any of these statements and let me know if I'm wrong in my line of thinking?

[00:41:00] Murch: Let me try to take it from the top. I don't think that covenants were invented that recently. Covenants is a very old idea. It's, I think, more of a 2010, 2011 conversation when it started. And I also don't really love the term covenant. Really, we are talking about opcodes that can introspect a part of a transaction. As in, they can self referentially look at other parts of the transaction that have previously not been accessible to Bitcoin script. And have some sort of control logic on basis of other parts of the transaction.

[00:41:43] Murch: So I think calling them transaction introspection makes it more obvious what we're talking about. And if you think about which opcodes have been added since 2010 and remember check sequence verify and check lock time verify, for example. Those are also transaction introspection opcodes that read a field and then make it available to a script. So the idea is not that new and I guess it's not that scary either. I think that there's a lot of misguided concerns around recursive covenants. Generally, in a Bitcoin transaction, the receiver always decides what output script they will receive to.

[00:42:36] Murch: And if you do not want to participate in a covenant, you will not put that into your own output script. Therefore, it will not be encoded in the address that you share with the sender and suddenly this covenant doesn't concern you directly. The other concern is more of a systemic concern where if other people use this extensively, does it ruin some properties around Bitcoin that I want to have? Does it impede my use of Bitcoin in the sense that it breaks some Bitcoin properties? And I think that one is a lot harder to answer.

[00:43:18] Murch: For example, if we get rollups on Bitcoin and then the entire block space is used by rollups, it might be really hard to send your own transactions on Bitcoin. And I'm not saying that that is something I expect, but that might be why introduce new features may interfere with existing features.

[00:43:43] Murch: All right. That was a little bit on covenants. Could you remind me? You had a number of questions. I think I addressed only a subset.

[00:43:56] Vlad Costea: I was speaking more about the pros and cons in terms of how the community is going to perceive this. Because, of course, they're going to say, wait, Satoshi took this out of the client for a reason, right? He decided to remove these opcodes because he was concerned about some situations. And if you're going to deal with the same people who say that the core developers who don't disable ordinals are evil, they're going to come up with this big conspiracy and say, oh, they want to enable OP_CAT because it's going to be the destruction of Bitcoin.

[00:44:29] Vlad Costea: So I'm trying to basically come up with some very small and easily digestible arguments in the form that this was rewritten in the way that it removes the concerns. And it's already available on two live networks and it should be easy to break, right? If the concerns are right about taking out nodes and making it easy to lock away funds and make Bitcoin easier to censor, then you should be able to do this on other networks and prove how it works. But so far, nobody has done that.

[00:45:04] Vlad Costea: I was wondering if you have any other easily digestible arguments for covenants. You say you're not a fan of the term covenants, but for OP_CAT or CTV or there was ANYPREVOUT, which I think fell out of grace these days for some reason.

[00:45:24] Murch: ANYPREVOUT seems to have a very dispassionate proponent. So, yeah, I just don't see a hard push for it right now. I think it's pretty much ready. There's been a bunch of research, but if nobody's pushing for it's probably not going to happen. There's a number of different proposals. There's OP_CAT, there's OP_INTERNALKEY, there's OP_TXHASH, there is TAPLEAF_UPDATE_VERIFY. There is OP_CTV, of course, ANYPREVOUT, LNHANCE. There's probably a few more that I'm forgetting at this point.

[00:46:02] Murch: So I think I don't have a very strong argument against covenants themselves. Some of the arguments are more middling, unfortunately. One is if you want to find sailors to build a ship with you and sail the seas, you make them love the sea and not ask them to cut a tree. So if you want an opcode in Bitcoin Core, you have to convince people that it'll do something awesome and that it will not break other things. And I think the step before that is you have to decide which one you want.

[00:46:47] Murch: So there's like seven proposals and there seems to be still a lot of debate about which one is best, what the trade-offs are, what we can do with each one. There seems to be fairly little testnet activity, just like you said. If people are so excited about OP_CAT, how come there's not a ton of OP_CAT use on Liquid, on Bitcoin Cash, on Signet? Like demonstrate your awesome new features, demonstrate your cool product. When we activated CheckSequenceVerify for Lightning, we had a functioning Lightning network on testnet that was implemented with a proof of concept client of Lightning.

[00:47:32] Murch: And the opcodes, CheckSequenceVerify was put into testnet along with a preliminary version of SegWit in order to test Lightning. And like, or test the whole combination of the three. So if you're so excited about it, how come you don't have a test case to point to and show us what you're doing, what you're excited about? So maybe that is a... I hope it's not perceived as shifting goalposts, but you have to make everyone excited in order for protocol development to get adapted. Because we do not have the benevolent dictator, we don't have [unclear: anyone who] ultimately decides. You have to build rough consensus for something and, to that end you have to convince them that it's safe and worth it. And so the first step of that is deciding which thing you're even aiming for. And while there's seven competing proposals that all seem to have advantages and disadvantages and trade-offs, maybe pick a lane, which one you're pushing for, build a movement and convince people that it's a good idea.

[00:48:51] Murch: Then we'll get it. Or not. Who knows?

[00:48:55] Vlad Costea: Yeah, so there is a lot of politics involved in this because you mentioned that the author of ANYPREVOUT is dispassionate. And there is a lot more momentum behind OP_CAT and people should build stuff and prove how it's useful and how it provides extra features that Bitcoiners want. So there is a degree of lobbying that's involved. And I was curious, in the end, there is this term of rough consensus or economic nodes or in the end, who is it that decides which fork should be integrated and whether or not it's valuable?

[00:49:33] Vlad Costea: Is there an arbiter of truth in this regard?

[00:49:38] Murch: Yeah, the CEO of Bitcoin, of course. No, I mean, that's exactly, I think that's an emergent theme of our conversation so far. It's all of us. We decide together and we don't have set rules because they are extremely easy to abuse. If you have exactly 15 people have to agree to this, well then suddenly 14 people show up for the first time and agree with it, probably, right? So it's not entirely obvious how exactly rough consensus is measured. But I guess I know it when I see it. It's sort of like you look around and you see what other people are doing, what the state of the conversation is.

[00:50:28] Murch: It's sort of more an emergent phenomenon. And maybe when Bitcoin was smaller, it was easier to see what the state of the conversation was because the conversation was in fewer places and with fewer participants. But our ecosystem has gotten a lot more complex and bigger and there is new players involved and the amount of money that is in play is much higher. So maybe it's just gotten harder. And if anyone has a brilliant idea how we can make this more obvious or easier without losing, on the other hand, our resistance to being taken over by state actors or private interests, then by all means, there's a huge space here for, I don't know, social experimentation.

[00:51:30] Murch: So to respond to, there is a political process. I guess politics is the art of compromise. And a lot of people want different things out of Bitcoin. So you sort of have to find ways that a lot of people want what you are offering in order for it to happen these days. And if nobody builds this sort of perception or movement or agreement, then probably the status quo will prevail. So it's weird in that it is politics, but it's not party politics. It's not national politics. It's sort of conversations happening, ideas spreading, hopefully a good dose of meritocracy.

[00:52:26] Murch: Well, however you pronounce it. And yeah, it's messy and nobody is in control. We are all together in control. And that's why we all have to find out and discover together when we agree.

[00:52:46] Vlad Costea: There are a bunch of people who are disillusioned with the idea of activating any soft fork because they feel deceived. When they added SegWit, they were thinking they're going to only fix an issue that enables them to use the lightning network. But they also woke up to a block size increase. And when they activated Taproot, they expected, I don't know, the marketing around Taproot was very interesting because it was presented as this upgrade that's going to make blockchain analysis obsolete because transactions are going to look identical to each other.

[00:53:21] Vlad Costea: Multi-sigs are going to look indistinguishable from normal transactions and therefore there's going to be more privacy on the base layer. But then what we got, I think the most popular use case for Taproot so far has been ordinal inscriptions. So there is this concern that we're going to activate something and we're going to deal with a side effect which ends up becoming more popular than the intended use case. And do you think there is any way to mitigate this or is there anything that we can propose that is not going to have these side effects?

[00:53:56] Murch: Well, it's always hard to keep track of all secondary effects and whatever people might, I mean, I don't think that people had ordinals on the radar when Taproot was talked about. Taproot has been talked about for five years before it activated. And I guess Casey just came up with it maybe two years ago, three years. And so maybe or probably after Taproot activation. It's also true that he could have done the same thing with legacy UTXOs. The inscriptions, of course, using the witness discount for the inscriptions would have also worked with pay-to-witness-script-hash.

[00:54:45] Murch: So I don't think that "Taproot caused ordinals" is a palpable or tenable point in a conversation. I do see that mostly it's been used for inscriptions so far. And that saddens me greatly, to be honest. I think part of that is that it is more featureful, but the features are more complex. So for example, MuSig2 took another two years to formalize and to spec and to make it into a BIP after Taproot activation. So clearly nobody was using MuSig2 except for people that were sort of jumping the gun.

[00:55:29] Murch: So yeah, MuSig2 just became available, what was it, about a year ago. And now there's a bunch of wallets that have integrated MuSig2. There's new BIPs now that have specified how to do BIP 32 key derivation based on a MuSig key, like an aggregated public key. There is now work on doing, or there's a, I think a BIP that specifies how to use MuSig in the context of PSBT. So, and the problem is that the feature is available on the protocol level. The tooling hasn't caught up yet.

[00:56:07] Murch: And even the specification for the toolings has just come out. And so I guess, sure, if you expected Taproot to immediately be adopted in the next year after it got activated, you're disappointed now that it has such a little market share or market share for the wrong reasons, in your opinion. But I still remain extremely excited about the things that we can build with Taproot, like something that you pay for as a single-sig that costs the same as a single-sig, but has a fallback that allows your heirs to spend your Bitcoin eventually if you croak.

[00:56:48] Murch: Or, yeah, if like a complex smart contract with a dozen different possible outcomes that just falls back to everybody signing off because one of the conditions has come true, the person that benefits from that condition can prove that it'll happen and can just publish their script leaf by themselves. But everybody is just like, okay, we see that that would happen. Let's keep our privacy intact and just sign off altogether and let that outcome go on chain. And that remains true. I think there's a big challenge in communicating about these sort of big projects in a way that is accessible to everyone.

[00:57:32] Murch: So I think that, for example, cross-input signature aggregations was a big talking point before Taproot, the final package of Taproot got proposed. But unfortunately, it was noticed that it was so much open research still and so much additional complexity that it wouldn't be ready for years. And in fact, cross-input signature aggregation is still a topic of open research today. So sure, we could have waited for cross-input signature aggregation before activating Taproot. But then we would have also not been able to use any of the other Taproot features for the next five years or so until we get cross-input signature aggregation, which I do hope we eventually get.

[00:58:19] Murch: So I think that we've just not really tapped the potential of Taproot fully yet.

[00:58:29] Murch: It's kind of funny to see how long it takes for a decentralized network to adopt a lot of different tools. Because if you look at the mempool, there's still a ton of transactions that just use pay-to-public-keyhash, the legacy transaction output format that's been around for the whole time. Even though they pay almost three times as much fees for it now. Okay, two and a half, but fine. They still like that and use that, and sure, they can. I don't think that it would be my first choice these days, but that's the nice thing about a decentralized network.

[00:59:11] Murch: With permissive rules and soft forks as an evolution mechanism, you can continue to use your old features if you like them. And yeah, so I think a lot of exciting stuff is going to be built on Taproot eventually. It'll take longer than people think. And I think with each soft fork, it might take longer because stuff gets more complex and not as obvious to use. And that doesn't mean that the proposal failed. You said that people were surprised by the SegWit block size increase. I think that's a mischaracterization or people might be misremembering or redefining the past.

[00:59:55] Murch: I think that it very much was a compromise born out of the situation at that time where SegWit hadn't progressed for years. And there was this big schism between people that wanted a block size increase and people that wanted a transaction malleability fix. And it was a very nifty way of getting something that many people wanted, moving the signature data into a discounted area of the transaction. By the way, the witness is part of the transaction if we're still not done with that debate.

[01:00:37] Murch: And sort of changing the cost of inputs to outputs in a favorable way, getting a little more capacity on the network with the block size increase, getting the transaction malleability fix. So I think it just checked a lot of boxes and got support from a lot of people, even though maybe some people hadn't fully understood what the entire package was. And yeah, Bitcoin doesn't have a spokesperson. There's no one person that has to explain exactly what the roadmap is. There is not even a roadmap in that sense.

[01:01:13] Murch: So yeah, if not everyone knows all the details of everything that's going on. Most of the time, unfortunately, it is their own responsibility to learn more about it. And if they want to have an opinion, they need to do their research. It's unfortunate that we are all in charge. So if you want to be informed, you have to inform yourself.

[01:01:40] Vlad Costea: That's a beautiful way to put it. But it's also a reminder that just because the development is slow doesn't mean that there is no development and that there is no discussion being had about possible improvements. And there's this topic of ossification, which seems rather nihilistic. It means, OK, we got to this point where the software is good enough for every possible use case of the future. And we believe that it's going to be the same. I don't think that happens to any open source software out there.

[01:02:10] Vlad Costea: It doesn't happen to Linux. It doesn't happen to Firefox. It doesn't happen to OBS, which I'm using right now. It doesn't happen to VLC, which is for playing video. There's always something new, like a new format, a new use case, a new something that users desire to have. And of course...

[01:02:30] Murch: The internet gets faster, and you can send bigger videos, yes. Sorry, go on.

[01:02:36] Vlad Costea: Yeah, and I was going to ask you, in a future where we have affordable internet bandwidth and we have affordable storage and maybe we also make transactions smaller and more compact. But do you see any situation where we're going to increase the block size? Because Peter Todd said this in an episode which I recorded. He said he would rather increase the block size than have drivechains because he believes that it's a more elegant way to scale as opposed to adding complexity.

[01:03:06] Murch: I think that there's still a few low hanging fruits how we can improve what we get out of the current capacity, the current block space. There's sort of things that give us leverage on our block space like the lightning network. There's a bunch of other similar proposals like Ark and payment pools or other ways of sharing your UTXOs in a way, maybe even e-cash and Fedimint and things like that just offer a wide range of different trade-offs in custody of the coins, privacy, features, trust models and so forth.

[01:03:51] Murch: So I think there's still a bunch of things how we can evolve and improve Bitcoin with the current block space. I think it's rather expected that eventually the block space will be increased. For example, people have been again talking a lot about quantum computers as a potential threat and currently what we're looking at with quantum safe signatures is on the range of I think a thousand to several thousand bytes per signature. And so right now a Schnorr signature is 64 bytes. If we're going to have to pack that on the blockchain, we're looking at a lot fewer transactions being possible at the same time.

[01:04:39] Murch: So for example, if we decide that we need quantum safe signatures and they are significantly larger, we might choose to increase the block space at that time in order to keep Bitcoin usable. I think that that would be an interesting or it'll be a difficult conversation for the community to have and come to consensus on eventually, it would certainly mean a hard fork or another SegWit-like extension block construction, which has been described by some as sort of a forced soft fork or I mean, in a way, if you want to use Bitcoin, you have to use SegWit today, right?

[01:05:22] Murch: Even if you could, you can opt out and get a similar experience as before to get all the features that are accepted on Bitcoin these days, you'd have to use SegWit. So yeah, I think I wouldn't rule out that we eventually have a block size increase, but how exactly that would happen and what the motivations would be is something that we'll probably only discover in a couple of decades or whenever that conversation is due.

[01:05:57] Vlad Costea: I think it's a bit unfortunate that the idea of increasing the block size became politicized and is associated with a different branch of the community that was maybe impatient seven years ago and didn't want to wait for things to improve. And they just said, let's just do it our way and see what the market thinks about it, which I don't think there's anything inherently evil about that. I think they tried to see if there is demand for digital cash, which exceeds the demand for store of value.

[01:06:28] Vlad Costea: It seems like the market has spoken, which use case is more popular, but it doesn't mean that this is the final version, you know, and you can also take some of their expertise because we saw what happened to BCH and how they basically imposed the limit of 32 megabytes. I mean, they're not idiots. They did understand that there should be a limit to this.

[01:06:51] Murch: I agree there. I don't think they were idiots. I think they had a different vision for what Bitcoin should be. And I still find I would balk a bit at the distinction between digital cash and store of value, because I think especially the lightning use case is a way of using Bitcoin in its digital cash. Well, I should say payments. I think Bitcoin is digital cash in the sense that it's directly peer to peer payments. Right. It has cash like privacy properties. It allows you to hold your bearer asset directly.

[01:07:29] Murch: Right. So there's a number of different definitions, what exactly constitutes digital cash. I don't think that it only refers to payments. And even if you make it about payments, I think that lightning is a way more attractive way of making payments than just scaling the block size. Scaling the block size is not something I would rule out, but I don't think it's a way of attaining an interesting amount of transaction capacity. Clearly, Bitcoin cannot have the transactions of eight billion people on the blockchain. That's just not going to work.

[01:08:12] Murch: So increasing by a small factor, even if it's a factor of 30, is inherently uninteresting. It doesn't solve the problem. It kicks the can down the road. It provides the illusion that you can just keep kicking the can down the road and you don't have to work on other more efficient, higher leverage scaling mechanisms. So I think it was sort of a deliberate choice to not increase the block size and to force ingenuity to make people think outside of the box, what can I do without increasing the block size increase that has led to a bunch of really interesting proposals.

[01:08:57] Murch: So, yeah, that ties into "Blockstream sabotaged Bitcoin in order to push Lightning," which, we know, Lightning is a huge revenue point for Blockstream. And I think that's the point where this conspiracy theory sort of falls on its face. But yes, in a way, Bitcoin developers supported putting a restriction on the network in order to make the network better in the long run, to have a more interesting vision than, oh, look, we can scale this by a small factor. No, with lightning, we can have instant payments instead of payment promises that propagate on the network.

[01:09:39] Murch: An unconfirmed transaction is an indication of your intention, maybe. But if you rely on unconfirmed payments, well. Clearly, you won't rely on a big unconfirmed payment. You'll wait for confirmations. You might rely on a payment promise from a friend that's sending you money for a coffee. But if you're making a coffee payment on a very expensive shared resource, then I think it's reasonable for that eventually to get priced out. And especially if we have better mechanisms of performing payments, like the Lightning Network. Is the Lightning Network perfect?

[01:10:16] Murch: Certainly not. Is it going to take another 15 years to get a lot better? Sure, I agree. Do we have to have it perfect right now? No, but it's already way better than it was five years ago. And I think there will be, hopefully, a bunch of new ideas people have. Other ways that we can scale the network. Maybe they tie into the introspection debate right now. Maybe they're completely new things that we haven't thought about yet. And I think we will want to scale Bitcoin 1,000x or 10,000x and not just 30x. And doing the 30x increase early on is just probably going to delay the 10,000x. At least that's how I perceive it.

[01:11:05] Vlad Costea: Yeah, at this point I want to thank the 800 plus people who have watched this across multiple platforms. There are 800 on Twitter and about 50 on YouTube. And one person watching on Twitch. Thank you guy who's watching on Twitch. I did not promote that one platform, but it's cool to see that there are people in there who are curious about this topic. And also must present the ad for Hodling.ch, which is a company that helps you with self custody. They're based in Switzerland. And if you have a lot of Bitcoin or you're part of a company that wants to own a lot of Bitcoin, then this is a pretty good solution for you because they offer consultancy.

[01:11:45] Vlad Costea: So they're going to tell you how you should manage your backup, what kind of hardware wallet is best suited for your use case, whether or not you should be using a multisig for your setup. And it's all under the confidentiality laws of Switzerland. So check out Hodling.ch or else just download the Electrum and do it yourself. But don't shoot yourself in the foot with too much complexity. Anyway, I wanted to remark something. So you mentioned the extension block. And right now there is an experiment on Litecoin, which is something that Andrew Poelstra proposed, I think in 2016.

[01:12:22] Vlad Costea: It's called the Mimblewimble extension block. And it's an extension block with private transactions. It has confidential transactions, which hide the amount being sent in and out. And it also has pruning, which is a quality of Mimblewimble. So basically it's a way to increase the block size, add privacy and also not increase the IBD too much because the data gets dumped. Of course, nodes can choose to store it as opposed to dump it. But it's a pretty interesting way to not make it too much of a big deal for node runners.

[01:12:58] Vlad Costea: And I was curious what you think about that one. And if you believe that in the post Taproot era of Bitcoin, you can see that still happening or we are way past this level of proposal.

[01:13:13] Murch: Yeah, I was actually pretty excited when the Mimblewimble proposal came out. I don't even remember seven years ago or whatever. It seemed to have a very interesting trade off on privacy versus scripting. So for example, it is extremely limited in its scripting capability. But then on the other hand, has the transaction cut through where multiple transactions, as long as all of their outputs have been spent, can sort of be squashed together so that you just see the inputs to the first transactions and then the outputs to the last transactions.

[01:13:50] Murch: So actually I thought it was pretty exciting. The movement around it seemed great. Maybe also people that hate inscriptions would find a home there because you can't do that sort of stuff. So I guess it's just a different set of trade offs. I think you mentioned an important point already. One is, even though there is the cut through and eventually the history is not retained on what needs to be processed for synchronizing, if someone cuts all of the transaction announcements and stores them, they get a similar sort of transaction graph information as in Bitcoin.

[01:14:34] Murch: But then addresses are just, I think, ECDSA keys and it's a point multiplication to do a transaction. So inherently the information that you can leak is more restricted than with the more flexible scripting system and transactions of Bitcoin. So, yeah, I think it's an interesting technology to look at and learn from. I don't think I've seen a serious proposal for Bitcoin ever to introduce the Mimblewimble extension block. I don't think that it would be easy to get consensus for it because, well, with the additional privacy, which definitely is something that a lot of people are interested in, you get other trade offs.

[01:15:26] Murch: I think with Mimblewimble specifically, it makes it harder to prove the total supply. Because you have confidential transactions, you know which coins were created and you see that they're spendable coins, but you do not see the amounts, not UTXOs. Are they UTXOs? I guess they might be UTXOs. What they have, you just see, well, UTXO got created or destroyed and you can't see the total supply. And the total supply of Bitcoin has been one of the core tenets of the Bitcoin community. And so, for example, introducing new privacy paradigms to Bitcoin might undermine other properties that community members really heavily value.

[01:16:25] Murch: And that is where the trade offs make it hard to have this sort of conversation. I think it would be hard to introduce confidential transactions to Bitcoin. However, we do have the ability to build other systems on top of Bitcoin. Maybe some of the people that are working on rollups right now will build a system that is sort of similar to tornado cash and you sort of pay into the bowl or earn and you pull out another thing later and it's not easy to connect. In a way, Lightning Network has some of these properties.

[01:17:06] Murch: When you create a channel, yes, that UTXO has a history and is associated with your prior transaction activity, but when you then make a multi-hop payment through the Lightning Network and effectuate an on-chain payment from there, it is fairly hard to track where that on-chain payment got paid from. I think if you look around, you can find some of the privacy benefits that other networks get through different mechanisms. Some of them haven't been invented on Bitcoin yet. I'm sure it would be awesome to see what people invent in the next 20 years.

[01:17:49] Murch: I hope there will be some big privacy improvements. Bitcoin is definitely not best in class in the privacy metric across all of the cryptocurrencies. I think that it has pretty decent privacy properties. There are definitely things that you can do to improve your overall privacy. There are definitely things you can do to reduce it, like address reuse or extensive on- and off-boarding from exchanges and other companies that have agreements with chain surveillance.

[01:18:31] Murch: It's hard. It's trade-offs. There's no such thing as a free lunch. If you opt into a privacy coin, you might have more private transactions on the individual transaction level, but you're part of a smaller anonymity set. Your cryptocurrency has a smaller network effect that might be unattractive to you for other reasons. For example, if you're heavily invested in the number go up use case, maybe the smaller network effect leads to less value increase and therefore it's not the right solution for you. Again, we have this grab bag of different visions that people have for Bitcoin.

[01:19:15] Murch: It's really hard to find a proposal that fits all or most of these visions. Different people have different needs. Maybe for what you're trying to do, a different cryptocurrency is better, but all of it has trade-offs. That's a long way of saying it. I'm not sure a Mimblewimble extension block would today take off very quickly on Bitcoin. It's pretty cool that Lightning, sorry, Litecoin is doing that. I haven't tried it out. I have no personal knowledge on how well it works, how much it's used. But experimentation isn't inherently wrong and we absolutely should look at other cryptocurrencies and see what sort of cryptographic schemes they come up with, what experiments they do, what their results are and learn from that and pick the cherries and port them back to Bitcoin if that's something that we can do.

[01:20:16] Vlad Costea: Is there any privacy protocol in particular that you find more interesting than maybe Mimblewimble? Because I believe there's been this resurgence of zero knowledge proofs and we've seen how, for example, there is Halo 2 on Zcash and these mixing pools that they're making contain transactions which are very close in size to those of the average SegWit transaction, one input, two outputs. And it's very interesting because for a long time it was considered that everything involving privacy is going to lead to larger transaction sizes. Of course, there is the ring signature situation in Monero and that one is the least scalable.

[01:21:02] Vlad Costea: It's the one that seems to be preferred by the market when people want to make private transactions because I guess it has more of a network effect, but it doesn't scale too much. So I think even the Monero people are trying to replace their signature scheme for something more efficient. But I guess you spend a lot more time researching privacy and you do understand that there is a necessity for Bitcoin to be private, not because people need to use it with privacy, but because you want the units to be fungible and this is an important quality of sound money.

[01:21:37] Vlad Costea: And of course, you don't want the ordinalist people to win, right? You don't want them to ordinalize the entire blockchain and have the entire community adapt that numbering system. You want units to be indistinguishable. So what do you think is a much better privacy protocol?

[01:21:58] Murch: I have to push back a little bit. I think privacy is interesting. I would not describe myself as being focused on privacy research or working on privacy improvements at this time. And I think I'm reasonably aware of a bunch of alternative projects. I think I used to know how Zcash worked, how Monero worked in more detail in the past. And I'm aware of some other privacy coins, some of which I think are not great. There's some that are better. There's some that do interesting stuff and some that are just doing dumb stuff, honestly.

[01:22:44] Murch: I think that, yeah, the three that I'm reasonably aware of and I think are interesting to at least be aware of the details are Monero, Zcash. Mimblewimble. I'm not, well, again, it's not a focus of mine. I wouldn't say that.

[01:23:09] Murch: Again, I think the main point that is a little oversimplified in many of these debates is the trade-offs and what you're willing to sacrifice in order to get better privacy. I think this is also something that should be talked more about in the context of mixing and other like coin swapping schemes and stuff like that. So, for example, on Bitcoin, if you participate in CoinJoin transactions, yes, you get pretty decent disintermediation of your inputs and outputs. But you're also putting your coins into the anonymity set of coins that participated in a CoinJoin transaction.

[01:23:51] Murch: And that may be fine for you. You might, I mean, obviously, I don't think privacy is a crime, but you're sort of labeling your coins differently, even though you get a better privacy inside of the anonymity set. You're part of a much smaller anonymity set at that point. And that might not be the right choice for everyone. You have always trade-offs there. It also costs a bunch of money to send your transactions or your coins through a bunch of mixing services to have hundreds or thousands of UTXOs instead of dozens, because you have to pay for the blockchain space to do the mixing to spend those UTXOs later.

[01:24:33] Murch: So generally, I think it would be nice if people addressed all of the trade-offs in detail when they advocate for certain modus operandi. And, yeah, I don't have a favorite privacy coin. I guess I had the benefit of discovering Bitcoin pretty early and getting excited about it very early. So I never really had a dabbling with altcoins phase. When I worked at BitGo, I was responsible for a few other UTXO coins. So I've made in my life a few other cryptocurrency transactions, but it's never really been a big interest of mine.

[01:25:22] Murch: So, yeah, I would love for someone to come up with a great privacy scheme that we can use on Bitcoin that doesn't undermine the coin supply and doesn't make it easier to have unnoticed inflation. I think that it will be a hard conversation with the likes of big number go up proponents heavily pushing against any privacy features. I think that the ecosystem has evolved a lot with Bitcoin now being traded on ETFs and things like that. There's going to be other new needs that also have some economic power to advocate for their use cases.

[01:26:10] Murch: And, yeah, I don't think it's too late to add privacy features to Bitcoin. I think it will be difficult to add it at the base layer. And I think it will probably be more built into second layer protocols or UTXO sharing mechanisms like Lightning or other hopefully additional mechanisms that we will develop and build.

[01:26:40] Vlad Costea: Something that I find interesting in Bitcoin is that it has this built in fungibility mechanism, which means that once some coins were part of the transaction fee and they go to the miners, they get reissued as fresh Bitcoin and every link to a previous transaction gets erased. So if anyone wants to use Bitcoin privately, they should mine because that's the best way to get Bitcoin that's fresh, that has no history and can get its own identity after the first transaction.

[01:27:14] Murch: Yeah, I think that's a fair point.

[01:27:16] Vlad Costea: But it would also be nicer if we had more mining decentralization, which I'm not sure how we can achieve it at this point. It's got to the point where it's very industrial.

[01:27:29] Murch: Yeah, I think that's one of the things that latently keeps me awake at night is there is too few people that are building block templates. And especially the dynamic around what Bitmain is paying for mining payouts has skewed the market away from decentralization. Yeah, I don't have a good solution. I know that Stratum v2 is coming. I am not entirely sure how easy it will be to make mining pools adopt that. And there's new problems with that. For example, it makes it easier for miners to earn money from a mining pool without contributing actually valid work because they might include fewer transactions than other miners or they might.

[01:28:23] Murch: So there's ways to fix that with additional vetting of the templates that you're being sent and statistical analysis of this user contributed this much hash, right? They should have found a block by now or something, which of course can be bad luck, but at some point becomes statistically tenable that it is on purpose. But, you know, there's some research happening. I don't think we have found a silver bullet. I hope mining decentralization gets better. If it gets worse, that might make Bitcoin very uninteresting because we lose the censorship resistance property.

[01:29:10] Murch: I've been spending some time lately discussing timewarp attacks and similar timestamp fudging attacks on Delving Bitcoin and in the context of the Great Consensus Cleanup proposal. It's not that these things are right there and easy to achieve, but if a small number of parties controls the majority of the hash rate, it is accessible to them. And I think we, I guess the... The point is, if we all own the Bitcoin network together and we all decide what the Bitcoin network should be in the future, we also have to be constantly vigilant and see what people are doing.

[01:29:57] Murch: In a way, I guess I applaud the people that think Bitcoin Core is compromised in the sense that they are putting in some effort to see what's going on and vetting it. I think their conclusion is incorrect and they should maybe dig a little deeper and not just look at a few screenshots that someone took out of context. But the direction is right. We need to watch out what's happening in the network, whether that matches our values and our vision for the Bitcoin network. And we have to contribute to the process if we want to be heard.

[01:30:34] Murch: And I guess the ordinals haters are doing that. They're very effective at being loud.

[01:30:43] Vlad Costea: I'm happy that I got to a point that is right up your alley and there's something that keeps you up at night because I felt like during the episode, I pushed you a bit to talk about topics that make you uncomfortable. But I guess this is something that comes up a lot on Bitcoin Stack Exchange. And yeah, there should be more miners. If you're listening to this, think about ways to mine. It's important.

[01:31:09] Murch: There's also another thing that I've been talking about with people a bit lately, which is, yes, mining has gotten very industrialized. And this has led to people running mining companies that are not directly heavily invested in the Bitcoin movement and idea. They sort of see it as an operations research problem where they have these cost points like shelter for the operation, electricity, hardware requirements, these sort of predictions on how the electricity market will develop. And we're getting revenue in Bitcoin to this amount. And now it's just a matter of management and business to find out how these things happen.

[01:32:02] Murch: But miners also have a sort of unique role in the protocol development sphere, which is it is way easier to adopt a protocol change if you collaborate with miners to do it. Because if a majority of the hashrate enforces a new protocol rule, eventually the network will coalesce on these new protocol rules. Because other miners that [unclear: ignored] the rules by including transactions that should be invalid according to the new rules will get reorganized and ousted. So I often see the criticism that soft forks can be done by miners by themselves, or we let miners decide whether or not a soft fork succeeds.

[01:32:53] Murch: And I think that, again, there's a little more nuance there in the sense that I think the network adopts a soft fork. But the miners can help enforce the adoption of the soft fork by signaling readiness for enforcing the soft fork. And then once the rules are active, enforcing the rules. And yes, we could do it without the miners, but that would lead to more unknowns, more reorgs, more fighting on the blockchain, whether or not something is valid. And it would make it harder to accept payments or to rely on payments.

[01:33:33] Murch: We would require more confirmations until we can be confident that something is actually part of the best chain on Bitcoin. So really, it is sort of an alliance where miners in their role as the authors of blocks get to... [unclear: the process] as a mechanism to make it safer. And yeah, I think a lot of people have PTSD around SegWit with the fighting, with the big schism, with the diverging interests of especially Bitmain and, well, the rest of the Bitcoin network. And I see that sort of bleed into our decision-making today regarding protocol development and makes it hard to just have safe soft fork activation. Because, currently, a UASF is a lot less attractive from a network transition standpoint because it would probably work. But the communication around it would be more difficult and it would be a lot messier.

[01:34:48] Vlad Costea: This also goes back to the idea that I think too many people got the impression that since 2017, when there was a UASF, that's going to be the only way we're going to activate soft forks from now on. And we don't need miners. Miners are sort of like our servants that fulfill a task and they collect the incentive for it. But there was always this disconnect between miners and validators, at least since 2017. And to me it's ridiculous because you can always spin up more nodes, right?

[01:35:25] Vlad Costea: It's not a democracy.

[01:35:27] Murch: Well, yes. Bitcoin is not a democracy in the sense that we have no way of really doing one user, one vote. There is sort of an economic majority maybe as a theoretical concept of people that have economic interests and choose to behave on the protocol layer in a way to enforce their interests that may or may not be able to force other participants in the network to do something. I think there's also quite a bit of rewriting and romanticizing around the SegWit activation of what exactly happened.

[01:36:12] Murch: There was a threat of a UASF. The UASF code was never run in the sense that it enforced anything. The miners saw the UASF and they activated SegWit before the date that the UASF would have activated. So I think this is still a useful tool in our toolbox. Just the ability of the network, the overall user base of Bitcoin to express their demands to miners in the sense that, look, we are buying the coins that you're mining. If you don't mine the blocks that we want, we will no longer buy your coins.

[01:36:57] Murch: But I don't think that it is the first tool that we should use. It's a messy tool. It is probably a tool that will only work once. And there's absolutely no reason to burn it on just some regular software that everybody wants. So while it is working, I think it would be more pertinent to work with miners, which are one of the shareholders in the Bitcoin ecosystem. They have immense investments in mining hardware, in long running electricity contracts. They've built a business around being of service to the Bitcoin network and getting paid for it.

[01:37:39] Murch: So how about we get them to participate in the conversation, not just run this as an operations research project, but keep track of what's going on in Bitcoin. Voice your concerns, learn about the concerns of others, be part of the conversation. There's a few miners that do a good job of that. There's some that have research positions that engage a lot with other participants in the Bitcoin network and keep abreast of research and development. There are also some that seem to be completely disintermediated from the Bitcoin conversation.

[01:38:23] Murch: I'm hoping that we can have more of a conversation again with miners and establish a line to what they need, what they want, and where we can also express what we need and what we want as the rest of the Bitcoin ecosystem. So, yeah, I don't know. I think service, they're definitely providing a service for the network and getting paid for it. I don't think that treating them as servants is going to be helpful in any means.

[01:39:03] Vlad Costea: I also believe that Paul Sztorc, with his advocacy for drivechains, has been very effective in reminding people what miners can do. Because they can form an economic majority and decide that they do want to activate a soft fork and the nodes can, in fact, hard fork and decide that they don't want to follow that majority of miners. But they're going to be in a minority, which might lead to a situation that's economically unsustainable. So there is this game theory that's being shaped and there is stuff that miners can do if they collude, if they have a majority, and it can be against the will of the users.

[01:39:48] Vlad Costea: It's just that miners so far have been pretty ideologically aligned with what the users want.

[01:39:55] Murch: Yes and no. I think that one of the core assumptions on the whole Bitcoin system is that the majority of the hashrate is honest and honest in the sense of self-interested honest. Like, maybe with a modicum of long-term interest, but they're doing what is good for themselves and even that should be enough. As long as not more than the majority of a hashrate, conspires against the rest of the Bitcoin network, it should result in a stable system. So generally there is a property that if a majority of the hashrate becomes malicious, I think Bitcoin in itself has drastically reduced guarantees on what we can expect from it.

[01:40:48] Murch: I think at that point very likely the system is broken and permanently uninteresting. So if your system breaks when a majority of the network is malicious, I guess you sort of have a similar security model as Bitcoin itself. But I wouldn't say that I have looked at drivechain any time lately. My understanding was that it wasn't completely clear to me whether actually a majority of the miners has to be malicious for a drivechain to fail or it is sufficient for a majority of the miners that participate in a specific drivechain to be malicious whereas the rest is apathetic.

[01:41:48] Murch: So anyway, I haven't looked at drivechains in a long while. I don't have strong opinions on it. It just doesn't seem to have that much of a momentum right now. So I don't really have much of a strong opinion.

[01:42:07] Vlad Costea: Yeah, we made a list of 10 talking points and I can see that it's been almost two hours. We have more than 1000 viewers live and this is impressive. I'm not sure if they're right now with us or they just jumped in and dropped out at some point. But I have this proposal to you. How about we tackle two more of them? And I want to go for pros and cons of zero-conf, which I think is a big talking point. It's probably what John Carvalho is waiting for us to talk right now.

[01:42:36] Vlad Costea: And the other one is, okay, tail emission. How about this?

[01:42:44] Murch: Sure.

[01:42:45] Vlad Costea: I think Saylor narratives and some of the other stuff that we established is not as important.

[01:42:54] Murch: I would agree.

[01:42:56] Vlad Costea: Exactly. So let's start with zero-conf. Do you want to set the stage for...

[01:42:59] Murch: Yeah, sure.

[01:43:01] Vlad Costea: So what is it and how would you describe it? Because some merchants were accepting these transactions without any confirmation, believing basically in the good faith of the sender. And they were providing their gift cards or their whatever instantly, believing that the transaction is going to get confirmed in the future.

[01:43:21] Vlad Costea: And with the recent activation, not activation, it was an inclusion of RBF by default in the Bitcoin Core client. And it seems like there's less of an optionality right now than it was before. So how would you comment on this? What do you think? Do you think it's beneficial for Bitcoin overall to be able to double spend a transaction that's stuck in the mempool or to cancel it if you realize that you didn't really want to send that transaction because it was a scammer or something?

[01:43:54] Murch: Okay. I think we need to go back to the start of Bitcoin and what Bitcoin actually promises and what problem it solved. So one, I think many people are aware that digital cash was a cypherpunk dream for several decades before Satoshi Nakamoto made this proposal. And essentially all of the projects failed on two different ways. Either they had a central point of failure and got shut down, or they couldn't solve the double spending problem where it wasn't possible to prevent that someone spent the same coins twice.

[01:44:34] Murch: And what does it exactly mean to spend the coins twice? It would mean that they first can spend them in one way in a manner that the counterparty has already given up the service in exchange and then spend it again. And so the way that Bitcoin solved the double spending problem was that it introduced an absolute order of transactions by publishing system updates in a regular cadence, the blocks. When a miner offers a block and adds it to the blockchain, they are proposing to the Bitcoin system, here is the new status quo of the network.

[01:45:23] Murch: This is the ledger of balances that exists now. And these transactions have been added to the journal. The idea is now, as more miners build on top of that blockchain, it becomes probabilistically more difficult to replace and rewrite the history. And as more blocks get added to the blockchain, we can be increasingly confident that this transaction is reliable and cannot ever be changed again. That's at least I think how it was described in the Bitcoin white paper. The white paper then had some statistical calculation on how likely it would be to replace blocks with a certain amount of hashrate, which actually I think has a mathematical error.

[01:46:15] Murch: And from that, I think the six confirmations recommendation was derived that has been a talking point in the Bitcoin community for 14 years. You should wait for six confirmations, then your payment is reliable. Now, I think as more hashrate and mining got more professional and Bitcoin got used more, I think this sort of watered down to depending on how much you are receiving, maybe one confirmation is enough, or for bigger payments, you might still wait for six confirmations, and so forth. Also, people started saying, hey, but if I want to make a really small payment and I immediately want to [unclear: make a provider service] in a brick and mortar store or online shopping, I want to be able to immediately have instant payments, essentially.

[01:47:09] Murch: And they started to look at unconfirmed transactions, essentially a promise by a transaction, what they intend to happen in the future and said, this is good enough for me. And I think that totally makes sense for small amounts and adds to benefit that you don't sit around for 20 minutes for your coffee to arrive because the payment hasn't gone through yet. But it's, on the one hand, I think inherently something that will be priced out of the base layer because as block space gets more contested, people are going to be able to pay more for, or will have to pay more for their Bitcoin transactions to make it into Bitcoin blocks.

[01:47:55] Murch: That will mean that larger payments inherently have a smaller relative fee compared to the amount of money that they move and a coffee payment will not be viable on the blockchain in the long run. So it's sort of, for different reasons, is a use case that I don't perceive to have a long-term future. In the last year, we have not seen the block, sorry, the mempool to clear at all. For very large parts of the last year, fee rates have been extremely high to the tune of several dollars for a small single input transaction.

[01:48:37] Murch: And it just doesn't make sense if you're buying a cup of coffee for, I don't know, $5 these days, to pay $2 in fees. We do have some tools now that work better. I think that the Lightning Network works reasonably well in some scenarios. It's not perfect. It's not a silver bullet that solves all the problems. But for small payments especially, I think it's a very effective solution. I know it's hard to manage your channel capacities. It's definitely very hard to run your own routing nodes. There is also a centralization issue here around Lightning or liquidity service providers, Lightning service providers.

[01:49:24] Murch: I never know exactly what LSP stands for. And is it the best solution for everything? Is it the final solution for all the things? Certainly not. I just don't think that small payments in the long term will be on the blockchain. There is now, additionally, the question about replacements. In a market where we bid on block space and there's always enough demand for all of the block space to be sold off, there will be more requirements for replacements and being able to increase your bids. We've had BIP 125 opt in RBF for, I think, eight years now.

[01:50:09] Murch: And I think a large portion, I haven't looked at numbers, it was certainly around a third or so of all transactions that were flagging replaceability. And with the shift, there was users starting to demand that replacements should happen always because it would make it easier for people that send a transaction before they knew that they had to opt into replacements to replace them. And now seeing that the network actively is doing a lot of full RBF replacements, I think the reliability of unconfirmed transactions has shifted further.

[01:50:51] Murch: I'm not saying that it's impossible to build heuristics and intelligence to assess whether payment is likely to be reliable or not, even while it's unconfirmed. And I know that businesses have done that successfully. I just think that there never at any point really was a promise by the Bitcoin network that unconfirmed transactions are going to be reliable or should be relied on before they get included in a block. And I think that we've further moved away from this idea that was more viable when block space was abundant and Bitcoin was a lot less valuable and payments were smaller that happened on the Bitcoin network.

[01:51:37] Murch: So yeah, I think that zero-conf with its immediate effect of payment, as long as you are aware that an unconfirmed transaction is basically a payment promise and is easy to replace and not protected by the network, our consensus mechanism is after the mempool when we build blocks, not in the mempool. I don't think that it is reasonable to expect that people converge on the same mempool and that these unconfirmed transactions in any manner need to be honored. That's just going to change a lot about how Bitcoin works in many different ways that I don't think is worth building out or making the trade-offs for.

[01:52:24] Murch: So yeah, unconfirmed transactions are unconfirmed, they're payment promises, the money still belongs to the sender even though they promised it to you. You can of course interact with that unconfirmed transaction and build a CPFP on top of it in order to make it more attractive to include it. You can therefore maybe even counter replacement by resubmitting your own transaction with a high fee rate child transaction and therefore enforce a payment that in that case maybe a perceived attacker was trying to cancel. But there's no guarantees from the network that this use case is supported and please don't claim that there is.

[01:53:16] Vlad Costea: I think that was possibly the best explanation I've heard of this full RBF conversation, which is pretty lengthy and tends to get tense when it comes to some merchants like Bitrefill that for a while accepted zero-conf Bitcoin. And then they basically presented this argument that in the absence of zero-conf BTC, users are going to switch to something else for their payments because they're impatient. They don't want to deal with a situation where they must wait for a long time for transactions and they might also have to RBF their transaction if there's a lot of activity in the mempool.

[01:53:59] Vlad Costea: So possibly a use case that was once popular has been partially eliminated by integrating this. But at the same time, some users who maybe don't know how to use Bitcoin or are making some mistakes, they get a second chance. They can either cancel their transaction when they realize that they sent it to the wrong address or they can decide to bump the fee and send to the same address.

[01:54:32] Murch: Right. Yeah, I think it just makes the interactions with the mempool generally more flexible and dynamic. I think it makes it easier to express the priority that you want to give a transaction by, for example, RBFing your transaction several times in the mempool to make sure that it gets confirmed by the time that you need it confirmed. If you want to make a payment in the next hour, you might be able to put it at the bottom of the second block from now, the projected second block.

[01:55:06] Murch: And as more transactions get added in the next hour or maybe there's a slow block, you might choose to bump it to the bottom of the first block. And then maybe you need to bump it up again to make it go into the first block in order to achieve that deadline of getting a confirmation within an hour. And in a way, I think RBF makes a ton of sense in the context of how we purchase block space and making it easier to express that and also all the work that Gloria Zhao has done on package RBF, some of the work that we've done here at Chaincode Labs in the context of cluster mempool and making it easier to assess different transaction packages against each other for incentive compatibility and whether or not to accept replacements.

[01:56:03] Murch: I think all of that will in the long term benefit the network and make it easier to get the outcomes that you expect to be able to pay for the outcome to bid on the block space that you want. And yeah, as we said, the block space market has shifted quite a bit in the last year. The inscriptions and ordinals and runes and BRC-20 nonsense has increased the mining revenue temporarily a lot. And we've had phases in which the mempool was churning a lot harder than we had been used to.

[01:56:44] Murch: And I think that in the future of full RBF, especially once cluster mempool hopefully rolls out, we will have a much better user experience in regard to getting confirmations within the time that you're anticipating.

[01:57:02] Murch: Okay. [unclear: Tail emission? Yes, tail emission, sorry.] Did you have a follow-up question, sir?

[01:57:06] Vlad Costea: No, I don't. I think it was pretty comprehensive. The listeners can make up their own opinion. Of course, there are going to be someone who says zero-conf is safe and is perfectly fine and I want to use that. There are other money networks that enable that if you're interested. There's Litecoin, there's BCH, there's something else.

[01:57:26] Murch: Yeah, we just can't do everything. We're trying to build something new. We have to make trade-offs. We do not live in a world where we can wish for every single thing to be possible. And the question is just sort of what is the best way forward? I think a lot of us that contribute to Bitcoin development think a lot about trade-offs and priorities, projects, what to spend your time on. Especially if you're on a grant or in the fortunate situation like me where my employer basically just requires that I benefit the Bitcoin network, that I work towards making Bitcoin better.

[01:58:20] Murch: And I have a lot of freedom in what exactly I spend my time on. I think we all need to choose what we spend our resources on and what we prioritize. And a lot of that is what is your vision for the Bitcoin network and what do you prioritize? And yeah, we can't do everything and we certainly can't satisfy two conflicting demands, unfortunately.

[01:58:50] Vlad Costea: Okay, so tail emission. I think it comes from other coins. Monero is the most famous one that implements this idea. And Peter Todd brought this into conversation in Bitcoin and said that there is no way that this 21 million inflation schedule is going to work out for securing the network. And we might have to look into tail emission and he made this assumption that given the amount of coins that were lost, we're never really going to have real inflation.

[01:59:23] Murch: Yeah, I think I remember reading this. This is a blog post from a year or two ago. And I think there's a bunch of assumptions there that could be substantiated a little bit. I do think that there is a good core point that is worth addressing though. So the block subsidy is obviously dropping off exponentially. It started at 50 Bitcoin every 210,000 blocks. It halves and we just had a halving in April and it dropped to 3.125. Is it? Yeah, 3.125 Bitcoin now. So there's often this wonderful meme about Bitcoin subsidy ending in 2140, which I think is an entirely overstated date because as the block subsidy is dropping exponentially, the block reward will drop to below one Bitcoin around 2030.

[02:00:30] Murch: Sorry, not the block reward, the subsidy. And so to clarify terminology, the block reward is the combination of transaction fees and the block subsidy. The subsidy is the amount of new coins that are created. Transaction fees obviously what people bid on the block space that is collected by the miners and together that's the block reward. So the subsidy will drop below one Bitcoin per block around 2030. And I think it's 2032 or whatever, but the overall amount of Bitcoin that gets mined drops below one Bitcoin in sum around 2100, like around the turn of the next century.

[02:01:18] Murch: All of the remaining block subsidies that will be paid out to blocks will be less than a single Bitcoin in sum. So frankly, 2140 is completely uninteresting because the four years before that we will earn one Satoshi in new coins mined per block. The four years before that it's two Satoshis per block subsidy and so forth. So really the block subsidy will go away in a meaningful sense of it in like 40 years, not in 120 years. And so I understand the concern about the block subsidy going away as the main mechanism to pay for mining.

[02:02:02] Murch: I think that we have a little more time because right now the subsidy is 3.125 Bitcoin. Very briefly for a week, we had a number of blocks where the transaction fees were higher than the block subsidy around the halving with the runes launch, obviously. And that went away. And 3.125 Bitcoin is equivalent to paying 312.5 Satoshis per vbyte on a full block. So fees for a long time had been, I think, around 100 Satoshis per vbyte for at least a couple of months. That was equivalent to paying one Bitcoin in subsidy per block.

[02:02:51] Murch: So I think for all my disinterest in inscriptions and runes and so forth, I think it does help demonstrate that there is demand for block space to the tune of the subsidy in a few halvings. And as the subsidy keeps going down, the amount of fees that need to be paid in order to replace the subsidy also goes down exponentially. So I anticipate that around, I think, 2040 or so, extremely likely, as long as blocks are full, I should have looked that up exactly, but I think it's like end of 2040 or so, where the block subsidy drops below one Sat per vbyte transaction fees.

[02:03:36] Murch: So as long as blocks are full, we will collect more in transaction fees than block subsidy, and the block subsidy will be less and less relevant. So I think there is a need for research and more work on what exactly happens to the incentives of the Bitcoin system when the subsidy falls below the transaction fees. I think that anti-fee sniping becomes more important so that you are not able to attack the previous block height and include more unconfirmed transactions that were very juicy, that were intended for the next block into the previous block in order to increase the fee that you can collect from re-mining the previous block, or at least the expected revenue, from re-mining and reorganizing the current best chain tip.

[02:04:28] Murch: So there's, I think, some need of work in making anti-fee sniping more adopted. There's some need of work in researching whether or not we can expect that there will always be block space demand in excess of the block space production, like it has been in the last 18 months or so, since February last year, except for a few blocks. So if we always have a backlog of transactions, some of the attacks that have been described in academic papers that Bitcoin is unstable, if there is no subsidy, go away, because this paper famously assumed infinite-sized blocks and that the mempool would clear every single block.

[02:05:17] Murch: Which I don't think is a valid assumption, given that we had just a huge discussion about how having a hard-fought block size increase would be a difficult conversation. I think we can rule out infinitely-sized blocks. And so in the case that we always have a backlog, the dynamic around incentives changes a lot. I think that the subsidy has a lower importance in that case. I don't think that the problem goes away completely. I would agree with Peter Todd's assessment that if we had a permanent subsidy and a tail emission, it would be academically much easier to reason about the security properties and incentives of mining on the Bitcoin system.

[02:06:07] Murch: I don't think that that is a sufficient reason to introduce a tail emission that breaks one of the core memes of the Bitcoin movement where it has a fixed supply that had been decided before the first block was mined. So before we throw the finite supply of Bitcoin overboard, I think we have a few more years, a few more halvings in which the subsidy is plenty to not allow for big concerns around instability of mining due to low transaction, sorry, block rewards. And we should keep our eyes peeled, watch it, do more research, look at the dynamics in the next maybe 12 years, three halvings.

[02:06:57] Murch: And even at that point, if I calculate, right, that's 1.6, 0.8 and 0.4 block reward, that's still 40 sats per vbyte in block subsidy, artificial block reward compared to transaction fees that we just get in new coins to incentivize mining. And I think at that point, hopefully we're better informed. We have a better gauge on how much block space demand we can rely on. Maybe at that point, block space is so expensive that the subsidy has been already overtaken by transaction fees and transaction fees are the dominant part of rewards.

[02:07:39] Murch: And maybe the concern is gone altogether and we will never implement a tail emission. And then to also break a lance for tail emission, if the tail emission was fairly small, it would probably definitely remain under the amount of lost coins because people are speculating that three to five million Bitcoins or even more have been lost permanently. So being under 21 million in liquid Bitcoin would remain true, even though maybe on the books more Bitcoin got created. And a tail emission with a permanent amount is still disinflationary if the amount of lost coins is in excess, which was something that Peter, I think, mentioned in his blog post as a concept, which I don't think was completely established.

[02:08:34] Murch: Like people get better at not losing Bitcoin with all the tooling that we've built around it. I think people get better at not losing assets that have increased in value significantly. Like if you keep track of your Bitcoin better, you're not going to lose them as easily. Right. So, yeah, there's a lot of assumptions around exactly what rate you could create new coins without increasing the amount of liquid coins. I think there's ways of implementing a tail emission that doesn't break the disinflation. And I think it would give us many, many years of tail emission before we actually go past the 21 million limit because there's also just actually a little less than 21 million Bitcoins in the reward schedule.

[02:09:25] Murch: And altogether, I hope that we just never will need a tail emission because block space demand will be in excess of the subsidy before that becomes a relevant discussion. So let's look at it for another decade or so. Keep it in mind. Keep thinking about what the best solution is and if it's still a concern. Honestly, 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. So, yeah, let's say it's not keeping me awake at night.

[02:10:02] Vlad Costea: Well, I've always regarded this idea of tail emission as partially trolly in the sense that Peter is saying unless we make this work and we're going to have enough transaction fees, this is what we have to do to save the network. Because there's also the nihilistic perspective of it that says if it doesn't work, it means it was never meant to work. As there are two elements that are part of the social contract. On one hand, you have the 21 million supply limit that many people, I guess it's the reason why a lot of guys got into Bitcoin in the first place because they perceived it as limited in supply.

[02:10:41] Vlad Costea: Not just scarce, but limited in supply. And there's also this idea that Satoshi described in the white paper that after the inflation cycle is over, the network is going to be secured entirely by transaction fees. That's part of the design. That's I guess the biggest uncertainty and the biggest gamble that Satoshi has ever pushed forward. And basically he put that heavyweight on our shoulders right now. And there's also that HODLing is using meme, which I think is very silly when people say, you know, when you're holding your coins, you're actually using them because you're preserving the use for a future time.

[02:11:24] Vlad Costea: You're not really helping the security of the network right now. And if there's not enough security right now, you're running into multiple risks, including not being able to move your coins around reliably.

[02:11:38] Murch: I'm not an economist. I, so take this with a grain of salt. I think I'm sympathetic to the argument in the sense that if you're holding your coins, you're expressing the expectation that they will have value in the future, which helps establish the market price and making other coins more valuable increases the mining reward. So maybe that's a little roundabout, but absolutely. I think that keeping some Bitcoin in the expectation that it stores wealth for you is a use case for Bitcoin. I don't know if I'm using exactly these Bitcoins right now.

[02:12:23] Murch: I think there's semantic games to be played. I do think that holding wealth in Bitcoin has been one of the use cases that has very significantly contributed to the success of the Bitcoin network. And I don't think it's a silly meme.

[02:12:45] Murch: Spicy towards the end.

[02:12:47] Vlad Costea: Yeah, it's funny. We can disagree on that one. I do believe that you need to build markets. You do need to transact. You need to onboard more people. You need to increase the demand for it. You don't just assume that there will be future demand. You have to use it.

[02:13:04] Murch: Yeah, I agree on that, too. I think that we would lose interest in Bitcoin and we would probably stop holding as much of it if we weren't also being able to use it. So I think just saying that I think that holding Bitcoin is a way of using it doesn't mean that we shouldn't use it in other ways and build out other use cases. I think that it is obviously more use cases lead to more interest in it. I'm not trying to pick a side here or anything.

[02:13:41] Murch: I just don't think that we should dismiss holding as a use case.

[02:13:48] Vlad Costea: Okay, Murch, you are the champion of the Bitcoin Stack Exchange. If you ever post a question there, it's likely that you're going to get Murch to reply to you within one business working day.

[02:14:01] Murch: And I would like to caveat that I've only written a little less than 2,000 answers. There's over 30,000 questions on the Stack Exchange. Not all of the topics are stuff that I feel an expert on or have an easy answer to. But yes, I do edit a lot of them. I'll probably see all of your questions probably within a business day. But...

[02:14:25] Vlad Costea: I mean, 2,000 in 30,000 is almost 7%.

[02:14:31] Murch: Sure.

[02:14:33] Vlad Costea: So for one human being to be able to do this is really impressive and admirable. I was going to ask you, where can people keep up with what you're doing? Look at your work, maybe also ask you questions if they have any.

[02:14:47] Murch: Well, I would love for more people to ask questions, good questions on Stack Exchange, like the things that have been bothering you, that you are trying to build out on. But also, I would love for a few people to come in and adopt their own projects as topics on Stack Exchange. If you're contributing to a specific wallet and there's some users that ask questions about your wallet on Stack Exchange, maybe take a look at what's tagged with your wallet's name and answer some of them. If you're a privacy researcher, maybe take a look at the CoinJoin topics and the mixing topics and whatever and add your answers there.

[02:15:29] Murch: If a few more people adopted their topics, brought some interesting questions, like questions that haven't been answered on Stack Exchange yet, because we do have a big body of topics that you can easily find if you Google. And I would also encourage you to check whether there's good answers to your questions already, because a lot of them have been answered. But I know, for example, that a bunch of the Lightning developer questions kept getting answers in Slack and so forth. And now we're missing almost the entire body of conversation about Lightning setup, running nodes, node maintenance, protocol development in Lightning, because they just never made it to Stack Exchange.

[02:16:16] Murch: So if you have topics that you heavily work on, that you're an expert on, you can absolutely ask your own questions and immediately answer them too, to seed them into Stack Exchange. Because one of the great things about it is it's a very visible and somewhat permanent archive of topics. So please contribute to this body of knowledge. I would love more people to participate in that. Other places that you can find me, I've been contributing to the Bitcoin Optech group for a while. Notably, Dave Harding, chiefly, and a few other people work on putting out a newsletter every week.

[02:16:57] Murch: I used to contribute a lot to that, but now I'm contributing more just to the podcast recap that we do every week. Currently on Tuesdays, Mike Schmidt and mostly I, sometimes other people, go through the newsletter and discuss all the topics in the Optech newsletter, add a little color. We invite a bunch of guests that have contributed to the news items or that have worked on the pull requests that we cover and ask them questions. And so if you're technically involved, I'm sure you're aware of it already, but please check out the Bitcoin Optech website.

[02:17:37] Murch: That's bitcoinops.org. Check out our recap. It's usually around an hour per week if you prefer audio over reading. And there's a lot of technical stuff in there. And something that a lot of people miss is a lot of work has gone into indexing all of the topics that were mentioned in the newsletter. So there's a topics index. And if you look for a topic, you can find all of the news items where they appeared in the newsletter in the past, I think it's like three, four years now.

[02:18:11] Murch: And they're all cross index. You can very easily do research on the past of proposals, ideas, how things came along. There's a series on Taproot, on Mempool. Yeah, so if you're writing stuff or if you're trying to get up to speed on specific topics, check out the topic index in the Bitcoin Optech website. And yeah, other than that, I'm at Chaincode Labs. I co-host the New York BitDevs. So if you're in town in New York, the last Thursday of the month, come join us to talk about Bitcoin development news.

[02:18:53] Murch: And yeah, I think that's that's most of the things. Oh, and I contribute to Bitcoin Core a bit.

[02:19:02] Vlad Costea: Yeah, I was on Twitter yesterday, I think, and I listened to the conversation about hardware wallets. It was led by Matt Corallo, but you're also moderating. And for me, it was sort of this way of understanding how you're presenting arguments. I was basically doing an analysis of your style and it was enjoyable. So if you can listen to this Optech newsletter, which is available on Twitter, you should.

[02:19:31] Murch: And we publish on a bunch of different platforms. It comes in Spotify, it comes in, I don't know all of them, but there's a list of them on our website. You can also just listen on it on Twitter. My preferred way is to catch it in my podcast app. Well, I don't listen to my episodes, but for example, when Dave Harding jumps in because I'm out of town or whatever, I'll catch it in my podcast app.

[02:19:59] Vlad Costea: Murch, thank you very much. You're a treasure and I hope that I made the best use of your knowledge. And if I haven't, I'm really sorry.

[02:20:08] Murch: Yeah, don't worry. No, it's been a great conversation. I'm also happy. Look, a lot of the podcasts are just sort of playing the hits and going over all the memes. I really enjoyed that you're asking the hard questions and asking about the other things that we also should be talking about and thinking about. So I hope some people listen to this and hopefully they realize that we people contributing to Bitcoin Core, we're regular humans just trying to do good, to contribute to the project, to build a good digital cash system.

[02:20:47] Murch: Building decentralized systems is hard. It's messy. There's no dictator. So all of it is like, hopefully mostly meritocratic, but obviously also people just like working with each other. So they might work a little more with each other when they get along. So anyway, if you're interested in contributing, we also have a ton of resources on Chaincode. learning.chaincode.com has some research. I proofread Mastering Bitcoin, third edition, for Dave Harding last year. I think this is an excellent book into a technical introduction. And I think Kalle Rosenbaum came out with Bitcoin Developer Philosophy as a book.

[02:21:36] Murch: If you want to understand more what concerns keep Bitcoin Core contributors awake and what they're thinking about and how they are trying to contribute to this open source world.

[02:21:48] Vlad Costea: Didn't he also write Grokking Bitcoin, which is, I think, one of the greatest books?

[02:21:55] Murch: He did. He did. Yeah, Grokking Bitcoin. I want to give another shout out. I've been reading Resistance Money and I think it's a really fun book and one that takes the Bitcoin skeptics serious. So if you have been talking to friends or family that would like to pick up a book that actually looks at it somewhat fairly, I've been enjoying that book.

[02:22:23] Vlad Costea: Oh, yeah, Andrew Bailey, he did a very good job. And I think it's one of the few books that is peer reviewed and that's something to which we should all aspire.

[02:22:32] Murch: I also, they contacted me and said that they had been using Stack Exchange a lot in their research and asked me to let them know if I find any mistakes. I have not found a mistake yet up to chapter nine. So chapeau to three philosophers writing a book about a computer system. I've been really enjoying it. All right. I think that's enough shilling for today, huh?

[02:22:57] Vlad Costea: Yeah, it is. Thank you very much, Murch. Thank you, Mr. Sponsors, for allowing this to happen. And keep listening because I enjoy what I'm doing. I like taking the contrarian side sometimes just to prove people that they might be wrong or I might be wrong. It doesn't matter. But it's not nice to embrace cultish behavior without thinking for yourself. And for me, the Bitcoin journey is all about trying to think for myself and questioning whatever I think is worth questioning. So thank you very much, Murch.

[02:23:31] Murch: Yeah, thanks for having me. It was a pleasure.