Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Mike Hearn: Blocksize Debate at the Breaking Point

Episode Date: June 8, 2015

Whether the block size should be increased to 20MB has created more controversy than any other question in Bitcoin’s recent history. For some, it is an urgent and necessary step in Bitcoin’s evolution. Their view is that leaving the block size at 1MB would be irresponsible inaction with potentially catastrophic consequences. Others see increasing the block size as unnecessary and a dangerous first step down a slippery slope towards a more centralized Bitcoin. We were joined by Mike Hearn, along with Gavin Andresen the most outspoken supporter of a block size increase. He is also the creator of Bitcoin XT, a modified fork of Bitcoin Core, that may become the vehicle for the push for bigger blocks if no agreement is reached regarding Bitcoin Core. Don’t miss this crucial conversation! Topics covered in this episode: What would happen if blocks started being consistently full Whether bigger blocks create a centralization risk Why Bitcoin core development has become pervaded with toxic division What Bitcoin XT is and how it differs from Bitcoin Core The roadmap ahead and how a transition to BitcoinXT would occur Update on Lighthouse Episode links: The Capacity Cliff Crash Landing Let's Talk Bitcoin! #217 The Bitcoin Block Size Discussion Gavin Andresen Moves Ahead with Push for Bigger Blocks Bitcoin Dev Mailing List Lighthouse This episode is hosted by Brian Fabian Crain and Sébastien Couture. Show notes and listening options: epicenter.tv/082

This episode of Episode of Bitcoin is brought you by Ledger, makers of the Ledger Nano hardware wallet. Half piece of mind in knowing your private keys are protected by industry standard, physical security. Go to ledgerWallot.com to learn more, and use the offer code EB09 at checkout to get 10% off your first order. And by Voltoro.com, the gold to Bitcoin exchange. Trade gold to Bitcoin instantly and securely, starting at just one milligram. Go to Voltroil.com to deposits of Bitcoin and start trading today. And by CoinCap.io, with over 500 all-coin exchange rates updated in real time,

CoinCap is the authority for cryptocurrency market information. Hi, welcome to Epicenter Bitcoin. The show which talks about the technologies, projects, and startups driving decentralization and the global cryptocurrency revolution. My name is Sebastian Kuchio. My name is Brian Fabian Crane. We're here today with Mike Huron. Mike has been on the podcast before, I think, just over a year ago, or just about a year ago.

Episode 25. Episode 25. And we're back today to talk about a super important topic that I think anybody who's been following to Bitcoin News has not managed to miss, which is the whole debate about increasing the block size from 1 to 20 megabyte, and there's been a lot of controversy about it. has been one of the, I guess, thought leaders or the ones driving that discussion on the one side. So I'm super excited that he's able to join us today. Thanks for coming on, Mike.

It's a pleasure to be here. Yeah, it's, I mean, you were working on Lighthouse before and we can come back to that at the end. And I think recently, like many, I mean, the Reddit has been literally plastered with posts about the debate, about increasing the block size. And I gave a talk about this topic at the conference in Prague just recently, and on the way I read through the entire Bitcoin Dev mailing list, and it was as well there, completely preoccupied everything. So to give some context for our listeners,

can you talk about why this has come up so much and what the problem is we're trying to solve in this first place? Yeah. So years and years ago, when Satoshi was still writing most of the code for Bitcoin, he put in a temporary, like, cludge, if you like, a temporary hack to limit the maximum size of a Bitcoin block to one megabyte. And as there's one block on average every 10 minutes,

and transactions take up space in blocks, that implies there's a limit on how many transactions Bitcoin can handle. When he did this, it was sort of, he wanted to avoid people creating really, really massive block. by just stuffing them with rubbish. It was basically an attempt to fix a potential way that people could bloat up the blockchain and just attack the system

if they just wanted to troll and cause trouble. His intention was always that when the block size becomes less relevant to most users, that that limit be removed. And over time, actually, what has happened is every time people have talked about bumping this limit or even removing it completely. It's triggered these sorts of big debates

and the group of people who were, you know, sort of succeeded. Satoshi didn't agree. And so nothing was done. And now what's happening is that our traffic levels, they're growing. Well, our traffic levels tend to grow in the northern hemisphere winter and then they sort of stagnate a bit in summer because everyone's outside. Is that the reason? Yeah, that seems to be the reason why these...

It's not uncommon for Internet services to show seasonal growth patterns like this. I've seen this many times before. And so it looks like, you know, after next winter's growth season, assuming, you know, Bitcoin does grow as like it did last year, then we will, Bitcoin will be full. We will actually run out of capacity. And so this debate has come up now because Vladimir van der Leyen, who is a Bitcoin core maintainer, in theory he's a decision maker.

He posted the release schedule for the next couple of releases of Bitcoin. and I emailed him and said, look, given the schedule, we're going to run out of capacity unless we make a decision right now. And then that sort of kicked off this whole thing again because he wasn't willing to make a decision there. So you mentioned that there are different sides to this debate.

Can you talk about what the different sizes are? The different sides? Yes, of the current debate. Yeah. Well, there's two. There's obviously there's a side. that myself and Gavin have been championing by writing articles and doing testing and simulation and working through the objections, and that's raised the block size limit, of course,

add capacity to the system effectively. And then the opposing side is saying, no, we don't want capacity to ever increase. We want it to stay as it is. And then when Bitcoin fills up, people will be forced to migrate to other systems. That's the debate. It sounds a bit ridiculous when I phrase it like that, but that's actually the core of this debate, and it is a bit ridiculous, I feel. I mean, of course, there is some subtlety we can talk about later, you know, especially when it comes about the idea of security, and I think that's one of the sort of, I still think they're slightly wrong about it in that I don't believe it actually will increase the security. but of course one of the reasons why some people are against increasing the block size

is because they think blocks need to be filled so people compete for space and miners make more money when the block award goes down I mean there's a lot of different arguments that have been marshalled in favour of doing nothing and a big chunk of the work that myself and Gavin have been doing in the last few weeks

is going over all of those arguments and you know responding to them and debunking them effectively so yeah Most of these arguments coming from a small group of people who they don't want to see Bitcoin grow effectively. And then they're constantly coming up with new reasons they've thought of why it would be bad. So it's sort of the cart before the horse, I feel, a little bit. But we can go over the different arguments, if you like.

Well, I think before we dive into these arguments, can you tell us a little bit about what you wrote in the blog post, especially in the crash landing post, because I thought that was a really, sort of a really vivid illustration of what a worst-case scenario could look like if Bitcoin runs out of space in a sort of relatively unprepared manner, which may well be the case if it happened soon.

Yeah, sure. Right. So for background, I worked at Google for about seven and a half, nearly eight years, and several of those years, three and a half of those years was spent doing capacity planning and traffic management for some of the world's largest websites where I worked on Google Maps. I was on call for Google Maps and Earth. So, you know, I have experience of capacity planning for systems and I know what happens when they

went out of capacity because I've actually seen it happen. And so I wrote this article because there was a lot of people who maybe don't have experience like that who are saying, oh, it's no problem if we run out of capacity. You know, there will be this nice controlled fee market will establish establish itself and everyone says, oh, I love markets. I'm a capitalist libertarian, you know, market-loving person. So what could possibly be bad about that? But then when you, when you just drill down into technical details, that's not actually the guaranteed outcome. And there are many other outcomes which are much worse, right? You just have to work through how does Bitcoin work at a technical level to see this kind of thing. So I wrote this article to explain, you know, what could

