Great Consensus Clean up, MEVil and LN isn’t dead - Steve Lee and Matt Corallo

Hi, you're watching Stephan Livera podcast brought to you by Swan Dot Com. Today, we're talking about a range of things in Bitcoin. Many people have this idea of Bitcoin as this perfect and pristine thing, but the reality is there are always bugs that need to be fixed. And actually, today, we're talking about the great consensus cleanup, which is an idea by Matt Corallo from 2019, but, it's got some momentum again, and I wanted people to hear a little bit about it. So Matt Corallo and Steve Lee joined me to talk about this. They I'm working over at Spiral, which is an open source Bitcoin, contribution organization, and so we talk about the great consensus cleanup, as well as MEVil instead of this idea of just M-E-V, what is it? Why should we use the term MEVil instead? And we also talk about this idea of the supposed death of the Lightning Network, and is it really dead, or what is the right way to think about that? These are some of the questions that we discuss with Steve Lee and Matt Corallo. On to the episode.

Steve and Matt, welcome back to the show.

Thanks for having us on. Yeah, thanks.

So lots to cover today, I know, you know, we've got a lot of things. We'll see how many things we can cover today in the time we have, but I was keen to chat with you guys about, the great consensus cleanup. I know Matt, this is your idea from, I believe it was 2019, but, maybe there's been a bit of a- You know, the idea has, you know, has been cooking in the background a little bit, and now there's a bit more discussion about it. so, you know, maybe let's just start there. Why, why, you know, why's the idea coming back up now? Let's start with that.

I'll, I'll start. I mean, I actually just, did a tweet thread a couple months ago, what, reviving it from, yeah, five years ago. I guess what inspired me to, to do that is, some of the recent non-standard transactions that are being mined and sort of the motivations behind that and possible worries there. that, and I think just a, a few other, a few other reasons motivated me to, to, to do it. I mean, another reason is that in the past five years, think about the im- Influx of new Bitcoiners who have probably never heard of the Great Consensus cleanup or any of the, the bugs that exist in Bitcoin. So it's good just as not only a refresher for the one percent of us around five or ten years ago, but all the new folks. So that's why I brought it up. And then, and then, I learned after that that Another open source developer, Antoine Poinssot, i-has been spending time researching this, and he, he himself also was interested in reviving Matt's Proposal, revisiting it, see if it still holds, see if it can be improved, and he's done a recent post on delving Bitcoin, elaborating on that.

Great, and yeah, I'll, for listeners, I'll put that link in the show notes as well. The delving link is, is a good one. Matt, let's hear from your perspective, you know, five years on, you know, what's, what's changed and what's, you know, what's bringing this idea back now?

Yeah, I don't think anything has changed in the sense that, you know, these great consensus cleanup fixes important issues, that we've known about for much longer than, the few years that it's been around, but- just it's never been a priority, and I think with where the Bitcoin community has come over the last number of years with the, all of the debate around the activation mechanism for Taproot, so a little bit of backstory, the Great Consensus cleanup was proposed kind of around the same time as Taproot, and part of the intent was at the time we hadn't done a soft fork since SegWit, and obviously SegWit had a lot of drama around it, and there was some- debate as to, you know, how are we gonna be able to do another soft fork? Are we able to do another soft fork? You know, what does it look like to do another soft fork? so this was really intended as a, here's something that we can all agree on, this is like pretty straightforward. just fixes some important bugs that we all agree are important bugs, and we can use this to hammer, hammer out how we're gonna do, soft forks going forward and, and, and what that process looks like. Now, Taproot ended up being ready relatively quickly, so we didn't end up doing this. but I think it might make sense to revive it for, in fact, very similar reasons to why it was proposed at the time it was proposed originally. of course, as, as Steve mentioned, and, and as people can read in the, delving post, it does fix some important issues, so we should do it at some point anyway. It's just a question of when.

Yeah, and that's a great point. So let's, let's ha- let's go further into that because I think maybe people who are maybe newer to Bitcoin or not as technically

Not to blame them, right? They're, they're new, but they're coming in and they're, they're listening to different people, and maybe they're coming in with this perception of, "Oh, Bitcoin is this perfect, pure thing. There's never been these big bugs," you know? Or people say this kind of, "Oh, there's never been, you know, a hack," when actually if you look back, there was, you know, the infamous value overflow incident in twenty ten, there was, you know, the inflation bug in twenty eighteen. Like there are these to, to fix. As I understand, it's a, there's a time warp, bug, and there's also this, i-idea around, blocks that could take a long time to validate. Do you wanna just expand on that?