happen. And, you know, the ways that software can malfunction, the way that, you know, Bitcoin can destabilize and, you know, the consequences of actually hitting the capacity limits. Can you talk about what that scenario would look like if we were to hit those capacity limits, as you described in your article? Yeah, so what tends to happen when systems run out of capacity is, firstly, the service degrades simultaneously for everybody. There's sort of an assumption in some of these arguments for leaving the block size as is, that, you know, we would get it's nice priority ordering of where people would pay higher fees and so on. But what actually happens is, you know, people just keep paying the fees they are paying right up until the point where,

you know, blocks are really, really full and you're seeing hugely unpredictable confirmation times. So the first thing that happens, and we're already starting to see this a little bit, is people send payment and they expect it to go through quickly and they discover it takes, you know, six, eight hours maybe to go through, which can easily interfere with business, right, if you're expecting it to be much faster than that. So that's the first problem. And the The next problem that can happen is, you know, if you actually, if the rate of incoming transactions becomes permanently higher than the rate at which they're being put into the blockchain, you can get this ever-growing backlog.

And the backlog of transactions in Bitcoin nodes is stored in memory, which is, you know, often a quite limited resource. So just before you go into that, I just had a question regarding what you just said. Do you think that the transaction value would increase because people would just resend those transactions assuming that they didn't go through or something like that? Why would, why do you assume that they would increase? Well, I mean, we're talking about organic growth here, right? As Bitcoin ads users, growth goes up naturally.

And then, you know, the coordination of the Bitcoin community globally is not, you know, it's not like everyone reads Reddit or everyone follows mailing lists or whatever, right? So as Bitcoin grows and people show it to their friends and other people hear about it in the news, you know, they download the software, they get some Bitcoins and so on. And then so traffic is going up over time. And then, you know, as that sort of natural organic growth hits the ceiling, what you do start to see is cases where people say, oh, my transaction is not going through. So I'll be broadcast it. I'll send another transaction. You also start to see, you know, people who were holding coins, but suddenly their faith in the system is shaken. And now they decide now is the time to get out. So they start moving coins into exchanges. And if you look at graphs of transaction activity, whenever there's a big change in Bitcoin prices up or down, suddenly a whole lot of coins that were stagnant for the time start to move. And so, you know, if you get a sudden step change in people's confidence in the system, then this causes another increase in traffic, which, you know, causes almost a kind of

cascading failure, and it gets even worse. An analogy of this is, you know, when we had outages of major websites at Google, we would actually see traffic go up and not down short for temporary period of time, because people would try and load, you know, YouTube, for example, they wouldn't load, and then it'd reload, reload, reload, they keep trying because they really want to watch their videos. And so suddenly, normal traffic changes completely and often you get pushed into an even more extreme overload situation as everyone simultaneously retries. So it can be quite hard to recover from that, actually. And then of course, even if we assume like those things don't happen and sort of an ideal thing, I mean, if you start having, you know, 1.1, 1.2, 1.3,

2 megabyte of transactions every 10 minutes. And there's only... one megabyte to go in a block, well, the amount of space taken up by these transactions that aren't in a block just keeps growing, growing, growing, and that's never going to stop, right? And then, of course, that can be even exacerbated by

situations like that, where people panic and everybody tries to, people resent transactions. Yeah. What would actually happen is, you know, people would, there'd be a spike in traffic as people, you know, suddenly lose confidence in the system and try and get out. And then, you know, as a

system slowly turns this way through these, the usage would drop again because people would say, this is stupid, I'm not going to use Bitcoin, right? My transactions aren't even reliable. You would get, if the blocks were completely full, you know, you would get cases where people are trying to pay for things, you know, pay for a coffee, for example, is the classical example, right? And then it would never confirm because they would blast it onto the network and then discover, you know, they weren't paying enough fees to ever be confirmed. And then payments would just break, basically. It wouldn't be this nice fee market. The user experience would be just paying people doesn't work. And then people would get upset. You know, they would feel betrayed

because they put all this effort into evangelizing Bitcoin and telling their friends how great it is and how cheap and fast it is. And suddenly it's expensive and slow and it's not working. So they would leave. So let's come back to the client. So the mempool start filling up. And can you explain then what happens after that? Well, no one knows because it's never really happened before. But some nodes will eventually, if this keeps up long enough, will fall over and crash because they don't have any limits on how many transactions

they will store in memory. And it's not entirely clear how long it would take to do that because, you know, it's obvious that it would happen eventually if pressure is higher than, if demand is consistently higher than supply, but like I said, you know,

users will also give up and go away. So while, you know, it's possible that we could have a sort of crash scenario where nodes actually start quitting basically, being killed by the operating system and have to manually be restarted. You would see a lot more like network instability, the network would shrink. But, you know, we don't know exactly how quickly that would happen. So regarding mempools, so I learned about this, you know, through your blog post.

I'm curious, why do these transactions stay in RAM? Like, it seems like a weird software design choice to have these transactions stay in RAM and not get written to some file on the hard drive effectively, like not causing it. so much bottom like on the system. They could be, but bear in mind that, you know, Bitcoin's original design actually had a limit of like 32 megabyte blocks because that's the largest message that can be passed on the network. And holding 32 megabytes of transactions, even in the average case, you know, even if you double that and get 64, 70, 80 megabytes of data, and even if you add a bit of, you know, overhead, because a transaction in the mempool is not

represented as efficiently as it is in the blockchain, I'm sorry, even if you take into a kind of all that overhead. You're talking about like 100 megabytes of data maybe, which is very cheap. So why was Satoshi, you know, having code to write stuff out to disk and load it back again is additional complexity. And from Satoshi's perspective, it's just unnecessary complexity. Right. So why would you, why would you implement that? Well, for this reason, exactly. Well, but he never planned for Bitcoin to run out of capacity. This debate would appall him. Everything he always said was like, no, no, no, no, Bitcoin can scale up. This is no problem.

This is no problem. This was like the first question he was ever asked about Bitcoin. and he explained this is no problem. So the fact that people would actually want Bitcoin to run out of capacity artificially isn't something that he would have ever planned for. I mean, I think also one of the ways to think about this whole debate is to think about it through the lens of the sort of outsider, right?

The person who's been sort of known a little bit about Bitcoin, but they're not deeply involved in it like we are in following all the discussions and debates and know that different trade-offs. Because, I mean, if you talk about, about Bitcoin to lay audience or technical audience you know there's some ways you have to explain it and I think there are certain metaphors people come back to like for example you know it's money is like it's information and and sending it

should be like fast and instant and like global and cheap yeah you know that's like one of the things that we always tell about and it's like hey dead the remittance use case whether or not that's actually being used but it's one of the it's a great way to illustrate how powerful it could be be, you know, if someone can send like instantly money for free or, you know, for a few cents from Kenya to China and it's there. Yeah. Right.

So when you now think of like, but let's say this does happen and you start having one of, first of all, it starts taking a long time to get confirmed. Second of all, it starts getting really expensive. And then also think of the user experience. Let's say you send out a transaction and then you have to work. wait and you don't know if it gets in a block or not. And if not, then you have to, you have to think about what fee. Even that like is a crazy idea.

And then we send it, it all, everything breaks down. Yeah. And I, I saw somewhere on Reddit, Luke Jr. make this comment. Um, he was like, yeah, I mean, it could be, right? But if it does break down, then I'm sure in a few weeks we could like, uh, come around. and then we could do increase the block size. And then that's just, in my view, this is so delusional, you know, the idea that you have a few weeks.

Because, I mean, I think Bitcoin is very fragile in that way, and that the trust is extremely important. And if the trust falls away, they believe in the system. And it has already, even with things that as Bitcoiners, you think, well, they actually have nothing to do with Bitcoin, like Mount Cox, right? Yeah, right. In a way, it wasn't a problem of Bitcoin. Bitcoin, but it hugely undermined the image of Bitcoin.

And I think of something like this happening, where it is actually a problem of Bitcoin. I think it would be a huge disaster. Yeah, I agree. It's time for work from our sponsors, Ledger. Now, if you've been into the Bitcoin space, if you've been following this, it's no mystery to you and it's no news to you that security and securing the private keys is so important. And when I got in first got involved in the Bitcoin space, I heard the same thing. thing and I was like, I'm going to be a model of Bitcoiner. I'm going to do it the right way.

So what I did was I bought this like re-furbish cheap old netbook for 100 euros on eBay, and I set up army on there and have an offline army and online army and try to run a full node on my laptop. And it was a truly horrifying experience. And I still have not been able to get my bitcoins off there. Well, I could, I guess, but, well, not with Ledger. That's right. Here it is. This is the ledger. This is what I use to secure my Bitcoins. You plug this into a USB port on your computer, and you can use your Bitcoin wallet on any system, even if it's pest filled with malware, your Bitcoins will remain safe. And by the way, we have a special offer for our listeners. If you're interested in securing your Bitcoins right now and have it be easy rather than difficult, you can go to ledger wallet.com and use the offer code EB-09, and you'll get 10% off your first dollar. And by the way, if you're interested in learning more about Ledger, you can also listen to episode 2C1.

of LTV with Tomah France, who's the co-founder, he explains how the product works. Also, you know, goes into detail about the roadmap of the company. They're building some really interesting infrastructure for Bitcoin security. So go to ledgerwalt.com and give it a try, and we'd like to thank Ledger for the support of Epicenter Bitcoin. Do you have any idea? Can you guess? It's hard to quantify, I suppose, but this crash landing over how many days or weeks are we

talking about here? Like, how do you think? that would play out. I don't know. I've never seen Bitcoin rent out of capacity before. Of course. Of course. But are we talking days? Are we talking weeks? Are we talking months here? I would say there would be problems like the build up. Well, there are going to be problems from now on, actually, because blocks are already sometimes being full and we're already seeing backlogs. And for example, Bitcoin wallet for Android by, you know, Andrea Shilbach, he's already bumped the fee paid by default. So we're going to see more and more of that over the next 12 months.

So that user experience degradation will keep happening steadily. And then if we reach a point where every block is at the minor maximum, whatever they've got it set to, then I think we would see problems within days. We would see serious user complaints within days and serious, serious technical problems within weeks. But it's hard to say because the moment these things break, right, what happens is users abandon the system and then the pressure goes down again. So what we might happen is this kind of bumpy equilibrium where users complain a lot,

another batch leaves, you know, leaving behind only the more hardcore types who are willing to stick it out. And it might be that the system never really stays over capacity for very long because demand falls away. I think it was Gavin Andreessen who said, I believe it was on the list on Bitcoin. He saw it differently that he didn't think that we were going to reach the capacity cliff in some sort of catastrophic crash landing as you described in your blog post. but that people would, in fact, when we start reaching limits,

people would in fact start leaving, perhaps resort to other means of sending transactions through off-chain solutions or, I don't know, I thought perhaps all coins. Or just stop using Bitcoin. Yeah, yeah. Yeah, a lot of it depends on time and events we can't predict. Like if there was kind of a panic, you know, if you start seeing articles in the New York Times saying,

you know, Bitcoin on Brink of Technical Collapse and then lots of people who bought some coins, have them lying around, but otherwise weren't really paying attention to the Bitcoin community, which I think makes up quite a lot of people from people I've talked to. And then they all suddenly try to sell their coins. Then, you know, that sort of spike driven, like press-driven spike could cause sudden unexpected problems. These things are very hard to predict, though. I don't want to put my hand down and say, that's exactly how it will play out.

We should never, ever even get close to finding out, right? Of course. That's like a complete disaster if we ever even get close. to this. I mean, maybe I'll come back to that. Let's first talk about some of the arguments against this. So it's, I don't know where to start. So personally, I have really difficulties finding them very convincing. And maybe, maybe let me give this context first. So the way I think about this whole question of increasing the block size, right, is that you look at how does Bitcoin work today? And then we think of like what will happen when the transaction volume increases.

And then you have two scenarios, right? Either you increase the block size or you don't. And then the question in my view is, which is the bigger change? And I think it's pretty clear to me that full blocks are a much more radical change to the network than having a higher block size, right? Yeah. So I think in that context, if you want to leave the block size the same, that is the thing that has to be justified. That is the thing that you have to put research behind and stuff. Whereas the sort of argument I see a lot of people doing,

but there's not enough research. We don't know enough what happens with the 20 megabytes stuff. And maybe that's true, but I think it's much more clear to me that there's even much less research. It seems nobody has actually, for example, written up coherently how such a fee market could work.

Right. It's just like they say fee market and then think that solves it. Yeah, I agree. I think, you know, if you can imagine it's another way, if there had been no limits and now people arguing to put this limit in place and to force Bitcoin to run out of capacity and they were arguing for it instead of, you know, for the status quo, I don't think anyone would really, you know, go for that. I don't think they would get anywhere, right?

People would say, no, it's working fine. Why would we do such a thing? Why would we make such a change? So unfortunately, this is basically a case where, you know, Bitcoin is sort of riding along on inertia, and things that Satoshi would have not even hesitated to do are just not getting done. So, okay, so let's talk about a few of these arguments. So one of them was Peter Todd said on the desktop Bitcoin episode.

We'll have a link to that in the show notes as well, is that you won't be able to run a full note behind Tor anymore. What do you think of that? Show me people who are doing that today. I mean, this is a trivial number of people running things behind Tor. You know, the idea that, so he talks about this in terms of people running nodes in countries where Bitcoin is banned or being censored, right? And, of course, they can use Electrum or something like that.

Yeah, I mean, they don't have to run a full note. But even if you accept they want to, you know, they can use VPNs, for example, which are far, far more popular than Tor has ever been for evading government firewalls and things. Right. if you look at the popularity of a, just to pick one commercial VPN service out of thousands, hotspot, not a hotspot, sorry, yes, sorry, it's called Hot Spot Shield. And it's done by a company with Anchor Free, and they are orders of magnitude larger than Tor, right? Whenever there's a major censorship event in, say, Turkey, their traffic goes up, you know,

by around, you know, thousands and thousands of times more than what Tours does. So this fixation on TOR, you know, it doesn't really make any technical sense. when you look at the market. And this idea that if you're in a country where Bitcoin is banned, you're going to be mining and things, it doesn't seem like a very realistic idea to me anyway. Yeah, I know I agree with you. I mean, I'm pretty sure, like, doing this right now

would be a pretty miserable experience trying to run a full note behind Tor. Well, yeah, right. It's not, I mean, it's adding a lot of latency for no real reason. You don't need Tor to get through firewalls. And when you're up against Svigman, this. I mean, it's pretty clear that you're trying to make an engineering argument in front of an ideological argument. So, I mean, it's sort of like trying to argue with fundamentalist Christians in some way. It feels like that sometimes. It is a bit of a caricature, but that's what the

extent of the debate, right? It's been a major frustration of me and Gavin for a long time now. We've been saying, look, you know, make a proposal, put numbers in it, right? When you object, put numbers in your objection, right? We're supposed to be. engineers here to do engineering. And what you get back, the people who are against these sorts of things, they have never ever done this, right? They never sit down and they do, they never do back of the envelope calculations and the way that engineers do.

And it's incredibly frustrating because they often pick some extremely academic or theoretical points and just assert it as truth. And if you don't agree, you must be an idiot. So these sorts of engineering-based arguments, you know, Tour isn't that popular. There are other systems that are. They work just fine for mining if you want to do that. then they don't convince these other people because they weren't really open to being convinced in the first place.