yeah, there's a few things, big. So you mentioned Time Warp, that's one of 'em. So Time Warp is an issue in Bitcoin where the, the windows for when we calculate difficulty adjustment rate, so when we look at how long did it take to mine the last twenty sixteen blocks, to calculate what the next difficulty should be for the next twenty sixteen blocks? We actually look at how long it took to mine the last twenty fifteen blocks. We don't look at the last twenty sixteen blocks. And so what this does is it means this group of twenty sixteen blocks and this group of twenty fifteen blocks, They don't overlap, and as a result, miners can play games with the timestamps from these two blocks that are right next to each other, right on the difficulty adjustment window, and they can drive the difficulty down. So after, you know, each difficulty period, if they wanna play, if they wanna select their timestamps carefully, they could drive the difficulty down four x each difficulty window, and they could just do this until they can build a long chain. Of course, Bitcoin selects the long-- the most work chain, not the longest chain, so you can use this to build a, like, an, an A smallish miner could use this to build a very long chain of blocks. It obviously wouldn't overwrite the whole chain, you'd need a, a fifty-one percent attack to do this, in a material way. But it would let miners, you know, decide as a fifty-one percent attack that they just wanna mine out all the subsidy faster or, just mine blocks faster or whatever, which would screw up a lot of time, A lot of the, time locks that people put on transactions, you know, they can say this transaction's not valid to be included until this time in the future, well, now that's gonna be a little screwy because all the block calculations that you had assuming blocks were every ten minutes are completely wrong. and yeah, I mean, it's just a particularly nasty bug, not super big risk because it requires a 51% attack, but something that, that should be addressed anyway. the next thing you mentioned is, I think you mentioned block validation time. So there are some transactions you could construct, very maliciously to create blocks that take a long time to validate. the Delving post quoted three minutes on a modern laptop, so on a very powerful or relatively powerful machine, could take minutes to verify, and on a Raspberry Pi it took an hour and a half, so you just couldn't ever stay in sync. so this is potentially really damning for, certain mining attacks, so for, selfish mining, you could use this for some kind of selfish mining attacks that miners could use to, inflate their effective hash power, so mine more blocks than they would given their hash power. And yeah, I mean, it can just be really nasty. These are issues we've known about, so these are things that were even talked about in the context of SegWit. So when we were talking about how to design SegWit, one of the things that was raised repeatedly was we need to add SegWit because we need to have a transaction format that doesn't suffer from these issues. And so now maybe it's time to start disabling a few select script features on pre-SegWit transactions so that you can't create these malicious transactions. and then, final thing that the Great Consensus Cleanup proposed fixing, was sixty-four byte transactions. So these transactions are totally useless. There's not a good reason why you should have them. But the Bitcoin Merkle tree, so if you remember, all the, the Bitcoin block header just has a hash that represents the hash of all the transactions, but it's actually a tree, right? It's, the hash of these two transactions, and then you hash them together with the hash of these two transactions, and then you hash that together with the hash of these. This row of transactions, you don't just kind of hash all the data and want to go, and that lets us build nice little proofs. So you can just reveal the path down to a transaction and show, "Here's the transaction, and I can prove to you that it was in this block cryptographically, without giving you all this crap. I don't have to give you all the transactions in the rest of the block." sadly, that Merkle tree construction, had a bug in it, and that is a sixty-four byte transaction can appear the same as, an Have a sixty-four byte transaction here, and that would look the same in this proof structure as two transactions below it that were longer and just happened to hash to the same value. this is potentially very damning for light clients, for clients that are accepting these SPV proofs. It's not as common as it used to, it used to be a lot of nodes just trust servers instead of trusting SPV proofs anymore. it also requires some amount of hash power, so it's not completely free, to exploit, but it's Pretty damning, and we should fix this.

I have a question about that, Matt. In the delving post, Antoine mentions, side chains might use these Merkle proofs. Are you familiar with any like new proposals that might use this

or

not?

I think a lot of the proposals people are pushing forward around rollups on Bitcoin as well as Liquid and other existing sidechains do use these hi-types of proofs, so they could potentially be fooled by this type of attack. yeah

Okay. W- one more comment I had on the first one, the time warp bug, and this is mentioned in the delving post too, but I mean, we-- I think the Bitcoin community should discuss how likely we think this might occur or, Like the likelihood of it happening, but, but also what's the response? So what's always been told to me is like, "Well, it'll become, if, if that attack, when it is initiated, it'll be public information and we can scramble in the next two to four weeks." to soft fork Bitcoin and come to consensus and fix it. But the delving post, and I would agree with the delving post, says that's, that in and of itself is risky. Like, Bitcoin's grown tremendously the past five years, and if we wait another five or ten years, think about how big it's gonna be, and to have the world scramble in two weeks To address that seems very risky. I mean, it's possible, yeah, but it's risky. So it seems far more safe and secure and prudent to, like, get consensus on a change like this now over a period of months or even years if needed and proactively make that change before there's an attacker. Yeah, that seems

enough I don't know why we would put ourselves in the situation where we have to scramble when it comes to Bitcoin. That is the opposite of conservatism and careful.

Yeah, of course. so in terms of, You know, getting enough support here, wh-what do you guys think that looks like? I mean, p-getting the message out here, you know, I, I think people maybe have a perception that, you know, soft forks are, you know, it's gonna be a huge deal, it's gonna take a lot of work, and, and, you know, maybe it is. what's the, what's the, you know, realistic pathway forward here to sort of, you know, if, if the-- assuming, you know, these changes are, you know, This is being done, what's the path forward there?

I think one is education, like, so the show will help, and, you know, the, the more we communicate this and just inform people of these problems, and it-- 'cause there are common-- 'cause some people will be like How, how bad can these really be? 'Cause like if these are really severe bugs, why, why is Bitcoin working so well? Well, you can have something that's severe but just hasn't occurred yet and has some probability of occurring over time, and the longer time frame you You push out, the, the probability goes up. So just education, number two is there's still technical work to be done. Like Matt's proposal, from five years ago goes a long ways towards it, but, if I recall correctly, Matt, there's no code written yet, and there's, they're certainly not code complete, tests broader developer consensus. So I think that's one thing Ant, Antoine points out is doing, and I know of another developer too interested in contributing to that. So there's technical work to be done there. also on some of the proposals, there's room to improve them so that to reduce the drawbacks to the changes too, we can get into that a little bit. And then, yeah, the, the, I mean, a third thing is to also Wade into the conversation about ossification, and, you know, I'd love to go deeper on that, maybe, maybe later in this episode or in a different episode to, to really thoroughly tackle that, but I, I think, if, you know, ossification means be conservative on such changes, that I would put myself in that camp, but if ossification literally means no changes, I'd, I'd take issues with that. And this is a great, this is a great example, 'cause they're- Because Bitcoin, isn't a perfect granite right now. It has, it has some cracks, and we probably need to fix some of these cracks.

Yeah. Matt, any, any thoughts to add there?

No, I think that's true. You know, I think the great consensus cleanup was proposed, it had a little bit of feedback, but because Taproot was happening at the time, people were more focused on that and didn't end up Spending a lot of time digging into the guts of the great consensus cleanup proposals, it seems like people are, are spending a lot more time doing that now. You have a lot more developers looking at it, a lot more people giving, now Antoine feedback. and so, yeah, I'm looking forward to the results of that, and I think once that process makes a little more progress, I think we're gonna be in a good spot to start talking about, what activation looks like, which will be a whole other, whole other conversation.

Yeah, I see. And so, is your- Idea or hope then that if maybe, if it, because this is the other thing, theoretically you can activate multiple things at the same time, right? Like you could have, somebody could package these things together with some other change that the community also wants, or it could just be sort of put up as its own thing. Do you have any views on that or just, you know, any thoughts there?