So there is one point I think that that does probably have some validity, and I'm curious on your view on that. So one question, right, is what kind of an advantage do large mining pools have of small mining pools and over solar miners? I mean, of course, one is the variance, but then there are other things. In particular, there's a risk of getting orphaned. And orphaned means basically if you mine a block, you find a block,

so you think like you may get the block reward, but then someone else finds one around the same time, and in the end you lose out. And you are a disadvantage with that, if you're a small mining pool. And some listeners may remember the episode we did about selfish mining with Amy Green Syria and Ithai, AI who wrote on this. So it does seem to be true probably, right,

that if you have bigger blocks and they propagate more slowly, then actually becomes a little bit more of a disadvantage, right, if you are a smaller mining pool as opposed to a bigger one. Is that a concern you have? Well, no. So Gavin has written about this quite extensively. You know, if everyone is making bigger blocks, then the orphan cost doesn't change

because your competitors get orphaned as much as you do. So in the end, it washes out. If you're making... If you're a bigger mining pool, you get less orphaned, right? No. It has nothing to do with how big your mining pool is. It's to do your connectivity, right, and your connectivity to other miners. But in terms of the number of people hashing on your pool, it makes no difference. Well, but if you find a block, right, and you immediately start mining on your own block, right?

Because it doesn't have to go anywhere. Yeah. And so if, so that's an advantage, right, if you're a bigger and minor. If you get blocks more frequently. I mean, the point of the difficulty adjustment is you shouldn't be, you know, finding a block immediately after another block that you've just found, like, with any frequency, right? That will happen very, very occasionally, but it's not supposed to happen frequently. If it is, then that the difficulty adjustment will kick in and...

I guess the way, well, you can think about it is this way, right? So if you find a block as a mining pool, then there's probably some period if someone else finds a block there's probably some period you're not mining on that longest chain so your work's probably wasted but if you're the biggest pool and you find it and then you can immediately mine

on that like that time you lose because you don't have the longest chain is less compared to other pools I mean I think this is probably true but it's also it's a fairly small effect and there are all kinds of other things having that effect as well.

Yeah. I mean, with respect to the orphaning costs and so on, I mean, it's fairly low today. But we don't have a optimized protocol really at all, right? So we've known for a long time that we can, every transaction is broadcast twice in the Bitcoin network, which doesn't make much sense. There are various ways to fix that and so on. Gavin has researched some of these mechanisms. But, you know, bear in mind what we're raising, what we want to raise here is a hard limit.

whenever you have a system, a large software system, there are a variety of scaling bottlenecks, right? You encounter one, you remove it, then you move on to the next one, you remove it, you remove it, you move on to the next one, you remove it. There's always going to be a next bottleneck to fix. So, by, you know, it looks like we're going to hit this self-imposed one fairly soon.

So right now the effort is on removing that one. And then maybe we get up to four megabyte blocks or whatever with enough time and organic growth and growth of the Bitcoin user base. And then we discover that mine is, don't want to go beyond four megabytes because of orphan costs or whatever. And they're deliberately capping the size of the blocks they make to less than the theoretical limit. That's called a soft block size cap, right?

A soft block size limit. Then we say, okay, then that's the next bottleneck. And then we work on fixing that. So I'm not too worried about this because, you know, we can see some of these bottom legs coming up. We don't know exactly where they'll hit, but we anticipate at some point they'll exist. And there are solutions already being researched and worked on. So we want to have to ask that, but maybe we can, we can,

we can clarify this right now. So with a soft cap or a soft book, is that just a minor? Yeah. I mean, right now, a miner can mine empty blocks if they want to, right? Yeah, exactly. Is that this, so does that just mean that if you have a 20 megabyte limit, a miner can, of course, mine blocks of whatever size up to 20 megabytes?

Yeah. And is that achieved through consensus of miners, or does everybody do what? they want. It's just a configuration setting in Bitcoin. Okay. Because right now that's with 750 kilobytes now. Well, that's the default. I argued, or I vaguely recall arguing when this was set to 750 that it should just be set to one megabyte. It shouldn't be effectively this often, the hard limit should be the same. And I wish we'd done that because now we have some miners who aren't, they don't know about this setting or they don't care or, you know, whatever. And they just leave it at the default. And so we're actually, we're hitting,

capacity limits even earlier than we should be, right? Just because miners aren't really paying attention and they're not raising this soft limit. So when we move the hard limit to 20 megabytes or whatever the final patch is, one of the issues that I'm going to be looking at is what do we do with a soft limit? And I think the correct solution will be to default it to the same as the hard limit. So by default, miners never throttle their block size deliberately. Yeah, yeah. And they can, okay.

So regarding, I had a question regarding network propagation where we were just talking about earlier, where large miners are at an advantage over small miners. I think that the assumption is that large miners have a much faster internet connection that can upload blocks a lot faster than a small miner. That's where that would be, no, am I wrong? I think you're wrong. I think large miners have an advantage mining, but that's just the way right now.

I mean, bear in mind the Satoshi set 10 minutes interval on the idea that blocks would take one minute to propagate and there would be 10% wastage of work for orphaning. And he was like, yeah, that sounds fine to me. If there's 10% then that's cool. So obviously miners were incentivized to make as much profit as they can, but they're also incentivized to move people's transactions

because otherwise Bitcoin doesn't have value. So there's some kind of interplay there where some kind of orphan rate is acceptable and miners have all the tools they need to figure that out. And at the software and network level, we have the tools to reduce it. well. Let's address one small point. I think that's also a strange argument I've seen. So Greg Maxwell brought up in one Reddit post that, you know, as many people know, the number of notes

on the network has decreased dramatically. It was, I think, about the $100,000 at one point, and now it's about $5,000. And, you know, that personally, I'm not sure if this is related to the block size very much, to some extent, perhaps. But just, you know, but just, you know, Do you think that, first of all, do you think it matters how many nodes there are? And do you think there is some sort of lower limit or amount we should strive for? And do you think if the block size was increased at 20 megabytes, this could maybe worsen this and decrease the number of nodes even further? Yeah, I think I need to dig in a bit.

I think the claims that we had 100,000 full nodes at any point are a bit dodgy, to be honest. These days, we count number of nodes because we have pretty good network crawlers that have been tuned. and they call the network and they measure up time and they ignore nodes that come and go quickly and things like that. Whereas several years ago,

we didn't have that. And the way we had accounting nodes was not that great, to be honest. We weren't like measuring whether these nodes are stable and fully reachable and stuff. So I doubt we've ever really had 100,000 full nodes

in the sense we would use a term full node today. But sure, if it was higher in the past, even once good callers were established, you know, we were seeing like 9, 10,000, nodes and it's shrunk now. The number of nodes we need in terms of need for the technical operation of the network to function is dependent on how many SPV wallets we have that are synchronizing

with these nodes. And we don't have any idea how many nodes we need for that. It's one of the sad things about Bitcoin engineering that, you know, all this work is being put into this arguing and actually very little work is put into basic measurement and metrics. So we don't really know how many nodes we need to serve the current user base. But apparently 5,000 is a lot. 5,000 is a lot of machines, a lot of servers. Just to put it in perspective, when you think about how much work can 5,000 computers do,

all of WhatsApp was at one point running on 1,000 machines. Now, 1,000 very good machines with very tightly optimized software, but still a much smaller group of machines in Bitcoin today. And they were rooting a million messages a second. So way beyond, you know, our one or two, per second, which is what Bitcoin is doing. So we have a lot of computers doing not very much in terms of serving their network.