do you mean the individual items in the Great Consensus Cleanup or the--

Yeah, I mean, as an example, if let's say, there's a whole bunch of people who want some kind of covenant thing, or, you know, in the same way that James Obie's proposal includes multiple things?

Yeah, I, I don't, I, I'm very much against the idea of doing joint soft forks. I think that's a really bad precedent because, i-it unnecessarily ties things together, right? Like we shouldn't be-- That's really the reason to do that would be to kind of force a political agenda, right? That's more of a political tactic to force people to agree to some compromise, but it isn't The way we do good engineering, it's not the way we, we do make good decisions on what is best for Bitcoin. and it's important to recognize too that just because great consensus cleanup happens, doesn't mean any of these other things shouldn't happen, won't happen, or couldn't happen on, at a similar time frame, right? we can have multiple soft forks with signaling, happening at the same time. It's There's no kind of requirement that these things happen serially, aside from just developer attention, which is certainly not something that's, that's, we can control and not something that I think great consensus cleanup is gonna make a huge, huge dent in. Yeah, I, I agree

with all that. also, the covenant proposals and some other proposals, you know, I would argue they're in the bucket of innovation and new features, whereas the, this great consensus cleanup I would put in a bucket of fixing bugs and security. So I, I think those are two very different buckets. And, and again, and The, when it comes to security and fixing bugs, I think it's way easier to get consensus as, as well, as opposed to, to new functionality. but to-- I mean, Matt asked this question, but I think one question will be for the great consensus cleanup is should all these fixes be in one go? And I, I, I think that's a function of how much, consensus we get on, on each of them. If, if may-- maybe two of the three fixes have phenomenal consensus and one ha-- there's some legitimate concerns or disputes raised that might take years to resolve or never Well, then it would make sense to split, you know, split the two out that have consensus, but so we'll just have to see what the overall, community feedback is on that.

Yeah. And, I mean, up, up to now, have there been any, let's say, serious technical objections raised or not, not at all? Well,

the only one I'm aware of, and I actually raised this with Matt fi-five years ago, is just if, if we make some, opcodes, like pre-sequence opcodes and scripts in-invalid, well, We make them invalid, in theory, there could be coins free-frozen or seized based on this change, which n-n-no one, no one wants to make, that, you know, that change, that, that, that's like a fundamental principle of Bitcoin, and no developer wants that to happen. So we just need to be very cautious of that. And, and I, I think I, I have heard enough convincing arguments about how we could do it technically that I think we can get comfortable with that, but- That's one area I think needs a little bit more developer attention and work.

Yeah. and so, so it sounds like, you know, there's not really any serious technical objections other than the one you just mentioned, Steve. So it's more just a matter of, I guess, getting the consensus, getting enough people to sort of agree with this that, you know, we want this fix, we want this, you know, we want this fix rather than some new innovation, With that, that's kind of the category you'd put it in.

Yeah, I think, I mean, broad awareness among developers, get developer feedback, make sure there's a strong risk assessment and evaluation is-- and, you know, we should give a good amount of time for that to occur, and then in-- this can happen in parallel, but again, broader, broader community awareness and, and because these are very technical and bug fixes, I, I think for non-technical Bitcoiners, it's more just understanding what, what is the bug, what's the probability of it happening, what's the severity if it does happen, and then what's the risk, technical risk with these changes. That, that's what I'd want to know as a non-technical person. You know, I, I think that should be-- the, the, the answer to that should be like low technical risk of making this change, and it's definitely something we wanna fix at some point, so let's do it sooner, sooner than later. But sooner doesn't mean like in a month. I mean, if it takes us two years to go through this process, I think that's fine, but let's start that process now.

Yeah. anything, anything else to add on, great consensus cleanup, before we move on? No, I think that's pretty much it then. Alright, well, yeah, let's leave that there. Hopefully, listeners are now at least more aware of this. I will of course include links in the show notes for people who want more detail, the Delving post, Matt's original post from twenty nineteen, and, maybe your thread, Steve, I'll put that there. let's talk a little bit about another concept that's

The concept of quote unquote MEV or miner extractable value, and I know Matt, you have an objection to the way people are using that term. So, do you want to just spell out your idea? What, what term should we use instead, and, and why?

Yeah, so all right, as, as this topic keeps coming up more and more in the Bitcoin context, it's obviously been a, a pop-- a big topic in the Ethereum world for a long time, because the miner extractable value on Ethereum has become complicated, right? So, today there's only a handful, and I mean a very small number of entities, very small number of companies that Can create a competitive block template on Ethereum. and this is such a problem that the, a bunch of software has been written and all of the, Ethereum blocks today are mined, are created by two separate entities, right? So there's one entity that actually selects the transactions that go in the blocks, which is, you know, kind of the important part from censorship resistance, right? That's the, the thing that matters is who selects the transactions and which transactions do they include, and then there's a separate entity, there's the staker who's actually, to the block and then announcing it. And this has been separated because a staker simply couldn't commit, couldn't compete today with all of the optimization that these, block template creators or searchers in the Ethereum, lingo, Can do and can optimize for and to create a much better block template. and so this is, potentially even worse in a proof of work model because, miners are highly competitive because you are on much thinner margins as a, a proof of work miner, and as a result, if it is the case that, you know, someone else can make a block template that is five percent more valuable, that pays them five percent more in total fees, per block. They can probably stay in business and you probably can't, right? So if it is the case that the, this MEV extraction concept in Bitcoin becomes Very, it becomes as complicated as, as it is in Ethereum, such that there's only, you know, really maybe three companies that can create a competitive block template, then we're fucked. I mean, we should give up on Bitcoin. Like honestly and legitimately, we should give up on Bitcoin.

Right.

luckily we're not there today. So