So if we assume that Bitcoin continues to grow, but let's make the assumption that there are less nodes as a result of the block size increase, what would that do to the network stability? What would be the impact on potential censorship or centralization, like issues with regards to centralization of Bitcoin?

Well, I wouldn't worry much about the centralization, bear mind anyone who wants to can run a full node. And in the past, a lot of people were forced to, even though they didn't really want to. So there's a natural decline as, you know, better options for those people come along. You know, like a lot of, the original

idea, right, is all merchants will run a full node. And in the beginning they did, but these days, we have companies like BitPay and Coinbase, and they handle lots of things, including running nodes for you. So that's more centralized. And if those companies, but, you know, it's a sort of a weak form of centralization, because you can

imagine if BitPay or Coinbase started charging really high fees or they got really bad policies or whatever, then people would say, okay, I'll just run my own nodes and I'll put my own storefront in front of it. It's not that hard. So to some extent, you know, people not running their own nodes is a matter of convenience, right? If they wanted to, they certainly could. And the actual number of nodes we need is, yeah, like I said, dictated by the serving capacity for these other kinds of wallets. If need be, you know, there could be techniques to incentivize the running of nodes paying for their services, things like that, but I don't see any signs we need that at the moment.

So it's Stanford for our sponsor of WorldForard.com, the gold Bitcoin Exchange. Now, you may be asking yourself, why do I need gold? I have everything I need. I have my TV, my couch, and I have my bag of Bitcoins. But gold, after all, it has been around for a little bit of gold. longer than Bitcoin. And Josh, the CEO of Boltro, wrote an interesting article on the Boltero blog, will link to it.

And he was writing that a lot of the central banks, a lot of the governments around the world are hoarding gold. And the reason of course is that when a financial crisis comes, that's the one thing you can sort of fall back on and still there. So maybe that's something to consider as well when you are thinking about your own central banking policy. My central banking policy is to buy gold, and I use Voltoro to do that. And so you can go to Voltoro.com and start trading today, and it takes literally minutes to start buying your first milligrams of gold.

Because you can start trading at just one milligram, and the trading fees are as low as 0.2%. And by the way, there's no KYC required for up to $5,000 risk of deposits per day. So you could really use this as a way to hedge some of the volatility risk that you have when you're holding Bitcoin. So there you go. So go to Valtoro.com, give it a try, and we would like to thank Valtoro for their support of WebCenter Bitcoin. Let's address one of the, one of this, maybe a bit bigger, bigger picture and more important issues in this debate. And I think that's a question, you know, is Bitcoin, like the sort of core Bitcoin where transactions are actually in the blocks? Is that scalable at all?

Can that at one point, or is it even desirable to try to make that scale to a point, where it can handle, I don't know, maybe thousands or thousands of transactions per second. Or is really the future that transactions move off-chain, hopefully in some sort of trustless ways like the Lightning Network. And that sort of evolution is natural. And I mean, I guess you can agree with that, and then you can still not agree with the related point that a lot of the developers make

is that this evolution is natural and we need to sort of force it to move that way by not giving people any space that they have no choice. What are your thoughts on? First of all, will transactions have to move off chain?

And second, is it desirable to try to... Yeah. You know, I think in this case what we should be following is Satoshi's original vision for this system for a couple of reasons. One is it's actually a pretty well-thought-out vision you know, people questioned it on, questioned him on it the moment he announced Bitcoin, even before code was available.

And he'd already fought through these issues, right? He had thought about scalability a lot. He made, you know, he made claims like, oh, you know, even if we scale to visa size, then, you know, it's just the equivalent of moving a few HD movies per day. You know, he'd done the calculations. That I said, even though he had done that, you know, he picked a reference point, which is visa, which is not a bad reference point to pick. if you're trying to design a financial system. But then he went further and he said, you know, maybe people want to do really high frequency trading with each other.

Maybe you want to see like, you know, 100 trades per second just between a few people. And maybe that doesn't need to be on the blockchain. So he designed these high frequency trading protocols on top of Bitcoin. And the modern concept of lightning networks and so on is sort of vaguely based in some of the things that he was doing there. Even though the original mechanism he designed got disabled a few years ago. So he thought about these things and he drew some lines in the sand.

He was like, yeah, we could totally move all of the payments being done with credit cards onto Bitcoin. That would work. But if you talk about high frequency stock trading, that wouldn't work. And he designed other mechanisms for that. So there's clearly some kind of line somewhere. And I think where he drew the line is pretty reasonable. Drawing the line at one megabyte blocks and then saying everything else should be done on this different system, actually, even if at the end of the day it settles on the blockchain, that's not reasonable.

I don't see any, you know, if you try and convince me that that's a good idea with the maths, I won't agree because there's just no credible. If you just look at what computers can do and how fast they are, it doesn't make sense to draw the line there. So I think we'll see, I think it is perfectly reasonable for Bitcoin to process thousands of transactions per second, right? I mean, there are websites that handle thousands of hits per second, lots and lots and lots of them do that. And we don't say, oh my God, you know, the web is decentralized, even though you wouldn't run a website that handles that sort of traffic from home. you know, people just don't do that. But, you know, the web is still a decentralized system, right? So I would worry about it less than other people do. But do you still think that it's likely that we'll get to the point where the same Bitcoin network is handling really large high-value transactions and really small transactions like coffee or even micropayments? Well, why not?

I mean, people pay for, you know, expensive holidays and very, you know, even quite expensive of things with credit cards and then also for their cups of coffee. I see no reason why the monetary size of the transaction should matter. But if we have systems like the Lightning Network, and I do realize that it's only a white paper for now, but if those types of systems get implemented and we have really fast payments which don't necessarily require like a 10-minute confirmation time and are significantly cheaper than perhaps what Bitcoin would offer, if you have all these higher value transactions

and fees start going up, don't you think people would start using those rather than using Bitcoin? Yeah, it could be. I mean, if some lightning network issue or Strom or whatever system is, you know, layers on top of Bitcoin, I mean, I think it's very likely we will see systems layer on top of Bitcoin. I'm a little skeptical that will be

lightning network specifically, but it might be. And that's fine, right? If that's the way the system evolves naturally because that's what people want, then that's okay with me. people being forced into it whether they want it or not is definitely not okay with me. I think if you look at ways in which people get faster payments on top of Bitcoin, I think the use of trusted computing is a lot more reasonable, a lot easier to deploy. And frankly, it's probably closer.

I know there are companies working on this stuff already. So from a technical perspective, I'd say the use of remote attestation and trusted computing is a lot more likely to give us super high confidence. instant payments with Bitcoin than Lightning Network. But these are technical issues on which reasonable people can disagree. Yeah, I mean, I think there's the Lightning Network, it kind of makes sense to me. I think it's a reasonable idea and it's all. But I think what's been really deceptive and maybe intellectually slightly dishonest is sort

of confusing those two, right? Because first of all, it's clear that it's not nowhere ready. I mean, we did an episode with them and they themselves said that. And the other thing they also said, well, the two other things, first of all, even if it worked, they still would need much bigger blocks. And even if actually people only were using the Lightning Network for all, if you want to have Bitcoin at some scale, you know, people have to open and close channels

and they actually have, you know, multi-six transactions with a larger. So there's no question you still would need to increase the block size significantly. And then the other thing, they said, well, their security model actually becomes worse if the blocks are full, because that's a problem for them too. So it's clearly whatever one thinks of it, it is clearly not a solution to this. And of course, it's also very complex to do, right? There are a lot of aspects like this whole server stuff, one needs to build, the wallace need to change,