yeah. So, so let's fill out the concern. The concern is miner centralization. The concern would be that, you know, the idea with Bitcoin is that anybody should be able to mine, like theoretically within reason, and you should be able to mine, you know, a, a relatively profitable block, a, a competitive block ba-basically. And if you can't do that, then maybe what ends up happening is You get this kind of private system where maybe you want to try to be a miner, but actually you're reliant on some, some particular pool because maybe that pool has the ability to create a very profitable block that you can't do as an individual miner, and then at that point you're starting to centralize, and at that point maybe the game starts to become captured in that way because- The state could go to that pool and say, "Hey, you're only allowed to select to include this kind of transaction and exclude these kinds of addresses or these kinds of transactions." That's the concern, right? Right.

Yeah. So ultimately, the thing that matters for Bitcoin is censorship resistance, right? Fungibility and censorship, censorship, censorship resistance are the things that make Bitcoin what it is. That there's, if we don't have those, then why are we bothering? And if it's the case that all the miners use one pool or all the miners use three pools, then clearly we haven't acquired, we haven't achieved censorship resistance. We are Totally censorable, because that's all we can do. with pools today, you know, miners have business arrangements with pools, it's not super trivial to switch overnight, but they can switch relatively quickly. and with potentially Stratum v2 on the horizon, you know, as, as miners and pools start to adopt that, then we're kind of back to where we should be, where miners are selecting the transactions, there's a lot of miners, and it- becomes very impractical, if not impossible, to actually effectively censor a Bitcoin transaction. if, like you described, if, if this MEV extraction becomes so complicated and so expensive to do efficient- efficiently and kind of optimally that you have to use one of these pools in order to make a competitive amount of money, then there will be-- there will be no decentral-- decentralized transaction selection. There will only be a few small pool, a few pools who control the whole network, and that'll be the end of it and, you know, if that's the case, we should, we should probably give up. So this, this is

potentially really damning, but luckily, I think we're not in a position where it- You know, where we're gonna end up, where, where that's fate is sealed. so you mentioned that, you know, I have a lot of objections to the ME-- to the MEV term, and I do. So you see a lot of discourse today on Twitter and elsewhere where a lot of these people working on rollups and working on other sidechain technologies on top of Bitcoin are kind of saying like, "Ah, MEV is inevitable. We can't-- there will always, there will be MEV. We have to learn to deal with it. and that's just how Bitcoin's-- Bitcoin is going to become Ethereum, and the Bitcoiners just need to grow up and learn to deal with it." and I think this comes from, a terminology confusion. I think this is, i-it is the case that MEV isn't inevitable on Bitcoin, but that's because MEV means miner extractable value. It means all of the value which a miner can extract. MEV includes the block subsidy, it includes standard transaction fees, it includes RBF, it includes, potentially miners doing reorg attacks, it includes literally anything a miner could do to get any amount of value So obviously MEV is inevitable on Bitcoin because MEV just means miners extracting value, duh. so, so I find this term to be very problematic and it, it, it makes the discussion kind of useless because people just say, "Oh, well, MEV is inevitable, so we should just figure it out and go from there."

But that's kind of a terminology confusion. So we really need a new term, and we need a term that means a effect that causes mining to centralize because it becomes expensive and difficult to, select an optimal block template. And the term that I've started using and that a number of other Bitcoin developers have started using is MEvil, so MEV that is evil or M E V I L. and so that, that has a much more clearly defined meaning and lets us talk about specifically what we're concerned about and specifically, what might be problematic and then what might not be problematic so, you know, a lot of people talking about rollups and talking about these sidechain systems are like, "Well, you know, MEV is gonna exist because we're gonna build, all these complicated primitives on top of our rollup, we're gonna build, decentralized exchanges and all of these things that, that create potential for MEV on Ethereum that create, that cause kind of complicated, dynamics where you have to create transactions, with very custom software." but that doesn't create MEVil, so that creates MEV on the rollup, but most of these rollups that people are designing and that exist on Ethereum are completely centralized, right? So there's one entity that operates the rollup, they select all of the transactions that enter the rollup, and they can do whatever they want there. so for example, you have Base, the, the rollup chain that's owned by Coinbase. Coinbase can censor or not censor any way they like on the Base chain.

this obviously creates lots of MEV potential, potentially complicated MEV extraction on that rollup because you have all these crazy complicated scripts and all kinds of stuff going on there that, that you could potentially wanna, do, you know, high-frequency trading or whatever to, to optimize how you're gonna extract value, but importantly, that value doesn't flow to Bitcoin miners. So Bitcoin miners, not that the value doesn't flow to Bitcoin miners, but that, that the complexity doesn't flow to Bitcoin miners. So the Bitcoin miners, don't have to do anything complicated to extract the same value. There's nothing they can do to, to get more or less value out of that It's also important to, to call out that some things, anything that can turn into a bidding war in the mempool is also not super relevant for MEV. It's a little bit different on Ethereum because they have very fast block times, but with Bitcoin's ten minute block time, the public mempool becomes a potentially a bidding war, right? So we've seen this with, you know, someone will spend a lot of money and send it to, an address that was very, had a weak private key. So the The private key was generated with, a wallet that had a bug or a security issue, and so, anyone, for some definition of anyone, could have known the private key to that output. So, potentially a lot of people know the private key, and they all wanna claim this money that just entered this address, and we've seen this turn into a bidding war, right? So we've seen, miners or these, these nodes that wanna claim this, this free money will start bidding up the claim such that a lot of the value ends up going to But at least they get some of the value back. So it's true that like a miner who is also participating in this bidding war would get a hundred percent of that value rather than ninety-five or whatever, but It's also the case that if this is an efficient bidding war, then ninety-nine percent of that value is gonna go to the miner, because you just want any amount of value, and you're gonna pay the miner the most value to, to get that value. so this isn't interesting from a MEVil perspective. This is obviously, something that you would classify in the MEV context, but it's not a MEVil issue, it's not a concern because the miner didn't do anything. The miner just sat there, they took RBF transactions like any Bitcoin node does, and they got basically the maximum value or close to the, hopefully close to the maximum value they could have gotten out of that. transaction, even if they'd hired a huge pile of software engineers to, to build the best block template constructor they could. so it's important to, to do these classifications, that I think this nuance always gets lost on Twitter, because people just talk about MEV and they don't have a, a clear definition in mind.

Back to the show in a moment. This show is brought to you by Swan Bitcoin, the lead sponsor of this podcast. Over at Swan Bitcoin, you can buy Bitcoin in a super fast and slick way using the Swan Bitcoin- App, which is available on Android phones or Apple phones, all you have to do is go to your app store and search Swan Bitcoin. This is a great way to onboard your family and friends, take them from zero to Bitcoin in just a few minutes. The team at Swan have been working really hard to make it a really slick experience, and so now is the time to get people onboarded to Bitcoin with Swan, because Swan has a mission of teaching millions of new people to become Bitcoiners. And the other big thing to add is that There are zero fees on your first ten thousand dollars of Bitcoin buys. So this is a great way to get started. There's no fees from Swan for the first ten thousand dollars, and it's not just for new customers, it's also for existing customers. So don't wait any longer, make sure you sign up over at Swan Bitcoin using the application on your Play Store or your App Store. This show also brought to you by CoinKite dot com. When it comes to securing our Bitcoin, we need to use hardware devices to help secure our private keys, and so hard- Hardware devices can help you in terms of generating the private keys, as well as keeping them offline for when we sign with that hardware device. So CoinKite are known for the Coldcard Mark IV, which is the well-known device that many people have been using for years and years, this or the prior versions, and the newest device coming out now, which people are receiving, i-is the Coldcard Q. So this one has a full QWERTY keyboard, and it makes it really easy in terms of typing in seed words or passphrase, and it also has a QR reader, QR scanning, feature. So that makes it really easy for those of you who like to use the QR feature, whether that can be really handy when it comes to multi-signature, or just for different setups. Now, the team at CoinKite are continually rolling out new features and security updates, so there's lots of things to learn about Bitcoin when you're using these devices. You can use it in a very versatile way, whether you just wanna use it in single signature, whether you wanna have a passphrase, whether you wanna do BIP eighty-five Or seed x or, or, use multi-signature. There's just so many options out there. So to get your gear, go to coinkite dot com, use code livera for a discount on your cold card gear. And lastly, this show is brought to you by mempool dot space, the leading Bitcoin and blockchain visualizer. Over at mempool dot space, you can search the blockchain in terms of past transactions by searching transaction identifiers, and you can also look at what's in Bitcoin's mempool, and you can see what kind of fee you need to Target to get your transaction confirmed into the next block. So I like to keep an eye on things, I'm often checking mempool dot space, and you should too. Over mempool dot space, you can also keep an eye on the Lightning Network, they've got a mining tab, and they are continually rolling out new features in terms of things you could look at, such as the mempool goggles, and just all kinds of new features. Now they are rolling out an accelerator program, so for those of you who want to sign up there, go to mempool dot space slash accelerator. And now back to Yeah, and I, I think you're right to, try to clarify the term or at least distinguish the term, like MEV the broad term and MEVil the specific, you know, the bad kind of MEV, right? I'm saying in a loose way. But, as an example, right? Like in the, you know, as I like to call them, the retardinals world or the inscriptions world, there's, there's been some kind of fee bidding wars as an example. So would you categorize that as MEVil or just standard ME

As long as the miner doesn't have to do something to get a more efficient block, then it's still just MEV.

Gotcha. yeah. So as an example, this could be-- It's not MEV, I don't

know.

Right. I, I mean, now I'm not intimately familiar with these protocols like the runes and the inscriptions and things, but as I'm understanding, it's like there are people who are kind of seeing a transaction in the mempool, and they sort of have a deeper understanding of it, so they're trying to snipe that. But crucial

So I guess that's why we would put that in the category of just standard MEV, that's not MEVil, in this, to use this parlance, right?

Right. You just any, anyone would bid on it, it just becomes a bidding war in the mempool, and that's totally fine. Miners will, you know, follow the bidding war and will take the highest bidder.

Gotcha. Yeah.

What about, what about rare, rare sets though? Yeah, so I think rare sets are a great example of something that is absolutely MEVil and should be considered antisocial and is something that Bitcoiners should strongly denounce, and shouldn't participate in. so unlike inscriptions, rare sets assign specific value to certain satoshis on chain, that's not, you know, it's not tied to, a thing you did, right? So like an inscription, I can take any satoshi, attach a picture to it or whatever, attach whatever garbage data I want to, and now it has some, potentially some value because I've inscribed it. rare sat say, "Well, that Satoshi right there, that one random Satoshi, is now more valuable." in the general case, this doesn't necessarily create MEVil, but it certainly creates fungibility issues, which Bitcoiners should also be concerned about. fungibility issues make it very hard to accept Bitcoin, very hard to deal with Bitcoin, because you don't know when you might have a Satoshi that might have higher value, and so you might have to, you know, constantly be checking in with centralized exchanges to see whether you randomly have- Satoshi that's higher value and suddenly you have a middleman in your Bitcoin transactions, which is not what we want. but specifically the Rarissats system that you, that, that I think people consider, that people think about today It is problematic for a MEVil reason as well, because it often assigns a higher rarity to Satoshi's as they are mined. and so specifically we see this for the, the having block block reward. So the first, I think it's the first Satoshi in the having blocks block reward, has some rarity value and it, Potentially, has some value higher than a normal Satoshi. So here too, a miner, if they wanna have the highest possible reward, they need to- Presumably consider this, they need to be aware of the market dynamics in the rare satz market. They need to, siphon off this rare sat and store it somewhere else, then they need to go participate in, in the rare satz market. They need to potentially sell, you know, they need to find a, a bidder for, who's gonna buy it for the highest price. So again, this, this is evil, right? This is a case where a miner running simple software Hopefully open source software can't get the highest value block template. A miner has to take some action that presumably requires hiring some people who are probably well paid and expensive, so a small miner can't do this. A pool, a large pool can do this, but a small pool may not be able to do this either. They may not have the resources to do this. So these kinds of things that, that cause mining to be a more complicated business, a more, involved business, a costly business Especially for small miners is really damning for Bitcoin centralization.