mergers need to change to that. So the idea that this is somehow achievable in a really short timeframe is, quite obviously not true. Yeah, and I agree it's obvious and I wrote an article laying out why it should be obvious and it sort of disappointed me that, you know, the block stream guys ignored that completely and now they actually hired a guy called Rusty Russell and said, oh, you work on Lightning Network and he published a blog post, it was either today or yesterday, where he outlined exactly the same conclusions. He said this is not going to deliver a solution in the time frame we need, we need bigger blocks. So everybody who has looked at this and the people who proposed this

originally in their white paper to myself to Rusty a Blockstream have all said this is not going to happen. We need bigger blocks. And unfortunately, this doesn't seem to have any impact on the people who are stalling this debate. Today's magic word is Spoon. Spoon. S-P-O-O-O-N. Go to let's talkbidcoin.com to sign in, enter the magic word, and claim your part of the listener reward. So let's talk about another topic has come up in this discussion, especially on the mainlandness. So Gavin Andreessen proposed that if there was no consensus on increasing the block size, that he would start pushing developers, companies, startups within the ecosystem to move to Bitcoin

XT, which is a fork of Bitcoin that you developed. Can you first talk about what exactly is Bitcoin XT for those who perhaps don't aren't familiar with it as I was, and also why this would be a possible solution to resolving this debate. Yeah, it's actually not my preferred solution. My preferred solution is that Gavin revokes commit access from everyone else in the project, and then makes a change himself and says, this is Bitcoin Corrie has made a decision, and this is how it's going to be.

He's reluctant to do that. Sounds pretty dangerous, right? That's going to get a lot of it. Well, I mean, I don't know of any other open source projects that have this notion of development by, you know, quote, consensus, which is, we can talk about that in a minute, but it's not really developed by consensus. Every project that I know of, certainly every successful open source project has a kind of benevolent dictator, is what we call them. Someone who makes a decision, a technical leader. And Bitcoin Core doesn't, and that's a big part of the reason we have this issue. So Bitcoin XT is the same program as Bitcoin Core with very small number of modifications to it.

And this BitcoinXT arose last year because I needed to add a feature to the Bitcoin Protocol for Lighthouse to make its user interface perform well, basically. So I prepared this change and I submitted it for inclusion into Bitcoin Core. And there was this massive dispute, massive technical debate, not quite as big as the block size, but it went on forever. Same sort of thing, a lot of the arguments made against this very simple 50 line change didn't make a whole lot of sense to me. And eventually, actually, Vladimir, he did integrate it into Bitcoin Core. And I thought, oh, well, you know, that took forever, but at least it's done. And then a few days later, you know, it got reverted by some other guy who has commit access,

so I won't name. And then when I submitted it again, he was like, oh, this is quoted shitstorm. I'm not going to touch it. I threw up my hands at this point and I said, look, you know, you guys cannot make decisions and stick to them. I'm going to, I need to launch Lighthouse, right? I can't wait around for you guys all day. So I'm going to make my own version of it. And that's the genesis of Bitcoin XT. There were a couple of other changes that hit the same problem. It's not just, it's not like me. It's that other people who made proposed changes also hit this exact same wall. And then I went and I fetched

them, fetched at least one of those changes and put it in Bitcoin XT too. So I made it a home for changes where I thought the arguments made sense. They hit this kind of stall, you know, we must have consensus over everything, you know, blocking of changes. Now, just to be clear, the changes that you made in this X-D-4 don't, I mean, it's still compatible with the Bitcoin Core.

Yeah, it doesn't change the blockchain. Right. So, and it does not include 20 megabyte blocks yet. No, currently it does not, no. Yeah. And so what is the, idea then that in some time after some assume like all these startups start using Bitcoin XT, then we include the 20 minute go by block in XT?

What's going to happen is either today or tomorrow I will release another version of Bitcoin XT, which also doesn't include any block size changes, but it just tidies a few things up. And then probably within a week or two, Gavin will have a change that's ready to submit to me for Bitcoin XT, and then we'll integrate that and release it to, as a new version of Bitcoin XT that anyone can upgrade to. And that will include block size increase. Yeah, well, what it will include is code which effectively votes.

So as miners start running this code, they will effectively embed a vote for bigger blocks into the blockchain. And then once the software sees that there's a majority of people voting for this change, then it will start to create bigger blocks. And if at this point you're on the, you're still running Bitcoin core, then you'll get split onto a separate blockchain. So the Bitcoin XT software will communicate, you know, we want bigger blocks, and then it will see how many messages it's to get back. And at some point, if it's a majority, it will switch. Yeah.

Okay. Okay. How does that work exactly? So how does this voting mechanism? It's been used before. So it's the same mechanism that we've used to roll out changes before. every block has a version number in it and miners can for example

set that block version to be block version three for example and then Bitcoin NXT would look at the past it would add up the number of version three blocks in the past time window and then just calculate a percentage and by there, through that

rolling window of time in the blockchain it can see what the support for the change is okay and so what would happen with those miners who remain on Bitcoin Corr, so that means if they mine blocks, they would just get ignored? Yeah, they would go onto a side chain,

and any coins they were to mine wouldn't be recognized by exchanges or merchants that were running Bitcoin XT. Okay. So does that mean, is this going ahead? The plan is to do it this way, and then I guess does that mean, you guys, you and Gavin, maybe some other people who volunteer will talk to miners,

we'll talk to people to switch over to XT? Well, I, you know, I emailed Vladimir earlier today to, you know, have one last attempt at convincing him that this is the correct path forward to grow the block size. And then, yeah, if that doesn't work, then we'll do a, we'll do Bitcoin XT. We've already been talking to a lot of places. We've talked to businesses, exchange owners. We've talked to some big mining pools. We've talked to a whole lot of different stakeholders in the Bitcoin ecosystem.

And the support is extremely strong for Bitcoin XT. Some of these people are just saying, just get on with it already. So we don't know exactly how much support, but we know there's a lot. And what we would do is, yeah, we would pick some threshold at which point the fork would happen and then go and talk to miners and say, look, you need to upgrade. This is what the community wants. So I've got a couple of questions about this. So essentially, then this is a hard fork.

So you're asking people to change their software to another version of Bitcoin core, which is a fork. If you're going to do that, like, why not just ask them to update their software to another fork of Bitcoin core? Well, that's what it is, effectively. Okay. BitcoinXT is just a name for a slightly modified version of Bitcoin Core. But why BitcoinXT? Why not just make a fork of Bitcoin Core and call Bitcoin Core 20? Well, I mean, Bitcoin, yeah, it could have been called Bitcoin Core 20, but when I, you know, I've already, like, done all the rebranding to XT and.

Right. XT is, it has a few other minor changes. It's not just block size limits, right? Okay. And then, so for, for Bitcoin companies that are using Bitcoin Core to power whatever they're building, right? So let's say it's like, I don't know, chain.com or something. Like, they're using Bitcoin Core. I don't know.

I mean, maybe they're using Bitcoin Core, but perhaps there are companies that are not using. Bitcoin core and wallets, for instance. I mean, I assume that Bitcoin J would include all these changes as well because you commit to it. But what about the other Bitcoin clients out there? It would require for them to rewrite their software potentially. That could be complicated. No, not really.

Most wallets don't care about the block size at all. For example, Bitcoin J, you said Bitcoin J would need to be updated. By far the most common way Bitcoin J is used is in SPV mode, in which it doesn't download the full blockchain. In this mode, it doesn't actually know how big blocks are. It doesn't care.

So all of those wallets, all of your bread wallet on iOS, all of your Bitcoin wallets and Hive and so on, all web wallets, for example, they don't need to change,

right? It's only people who are running Bitcoin Core that would need to, or, you know, a re-implementation, like there's one that written in Go

called BTCD. But the actual code change is very small, right? We're talking about, it's not quite just adjusting one number, but it's very small.

Do you have an idea of how many companies are using Bitcoin Core a back end or perhaps have written their own implementation of Bitcoin? They're basically all running Bitcoin Core at some level. Usually if they've written their own implementation, it'll be connected to their own nodes, which they'll run Bitcoin Core, which connects to the P-to-Per network,

and then they'll connect their own version of Bitcoin to their own Bitcoin Core. So a few companies like Coinbase might need to, you know, spend an afternoon writing a bit of code. It's a very small change. And how trivial is this change? I mean, because fundamentally you just take one climb out, put it in the other, but for companies that have rigorous software testing procedures and such, like how trivial would this be for them to actually change that?

How likely is this to happen is basically what I'm trying to get to? It's very trivial for these companies. So the best way to these companies should be organizing things. I don't know if they all are, but I know a lot are, is, you know, if they have software that's calculating a database from the blockchain or whatever it is they want to do, they should just be connecting to their own private nodes, and then they can just take out the block size check. If their software is connecting to their own copies of Bitcoin Core or Bix20XT,

the check is already being made by those programs anyway. So doing it again doesn't actually add very much, right, unless they have some kind of philosophical desire to do it all themselves in their favorite programming language or whatever, in which case, okay, you know, they've taken on the burden of keeping up with changes in the Bitcoin Protocol. And they knew that when they started. Okay. So then in that case, if we extrapolate, so if most companies that you've talked to are on board with this,

we're switching to Bitcoin XT, then what you're saying is essentially that this is going to happen, this block size increase is going to happen no matter what. I think so, yeah. The only question is how long does it take for people to, you know, opt in? do we really have the majority that we think we do? I mean, you know, from polling, you know, going and talking to, you know, important players in the ecosystem, we think we do,

but there's nothing quite like measuring it for real. And then the worst case scenario is the majority of the economic majority that we call it is in favor, but the hash power, the mining majority is not. That would be a very messy situation for Bitcoin. So can you explain that? How would that happen? So you mean that, like, let's say, Coinbase and the big companies and they're all in favor, but the mining?

Yeah, so let's say that, you know, so there's been some concerns raised by mining pools in China, for example, where there's a lot of mining going on, that their connectivity is extremely poor to the rest of the internet for a bunch of reasons. So if the needs of the wider global Bitcoin community start diverging from what, you know, miners in China want, then who wins? Well, the answer is the economic majority wins, right? The wider community wins, but it would require a bit of, you know, a bit of a technical mess to sort everything out in that case. Because you somehow have to get clients to ignore potentially the longest chain, you only accept.

Yeah, so people, again, merchants and exchanges that would be running Bitcoin XT, if we imagine this sort of worst-case scenario happening, they would ignore the longest chain. It doesn't matter that it's the longest. if it's, you know, well, let me rephrase that. They would be forced. They would take the longest chain with that specific version of the software, right? Yeah, so let me rephrase that, right?

Like, if miners were building a longer chain than the 20 meg chain, then, you know, the client would keep switching back to it and will keep ending up with this bigger and bigger backlog. And at that point, what we would have to do is, like, checkpoint blocks into both the full nodes and the SPV wallets. So that's a much larger and more complicated upgrade to force it onto the larger chain, right? And in the worst case scenario,

if the miners and the rest of the Bitcoin community end up in some kind of like full-fledged war, that would basically wreck Bitcoin. So we would hope that miners wouldn't do that. Of course, it's not in their best interests to mess up Bitcoin for everyone. So, but let's say even this XT's switcher and larger block size happens.

I mean, one thing that's really clear, I think if one follows a dev mailing list, there is so much disagreement and animosity and an almost hatred between people. Quite frankly, I find it a bit worrying. And it does not seem to be a lot of sort of cold-headed rational analysis of what's actually the best way to go. And, I mean, it seems if this happens,

And now we have most of the people who have committed access to Bitcoin core are against this. And they will be sort of left behind them. I mean, it seems like that can cause a big rift in the Bitcoin community. Why did it come to this? Yeah, good question. It's been a long time in coming, let's say that. These problems were not unpredictable. You know, I've been talking about them for one.

while mostly in private, but sometimes, you know, these concerns surfaced in public as well. On this show? Yeah, on this show. You know, it's something where I've mostly been talking about this with, you know, like guys like Vladimir and Gavin and other people and guys like Gregory Maxwell as well. What we've, what we see in Bitcoin Core is it started out as a traditional open source project, Satoshi was in charge. Then he delegated to Gavin and Gavin was in charge, right?

And then Gavin delegated to Vladimir and Vladimir was in charge. and that's completely normal for any technical project. You have one leader who listens to input from people makes a decision. Vladimir, unfortunately, he prefers to not make decisions, I would say. I don't think he would disagree with his characterization. When there's a sort of dispute, he tends to stand back and try and hope that it sort of resolves itself into a nice consensus where everyone agrees. and when that doesn't happen, you know, he just sort of ignores what's happening. So Bitcoin Core sort of devolved over the last few years into this rule by consensus

is what they call it. But it's actually much closer to anyone who wants having a veto, right? Because as long as there's anyone who's sort of objecting and making vaguely intellectual-sounding objections, then there's no consensus and therefore the change won't happen. So this has become a huge problem, especially because some of the people who, who value this and have commit access and love to make these sorts of arguments, they like theory.

They enjoy coming up with complicated theories and complicated proposals for redesigns of Bitcoin and other things like that. And then what tends to happen is the more practical day-to-day needs of developers get lost. They'll say like, oh, I really need a simple change. And it never happens because, you know, theoreticians, you know, feel like, oh, I would rather have a completely different design that doesn't exist.

Like, no one has ever built, what I mean, when I say it doesn't exist. So there's this huge problem, and this is a thing that triggered the creation of Bitcoin XT last year. It was a similar dispute over a similar, well, not similar feature, but a different feature. And, you know, you can see this was going to come up again. We've known that this was going to come up around block sizes for years, and now it finally has. So I don't know what the fix for this is, but I think Bitcoin Core needs to get back to what it was supposed to be, actually, which is, you know, a traditional project with a leader who makes decisions. But if that doesn't happen, then that's what's going to trigger a fork. That's a very strange, in a way, that's a strange idea, because now if we have, if we assume that Bitcoin Core keeps having this big weight and sort of determining some of these rules, like let's say the block size, and then I, I, I, I,

I find the argument a little bit strange that all these five people can agree, well, let's just give all the power to one person. I mean, that may be fine as long as Gavin is there and he's a rational guy and stuff. But that's, I mean, that really seems to be in conflict with the whole idea of a decentralized system. Where, you know. I mean, the decentralization of Bitcoin doesn't come from like the fact that there's like five guys instead of three or instead of two, right? or even instead of one. Like one to five people, you might as well say,

well, Central Bank has a committee that sets monetary policy, so the dollar is decentralized, right? It doesn't make any sense to view it the system that way. The decentralization of Bitcoin, it comes from the fact that everyone can audit the blockchain, check the rules for themselves. It comes from the fact that, you know, there's a competitive market of implementations,

and ultimately from the fact that people can switch to other implementations and fork the blockchain if they want. I mean, I guess that's where you would have some sort of control and check, right? is because, well, people have the option like it may happen now with XT to switch to another version. So I presume that

does that mean you will retain sort of the control, main control over XT if that becomes the main client or would you pass it on to Gavin or how would that work? Yeah, I've been thinking about this in the last few days. What I suspect

will happen is one of two things. One is that if we go ahead, well, okay, let me say one of three things. One is, this is what I'm hoping, Vladimir realizes this situation is unsustainable. He makes a decision. And if the decision is no block size increase, then the fork will happen.