Yeah, I see. and so listeners, you can check out the, I've got an earlier episode with Casey Rodama, but the basic gist of it is that there are- there's a different rarity level for different kinds of satoshis. These satoshis are being serialized, and there's like, you have to run this additional software called ORD, O R D, right? And so, as Matt is saying, it's not just running Bitcoin Core and the Stratum v2, you know, protocol, now this miner has to also run ORD. They have to think about which sat-- and we might even see reorg attempts, come the halving block because of if there's additional value being, you know, ascribed to these, so Satoshi. So that's an example where, yeah, it's probably more in the MEVil category. are there other, you know, MEVil, things that can-- I guess one other area that would be good just to spell out a little bit more, you, you were touching on this, Matt, but just around- What layer it bleeds through to, right? So if, if the quote-unquote MEVil is on-- is all happening at L2 and none of it's happening at L1, maybe you would argue, or we would argue, that's not MEVil because it's not impacting the L1 Bitcoin miners. That's kind of all happening at a different level, and you don't have to run that L2 rollup or whatever sidechain in order to be, competitive L1 Bitcoin miner. That's, that's how you would see it, right?

Right. Yeah, yeah, absolutely. and, and so there is nuance, of course, when we talk about rollups, there are different kinds of rollups, there are different kinds of side chains. some rollups, in fact, most rollups are super centralized because it is, more valuable, right? The, the centralized party, if there's a company creating a rollup, they're gonna wanna extract the value, so they're gonna create a centralized one so that they can get the MEV. but in, in the general case, rollups and sidechains more broadly, don't have to be, right? They could have a decentralized, transaction selection that is based-- that allows Bitcoin miners to select transactions And I think that also has potentially very damning impacts on Bitcoin. so, more recently, there's this idea of sovereign roll-ups, which are, yeah, a roll-up where the Bitcoin miners can select the transactions. there are things developers of these systems can do to make it so that MEVil isn't a concern, and, and I won't necessarily get into all of them, but, they, they can they can design the system very carefully, but a naive system might introduce MEVil in a big way, and I think that, a developer or even a user of a system like this needs to really carefully consider it because You know, you're gonna use this system on the thesis that, you know, Bitcoin is the most decentralized chain, and that's gonna make your, your rollup even better because it's gonna have better censorship resistance, and then you're gonna introduce MEVil, and then Bitcoin is gonna become really centralized, and then Bitcoin's not gonna have any value, and your rollup is gonna be, kind of dumb, and you should have just done your rollup on Ethereum because, you know, they, they're already, grappling with these issues in, in different ways, And they're working on solving these issues in, in very different ways. But

yeah. So just to hammer this point as well, so as you mentioned, some of the, you know, on, in shitcoin land and Ethereum and all these other, they have, you know, decentralized exchanges or so-called DEXs or AMM, automated market makers, and this is where some of the, you know, the MEV conversation is happening as well, because that's where maybe there's more of this sort of- Sniping or front running dynamic, but as you sp- as you said in Bitcoin, we have ten minute block times, and so therefore, i-it's not as much of a concern, and it, it doesn't relate to the miner, the L1 miner having to do that. It just relates to, you know, people in general could be doing that. Is that how you're saying that? That, that, you know, as an example, that Bitcoin doesn't have, you know, these kind of decentralized exchanges and automated market makers, therefore, that- Yeah,

that, that's Of maybe that's a big part of Ethereum's main problem today, it's not all of it, there's other more complicated things that happen as well, but that's a big part of it. Ethereum, what has essentially happened is in order to be a, an effective Ethereum searcher or an effective Ethereum transaction selector or block template constructor, you have to be a high-frequency trading firm. so you have to be, actively monitoring, you know, all of these centralized exchanges, and you have to be, you know, creating an Ethereum block at exact, just the last possible millisecond, and you have to have your hardware co-located in the right building so that you're better connected to all of the other Ethereum stakers so that you can get your block out just before the time limit, and also at the same time trade against the centralized exchanges. That's a big part of Of where MEV comes from in Ethereum today, and it, and you know, there's only, whatever, three or four great, high-frequency trading firms that are really super competitive. Obviously, every trading firm on Wall Street is now to some extent a high-frequency trading firm, but there's only a few that are really, really good at it. and similarly, there's only a few that are really, really good at it on Ethereum.

Yeah. one other area is around out-of-band fees. So people have been talking about Marathon's service, Slipstream, but out-of-band mining pools have existed for years. It just seems that now it's becoming more productized and sort of public-facing. Does that also present a, a MEVil concern in your view?

I'll speak to this a little bit, I mean, getting back to the, Genesis of why I tweeted out about the, the great consensus cleanup, Marathon slipstream announcement was, was a motivating factor for that, and we reached out to Marathon to speak about that, not about the out of band fee issue which you raised, but instead the non-standard transaction aspect of it, 'cause that, that API allows for non-standard transactions, and getting back to the great consensus cleanup topic and some of the concerns there, we just wanted to make sure they weren't going to be naively- mining some of these DOS attack vector, transactions. And the good news is they were aware of that and sensitive to it, and, and really, it, the main driver of non-standard transactions for Slipstream, my understanding, is OP_RETURN And that's from inscriptions and, and, and BRC20 and, and runes and some of these new, new applications. So that's what's driving that demand. But it is, it-- I think it's correct to say, that it is becoming more popular, and thus we do need to look at, is out of band a payment an issue? yeah,

absolutely. potentially. so out-of-band payments that create a centralization vector, you know, where, where only one pool is able to claim the, the best, or one pool or one miner is able to claim these out-of-band payments and thus make the best block template is, is absolutely super-centralizing. but it's not necessarily required, you know, you could build an out-of-band payment scheme that is a simple open-source software Library that someone can just run as a miner and it takes five seconds to set up, and then they get, receive these out of band payments via whatever mechanism they want, and I, I wouldn't call that MEVil, right? Because you're not necessarily creating any cen- centralization there. A small miner can, easily participate in a very small amount of work and so, it, it depends a lot on exactly the, the details of, of how it's set up, and I think that's kind of the story of MEVil, is that it, it depends a lot, once you get, really get into it, it depends on a lot of the exact details of, you know, is this rollup centralized? Is this rollup decentralized? Is this rollup taking some of these mitigating strategies? you know, is this out of band fee payment, open access? Is it centralized? Is it, you know, what Have, and I think that's also why it's important to define a different term rather than just calling it all MEV, because this isn't all MEV.

Gotcha. Alright, well, one other area we were keen to touch on, for this episode is around Lightning, and there's been a lot of back and forth about, is Lightning dead or is it not what was promised in the early days? And some of this is, sometimes it's just big blockers who are a bit salty, in other cases maybe there are genuinely, you know, Bitcoin and Lightning builders who Where are you guys at in terms of, you know, Lightning today in twenty twenty-four? Is it dead or doomed in some way?

I mean, I think it's, it's ne- neither extreme. It's not a silver bullet, perfect, and it's certainly not dead either. It's, it's in between. And I mean, as far as the critics, I would take the builders who are actually trying to build Lightning, their feedback much more seriously than people who are working on, on another system. but the-- there's definitely been some- Builders of Lightning wallets with critical feedback, and they've gone through a lot of pain. It's valid feedback, for the most part. Lightning's not perfect, but it's not dead either. the- Diff- people have different conceptions of what Lightning can, can do for, for users. If your conception is that it's going to be, A, a no fees or extremely low fee decentralized censorship resistant payment mechanism, then, That, that can onboard eight billion people and machine-to-machine payments, that's not what it is today. it's, it, it is instead a, it, it, it, it's the best scaling solution that we're aware of that That does a really good job at mirroring the properties of on-chain Bitcoin, not perfectly, but you get most-- you, you get the closest to on-chain sort of self-sovereignty properties of any other scaling solution, but it does come at a cost, in the sense of it's definitely cheaper than on-chain payments if you amortize over like a hundred payments or whatever, but it's not, you know, it is a function of on-chain fees, and it's definitely not Not free. So I think that's where some people got burned. they've been paying like one sat fees on custodial lightning solutions or when the on-chain fee market was one sat per vbyte, and then all of a sudden when the on-chain fees went up and non-custodial lightning wallets have become more popular, then you're faced with like a twenty or thirty dollar on-chain fee to open a channel, and if you weren't expecting that, that hits you, hits you hard. Yeah,

Matt, anything?

Yeah, I think it's important in this context to also kind of point out that Lightning, you know, this was something that people talked about early in the days of Lightning, but became not as popular a narrative, calling Lightning kind of a compression layer for transactions. so like Steve mentioned, you know, Lightning is the only, system that anyone has proposed, in the short term that, that's kind of practically being implemented, certainly that's available, but that will be implemented in kind of the near to medium term that Has properties anywhere close to on-chain, right? Everything else has basically a custodian or maybe multisig custodian, but a custodian, and With that in mind, you know, if you're saying like, "Well, I could do on-chain, but, well, on-chain's not great because I have too many transaction fees and, you know, confirmation times of ten minutes or an hour or whatever," so I want something else. But, you know, when we're comparing with Lightning, well, Lightning is always going to with Reasonable assumptions have fewer total on-chain transactions compared to just having an on-chain wallet. it's gonna have instant transactions in many cases, and certainly if you trust an LSP, at least for, you know, kind of displaying a pending transaction as pending, it's gonna have instant transactions. so it, it fixes major UX issues and always has lower fees than on-chain. So if we're comparing to on-chain, it's strictly better, always better, and Lightning is great. If we're comparing to a system with a custodian, Lightning is awful. The fees are high, there's complexity, things fail sometimes, yada yada, right? it's important to kind of put these things in context, and I think, you know, maybe as we build more systems that sit somewhere on the permissionlessness and censorship-resistant spectrum between Lightning and custodial systems, that we can have a more nuanced discussion. But right now, saying Lightning isn't as good as custodial systems, well, duh. And Lightning is worse than on-chain, well, it's never true. Lightning is always gonna be better than on-chain by some, some small margin, at least, if not a large margin. And depending on how many transactions you do, so sadly it's kind of just the, the one option right now. That's all we have, and it is super compelling if you do a lot of transactions, the fees can become very, very, very low, if you do very predictable transactions, your LSP can plan for it and the fees can become very, very, very low. If you do very, very infrequent transactions and you only get zapped, well, Lightning is just not great for that. A few

more things I'd add, you know, if we think of Bitcoin as the global, asset and underlying money, I think Lightning ha-is clearly the global payment, open payment network that, that allows payments to flow with, with, Bitcoin, and as Matt just said, it definitely, you have this compression factor and, and win over on-chain, and I think Lightning's already, won, won In that, meaning like the only world where Lightning, that I can imagine, that Lightning isn't the open monetary network is a world where we develop some new layer two Scaling solution that is a silver bullet and satisfies every user, every use case, and then, well, then everyone would just use that. That's not on the horizon right now, though. No one knows what that solution is. I mean, it would be amazing if we figured that out and has all the on-chain properties, scales to everyone and everything, amazing, but that doesn't exist. So we're going to have many, many different types of layer twos, threes, whatever, whatever you wanna label these, but various solutions that have various trade-offs. trade-offs in terms of functionality, fees, trust and trustlessness. and Lightning's already the glue between all those. So look at all the different proposals, whether it be eCash proposals like Fedimint or Cashu or ARC Or you name your new proposal, all of them integrate with Lightning already and all of them compete each other with Lightning, and of course custodial solutions like Cash App and soon Coinbase, Kraken and they, they, and Strike, they all support Lightning. So it doesn't matter, and even, even if you just take JustFED, I mean If you have, if, if like Matt is using one mint on Fedimint and I'm using another one, how do we pay each other? Well, we pay each other via Lightning. So I think Lightning is that interoperable glue between all these different systems, and it does really, really well at that. The main challenges moving forward in question marks are how well does Lightning, scale to individual users for a Lightning wallet? And we, I mean, there's clear, you know, obstacles there. But again, I don't think custodial lightning is, horrible and needs to go away. We just need to make sure that there's non-custodial lightning, credible options and a, and a, an actual user base. I think both can, can coexist. and, and custo-- 'cause some people criticize whether custodial light-lightning even has a purpose, well, it, it again, allows for instant payments, low fees, and you can plug into this open, open monetary network. with, with trade-offs though, you have to KYC and you're trusting-- you have to trust your financial partner, a, essentially a bank. and that, that's the advantage with non-custodial lightning. You don't have to KYC, you get cash-like properties, You know, from just using re-regular paper money. So if people value that, you know, we'll, we'll, we'll find out what the willingness to pay is for those properties, because there will be higher fees with not using Lightning.