And if the decision is block size increase, then maybe, you know, we put off these problems for another day, right? We kick the can down the road a bit. We'll have resolved the immediate issue. The second possibility is we do Bitcoin XT and we get the majority for the blockchain fork. And in that case, I think, you know, Bitcoin Core would have the,

two choices. One is to accept the Bitcoin XT patch and adopt the same rule set that XT is using or face irrelevance. And I think in that case, they would come into line, right? They would adopt 20 meg blocks or whatever the rule is. And the third possibilities they don't do that and Bitcoin core just becomes completely irrelevant, right? And if the fork happens and Bitcoin Core has not released a version that comes into line, then no one will run core anymore. Right? They will become effectively an X project with no users. And then at that point, it's not clear what would happen, but I think, you know, we would probably,

we would, you know, people who were working on core would move across, right? People don't want to submit their patches to a dead project effectively or where there's no chance of their code making it to end users. So at that point, whether development momentum would shift to XT or whether, you know, Core would sort of, Corwood sort of, you know, secede the arguments there and go with the bigger blocks is unclear. I think it was, yeah, Andreas Antonopoul has put it on the LTV episodes. It doesn't matter what decision we make is as long as you're on the right side of the consensus.

That's, that's really where your decision lies. So I wanted to come back to what you were saying earlier about other open software projects and the fact that most open software projects have a leader that has a veto. Of course, with Bitcoin, as mentioned, as Brian mentioned, that's a little different because, you know, we have that decentralized ideology that's sort of baked in. And it seems sort of contrary to to have one person who can make all these decisions. What do you think is the ideal solution for Bitcoin knowing that it would be difficult to pass the idea that, you know, person would have the veto and everything. How do you think we can make these decisions smoother in the future? Because they will come up.

Yeah, I think the current approach is completely unsustainable and cannot continue, right? It's not just me who's lost patience with this setup. It's a lot of people. Hey, there has to be one leader. And if they make bad decisions, then the results is a fork. That's how all open source projects operate, right? Or virtually all. Of course, but, you know, there's the economic incentive in Bitcoin is much higher, I would I would say than other projects. Do you see some sort of maybe way down the line where one would have a type of voting

where people maybe would vote or if they have votes according to their Bitcoin holdings or something like that? No. I don't foresee any situation except one guy makes a decision and if people don't like his version of software, they switch to another side. I mean, the notion,

that, you know, like, oh, I bought, the notion you can effectively buy votes over technical matters is never going to fly, because again, what you see in, like, a lot of these arguments is a lot of these, you said it yourself earlier, a lot of these arguments don't actually make a whole lot of sense when you dig in, right? There's a lot of obfuscation going on, a lot of arguments that sort of superficially sound good, and then when you stop to think about things like, how quickly could this code be written, who's going to write it, how much complexity will this add, what will the user interface, look like. When you stop to think about these questions, you realize, like, a lot of these proposals

are not very well thought out. And what happens if you get, like, one guy? You know, what happens if, like, Richard Branson or the Winklevos twins or whoever have bought huge amounts of Bitcoin and they read, like, one mailing list post, and then they say, we're definitely voting for this change, right? And then other people are saying, well, we're the ones who have to do the work.

Right? You can't tell volunteers what to do for a voting mechanism. That idea is D.O.A. So the way forward is basically, to have the same system as when Bitcoin was first created, right, when Satoshi just made the changes that he felt were correct to the code. And then, yeah, if people didn't like them, they could

switch to a different version. I don't think Bitcoin needs anything more than that, especially because actually, think about it, the core functionality of Bitcoin core or Bitcoin XT or whatever is not that complicated. It's basically ordering transactions and updating a database and

running these little scripts. There shouldn't actually be very bitter disputes about what goes in very often, right? That really shouldn't happen very much. So the fact that, you know, you need these, you know, the idea that people have to switch to different version of the software to resolve disputes is really, should be a very rare event. Yeah, absolutely.

Well, I think that's, we're going to have some very interesting time ahead of us. I think that's going to be very eventful. and could be quite destructive time for Bitcoin. And let's hope that the reasonable and best way will go ahead. And I mean, personally, I do feel that block size increases is a reasonable way. And I hope that will be possible to accomplish in a way that doesn't deepen even more all those resentments that obviously exist. Yeah, I think this is.

If you dig into the core of this debate, it's a clash of vision, right? Between people who want to follow Satoshi's original plan and people who've decided they don't like that plan, and they want something radically different, and they want to force people to go along with them, right? So, yeah, that's unfortunate, and we'll see how it plays out. But I'm hoping, with minimum disruption is what I'm hoping for. So before we wrap up, do you want to give us, last time you were here in this podcast, We talked quite a lot about Lighthouse and Lighthouse has launched now and it was I used it. I think I was like I used the first, what was the first thing again?

There was a charity. Charity fundraise. Some charity. Yeah. Yeah. And can you give a bit of an update? Yeah. About how that project was going.

Yeah. So actually I should have some interesting stuff to announce around Lighthouse in the next few days or possibly next week. I'm really looking forward to announcing some of this stuff. the app itself is still in beta. So the progress on the code has been somewhat slow in the last few weeks, partly because it's a block size thing, partly because I was on vacation and so on.

I've been doing other things. But I'm looking forward to once the whole Bitcoin XT, Bitcoin core thing, is resolved in whichever way it's resolved. I want to get back to Lighthouse. And my near-term plan for Lighthouse is to take it out of beta, which means fixing bugs, raising the quality of the product, adding a few more features.

that should really be there. Right now, it's still very much a beta quality product, I feel. And I would like to see it reach that next level of quality, just so I can be totally happy with it. I also, so after that, you know, the question is, where do we take Lighthouse after it's reached 1.0 and it's a solid crowdfunding product. I'm looking at the possibility of actually evolving it into a more general sort of smart contracts wallet. The name Lighthouse is deliberately general. So we might see features crop up in Lighthouse that are not to do with crowdfunding, but where, you know, the concept of a wallet has sort of general feature set and can do more things than just sending money around. That's sort of what Lighthouse is probably going to be all about.

Cool. That sounds very exciting. So I'm curious, what are you spending your time on most these days? Other than trying to sell these disputes? Yeah. Unfortunately, in the last few weeks, it's most I had to spend a lot of time reading things, writing articles, doing a bunch of other things. I've, I spend my time on a mix of Bitcoin J, which is still, you know, by far the largest project that I manage. And it's very widely used at this point. You know, we get people asking questions and announcing projects with it every day, basically, at this point. So that takes up a fair bit of time. Lighthouse and, yeah, sort of more general, like doing tutorials, teaching,

speaking at conferences and, yeah, advocacy. Cool. Cool. Fantastic. So, yeah, I look forward to that. Also, if people want to check out Lighthouse, we'll have a rather link in the show note. It's actually, it's really quite cool

because I think it sort of makes a very concrete, somewhat of promise that Bitcoin has, especially the idea that you crowdfunding without the central party, I think is really awesome thing. So yeah, Mike, thanks so much for coming on. I think it's a super important topic, and I'm really glad we could dive into that and talk about it

because, yeah, it's absolutely crucial and absolutely crucial for the future of Bitcoin. I think it's crucial that people are aware of what's going on and understand the arguments. Yeah. Cool. Thanks for having me. It's been good chatting to you guys. Yeah.

And yeah, to the listeners, thanks so much for joining. So we release new episodes of Episand of Bitcoin every Monday. you can subscribe to show in iTunes, SoundCloud, or your favorite podcast app on iOS or Android. And you can also watch it on YouTube. We are at epicenter, YouTube.com slash Epicenter BTC. And, of course, you can always send us a tip which will be in the show description.

So thanks so much, and until next time.