And as we've been saying, there's no free lunch here. There are costs to using Lightning, so notably Generally speaking, there's a liveness requirement. You have to be online, and a lot of people talk about the inbound liquidity problem, right? Like someone somewhere, especially if you are a, an edge, you're out on the edge of the net-network, you're not a routing node, someone somewhere is opening a channel to you, and they are gonna have to lock up some satoshis in your direction. Who's paying for that? And I think that's maybe the question, that people are asking, and let's say that LSP, whoever that Lightning Service Provider is, he's For them, are they gonna earn enough on the fees somehow, somewhere to make it up on that? Or, you know, what's, what's the business model gonna be, once we start getting to larger numbers of people? Maybe that's, you know, and so that's, perhaps where the, the challenge would come from people, maybe from earlier years, maybe for their, from their perspective, Lightning wasn't what was promised, right? Because they thought it was gonna be the silver bullet. Unfortunately, Lightning isn't a silver bullet. Maybe that's, that's sort of where it,

I think Steve's totally right that, you know, there are questions around non-custodial lightning, but I don't think, you know, you described Stefan the, the kind of issues, the liquidity issue, the-- I, I think these are issues that are totally solvable and largely being solved. You know, we saw at Phoenix D with the, you know, automated inbound liquidity, there's LSP spec and, and various marketplaces for these things. You know, this is a, a problem that is You know, been solved, quote unquote, but for a price, right? And so the question is really not, are these problems going to be solved? It's what, you know, to some extent, what cost, but also how much are you gonna use this channel? You know, how much are you actually gonna use your Lightning wallet? If you're gonna use it for a lot of transactions, on a regular basis, then I don't think there's any question that non-custodial, even mobile edge node Lightning is gonna work great. If you're gonna use- Use it very, very infrequently, I think there's probably not really any question that it's not gonna work any cheaper than a regular on-chain wallet. You know, if you only ever do one channel with your Lightning wallet, it will cost the same as an on-chain wallet. so there's, it's really a gradient between how often you use it, which reduces the price.

Yeah, totally fair. so I'm not sure how much time you guys have left, but, if you wanted to maybe just quickly touch on Bolt twelve, I know Steve, you had a talk on this at the recent ViaRegio, Lightning Summit, so maybe you just wanna touch on, in your view, the importance of Bolt twelve.

Sure. yeah, I think, the importance of Bolt twelve is, is, Delivering cash-like properties to, to, to Bitcoin, Bitcoin payments, I should say. So, and by that I mean, censorship resistance and, improved privacy and improved security. And I, I call out those three things because with Lightning payments, what's been popular, has been Bolt twelve invoices, which is ubiquitous as, as a way that, that people do payments with Lightning, but Bolt eleven Has a bunch of problems in that you can't reuse that payment code, so you're, you're not able to tie a human-readable name, to, to your, your wallet. LNURL became very popular because you can reuse, a, a payment code with LNURL. and then Lightning Address was born, and it's become popular, people like being able to have, like, you know, Steve at Strike dot me or, or, or whatever your, your name is, it's way easier to pay. The problem with LNURL, though, is that it has serious problems with censorship resistance Privacy and security because it depends on a third party web server. So Bolt twelve gives you the benefits of LNURL, without the drawbacks of LNURL. And, and Bolt twelve has a number of other technical improvements over Bolt eleven as well. So that's, that's the sales pitch for why Bolt twelve. Now people have been hearing, some people have been hearing this for five years because it was proposed five years ago, so I think the broader community might think that Bolt twelve is just like a fantasy or hasn't really- been worked on, but the good news is there has been a small group of developers across a few projects doing a lot of the legwork for Bolt 12 the past couple years. It's now available in Eclair's Lightning implementation, CLN's Lightning implementation, LDK's Lightning implementation, and there's a new project called LNDK which adds, some of the Bolt 12 functionality to, for LND users, that allows you to, to, to pay Bolt 12 offers and, and, And a few other things. So that lays the groundwork, and we're now at a-- so the important message to the community now is that wallets can integrate Bolt 12, and in fact, I'm quite Optimistic that we're gonna see a handful of popular wallets supporting Bolt twelve, hopefully by the summer, certainly this year, and, and that'll start-- that will help create awareness around this as, as well and create momentum. because Bolt twelve, adopting a new payment protocol is difficult because you really do need all wallets to upgrade, otherwise you face a sit-situation where, you know, you want to accept Bolt twelve, but or maybe I do, but Stefan, your wallet doesn't support sending it, then we, we can't transact. So it, it's a chicken and egg problem that's difficult to overcome, but I, I think it's important enough we don't wanna, we don't wanna lose those important- cash-like properties of Bitcoin, so we need to, to push hard, get this into wallets, and so we need to both create awareness with wallet developers that they can integrate it today, and also with their users to create demand so that it becomes a priority for wallets.

Right. And it reminds me a little bit of, SegWit adoption, where people were running around yelling "When SegWit?" at, different wallets to, and exchanges to get support there. I know this is kind of a complicated area, like we could go into further discussion, but we're Much running out of time, so we might have to save some of this, Bolt twelve and, future, some other discussion we had in line for, you know, for a future episode. but, thanks, gentlemen, for joining me. I will include the links in the show notes, for people to check out more detail there. So, thanks, Steve, and thank you, Matt.

Thank you for having us. Thanks. Bye, Stefan.

Alright, I hope you enjoyed the show with Steve and Matt. I hope you learned something that So hopefully you take that message away and maybe we'll see some progress on this idea of the great consensus cleanup. If you enjoyed the show, make sure to leave a like and share it out there with family and friends. Thanks for listening, and I'll see you in the citadels.