Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Gavin Andresen: On the Blocksize and Bitcoin’s Governance

Episode Date: August 31, 2015

As the debate about the blocksize continues to roar through the Bitcoin community, Gavin Andresen joins us to take a step back and ask the big questions: How should these decisions be made in the first place? What does the governance of Bitcoin look like now and what do we want it to look like in the future? In a challenging time for Bitcoin, it’s a critical discussion to have with the Chief Scientist of the Bitcoin Foundation and successor of Satoshi. We cover everything from the current blocksize debate to the nature of forks to how decisions will be made in Bitcoin XT. Topics covered in this episode: MIT Digital Currency Initiative The way Gavin thinks about Bitcoin How were decisions made throughout Bitcoin’s history What the Nakamoto/market consensus is Forking the software vs a fork of the blockchain Who should make decisions in Bitcoin and how the interest of different stakeholders should be reconciled Why the desirable state is to move towards many different implementations How decisions will be made for the Bitcoin XT code base Episode links: Eli Durado: How should Bitcoin be governed? Arvind Narayanan: Bitcoin faces a crossroads, needs an effective decision-making process Matt Asay: Why you should fork your next open-source project Robles & Gonzalez-Barahona, A comprehensive study of software forks Chinese Mining Pools Call for Consensus; Refuse Switch to Bitcoin XT Bitcoin and Cryptocurrency Technologies - Chapter 7: Community, Politics, and Regulation BIP 100 Proposal This episode is hosted by Brian Fabian Crain and Sébastien Couture. Show notes and listening options: epicenter.tv/094

This episode of Epicenter Bitcoin is brought you by Ledger, makers of the Ledger Nano Hardware Wallet, half piece of mind and knowing your private keys are protected by industry standard, physical security. Go to ledgerWallet.com to learn more, and use the offer code EB-09 to check out 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 Voltor.com to deposit some Bitcoin and start trading today.

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 Sebastin Krujou. And my name is Brian Kroen. So we're here today with someone who also needs no introduction, like some of our other guests, Gavin and Driesen. So it's the first time we have him on the show, but of course, super exciting. So Gavin, for those who don't know, don't remember, he was the guy who, who was involved very, very early on in Bitcoin, and he sort of took over from Satoshi, the lead development role,

and he had that for a long time. And then he passed that on, and well, he was also the chief scientist of the Bitcoin Foundation, and he passed on the lead developer role, and now he's at the Digital Currency Initiative at the MIT Media Lab. So, Gavin, thanks so much for coming on. Oh, thanks for having me. excited to be here. Yeah, absolutely. So I remember I met you once very briefly at the Bitcoin Foundation

conference and I asked you, how much does it cost in mind if you include a transaction because it increases the propagation risk? And you said 11 cents. That's probably that I'd have to redo the calculations. It's actually probably a lot lower today. Yeah. Technology has changed, but yeah. Yeah. Short interaction, but it was interesting because that, yeah. So tell us a bit, like you're now at the MIT Digital Currency Initiative.

What is that exactly? Well, you really should do an interview with Brian Ford to get like the complete vision for the digital currency initiative. But basically MIT is interested in digital currency and what does it mean and is interested in having students and professors, do research, learn about it. And so they're trying to figure out kind of how to make that happen. And I have no experience with these kind of academic interacting with industry kinds of initiatives. But the MIT Media Lab has a ton of experience with that.

You know, they do it all the time. And so the Media Lab is sponsoring the Digital Currency Initiative. And when the Bitcoin Foundation kind of fell down last year, they volunteered to kind of pick up me, Vladimir, and Corey, continue paying our salaries to work on the core technology. And we're still kind of working out, you know, how much interaction will, you know, we actually have with the Digital Currency Initiative. I mean, the digital currency initiative itself is still bootstrapping and growing and kind of getting its feet. So, I don't know, we'll see what happens over the next year or so.

But so far it's been great. It's been a great place to be. So do you actually work from MIT? And are you also going to teach courses or seminars, workshops, things like that? I don't work at MIT. I'm actually two hours away from MIT in Western Massachusetts. And we'll see. I mean, it all depends on kind of, you know, what the professors are up to.

as to I probably I won't there's no plan for me to teach a course I'm I'm busy writing code that's not really you know what I do I don't you know I'm not a teacher I'm not a professor but certainly going in for seminars maybe doing guest lecture certainly something that I think will probably happen over the next year or so and can we get an idea of how much money the digital currency initiative is putting into Bitcoin development? Well, they're paying three salaries. I don't, you know, again, talk to Brian Ford about, you know, details of the digital currency initiative.

And I don't know if they want to make kind of, you know, the salaries that they're paying public. But it's a pretty good chunk of money. So, yeah, I think that's all about it. I can say about that. Yeah, no, I think it would be great to have them on, right? Because people have heard about it, but at the same time, it's sort of a bunch of. clear exactly what it is going to do.

And it's definitely great that, you know, university like MIT is supporting that and putting their name and support and infrastructure behind it. Yeah, absolutely. But, I mean, the only thing is that they're not on Reddit and they really need to be on there to take part in the global debate on Bitcoin. I think you do sometimes see, like, Jeremy Rubin on Reddit. Anyway, but, yeah, I mean.

It's certainly a busy time. I know it's a busy time, you know, getting kind of ready for a new semester. So I'm not sure if Brian will be available soon, but you should definitely have him on this show. I'm sure he'd be happy to talk about the Digital Currency Initiative and what the vision is and what's likely to happen going forward. Yeah, we'll do that. So today, the main thing we want to talk about, well, there's sort of one topic, which is, of course, the block size. You know, we've talked about this many times, and it's an important topic. and our listeners will be very familiar with it.

But we don't want to make that the main focus here, but we really want to talk a little bit about the larger, the meta question of how actually our decisions reached in the Bitcoin community, how is the code evolved, what happens when there is disagreements and arguments, so really the issue of governance. And I think it's a very important issue to think, about and it's certainly not going to get easier from here on. So before we dive into that, do you have a definition of governance?

Yeah, I've got some flack on Reddit and Twitter for talking about governance in a very kind of broad way. And when I say governance, I don't mean government. I think we're governed by all sorts of things. You know, we're governed by our government. government, we're governed by the laws of physics, we're governed by social norms. You know, there are all these things that affect our behavior and what we do. And that's what really I mean by governance is, you know, some effect on, you know, what we do, how we behave, or how a technology behaves, you know, how a technology works. That's all, that all fits into

my kind of general idea of governance. And when I think about governance issues, I really think about all of those things. I think about, you know, what's possible with the laws of physics, you know, what's possible with kind of social norms, what's possible with governments, right? I mean, also, you know, I think if you really want to think about governance, you have to think about kind of all those different levels. So, you know, I think a lot of people when they hear governance, they immediately go to, you know, a nation state governing and deciding, you know, what you can and can't do. And that really isn't what I mean when I say governance. Yeah. It's interesting that you define it like that because the thing that sort of came to my mind was like the process by which decisions are reached, right?

That's, but maybe that's a little bit, a more narrow way of looking at it. That is more narrow. And, I mean, that's a useful way of thinking about it. I think processes is always important. And I think if you have good processes, good things, happen. But yeah, I mean, in general, when I say governance, I really am thinking about everything. I don't know if there's a better, you know, we could talk about process, I think. I would probably say process if I'm specifically thinking about, you know, what is the process we use to come to decisions or what is the process we use to make changes to source code or whatever. You know, I don't really, I do make a distinction between that and governance.

And in the recent debate around the block size that we've seen in the last few weeks and months, what have you learned about the process that is in place, whether it's formalized or not? What have you learned about the process about Bitcoin governance as it exists now? I think the problem is different people have different ideas about what the governance process ought to be or even what it is or even what it was. If you go back in history, it was really simple. It was whatever Satoshi decided at the beginning. And that's really where we started. We had one source code. We had one pseudonym person who made all the decisions about, you know, what should

Bitcoin be, how should it evolve, what should it do. You know, that's where we started. You know, as soon as Satoshi kind of stepped back. and threw the project onto my shoulders. One of the first things I did was to try to decentralize that so that if I got hit by a bus, it would be clear that the project would go on. And so that's why at this point there are five people

who have commit access to the GitHub Bitcoin source tree. And there's this kind of consensus process for what changes are made to the code. And even, you know, what, what, you know, what consensus level, low-level changes to the Bitcoin rules should happen. And, and I don't know, I think a lot of the strife and conflict comes with, you know, we're going to, we're starting to grow beyond even, you know, even that to, there are a lot more stakeholders. There are a lot more people involved. There are a lot more projects. And how do we evolve from, you know, it used to be just Satoshi making decisions to it was this small group making decisions to suddenly there's a much larger set of people who are interested in in decisions and how they're made.

So you think that's the challenge right now. So we have these five people that, well, you chose, I guess, right, to have commit access. And of course you could say that, well, they just vote and it's a majority or. four out of five or all of them. I chose the first couple people and then kind of, you know, among us, among like the three of us, we chose a couple more people. And yeah, I think I think that is the challenge going forward is, I don't think any of us, you know, especially those five people,

like want to be the high priest of Bitcoin. That's just not our role. That's not what we want to do. That's not what we want to be. And so we need to find a new way of governing, right? A new way of coming to decisions and having everybody happy about the process and the decisions that are reached. Cool.

Well, we're going to talk a lot more about what that could look like. But before we do that, you know, when we emailed before the show, you mentioned one thing that you wanted to stress and that is sort of confusing and a little bit unclear, right? So there's that term forking, right? And of course, forking is used for open source software when, you know, you take it, you copy the code. And then, you know, you have two instances. You can make changes to one and all. But forking is also used in Bitcoin, right?

When all of a sudden, there's several chains, right, that sort of run in parallel. So how do you think of those two in the terms of governance and of those sort of decisions? Yeah, it's really important for people to, to separate in their head Bitcoin the protocol, you know, Bitcoin the system that we're all using to transact, and the Bitcoin Core open source software project that lives on GitHub and has a bunch of people contributing code to. They really aren't the same thing. You know, I call Bitcoin Core the reference implementation, and I've called it that for years. I mean, that implies that there will be other implementations of the Bitcoin Protocol.

And when we think about governance, I think we have to think about the governance of kind of how will the protocol evolve as separately from, you know, how will Bitcoin Core the reference implementation code? How will that evolve and how will that be governed? Right. I think there are two separate governance processes. And I think it's, I think most people, because we started with this, you know, this one source code defined the protocol and was all anybody was. anybody was ever running, I think in a lot of people's heads, they don't make that separation. But I think it really is important to think about the protocol separately than, you know, this one set of source code that has been, admittedly, the source code everybody's running.

But I've been saying for quite a while that I want to get to a point where, you know, there are multiple robust implementations of the protocol. And I think we will get there. I think it might be a little bit rocky, but that's a really important distinction to make as we talk about governance processes and consensus and all of these things. Do you think that in terms of software design, it was a wise decision now in retrospect to have the protocol sort of embedded in the reference client rather than the protocol be defined somewhere else and have several clients, for instance, like what Ethereum is doing with the release of the Ethereum client, the frontier launch, they have multiple clients. What are your thoughts on that? I think if Bitcoin had like lots of money to start like Ethereum did,

it would have made sense to try to like start with multiple implementations. Having multiple implementations is great because you find places where things are not well defined. And as Bitcoin has developed alternate implementations, like, for example, conformal has an implementation of Bitcoin written in Go, which if I had infinite time, I would spend time playing with. And I'm actually hoping to spend some time working with it and trying it out. And they've found, you know, as they re-implemented things, you know, they kind of refer back to the C++ reference implementation. and they find little edge cases that, like, weren't tested and submitted tests to say, you know, this is the way the system behaves. You know, we ran across this as we're re-implementing it, and, you know, let's, you know, make sure that we're aware of all of these hairy little edge cases.

So it's definitely a great thing to do. Satoshi could not have done that, right? Satoshi didn't have millions of dollars to hire lots of developers to do four different implementations at the same time. Do you think it would be wise today at the point where we are to separate and really have clear protocol documentation? Do you think that would enable more people to come in and start developing clients? I mean, the problem with documentation is that always

lags behind code. So, you know, early in my professional career, I worked on a 3D graphics specification. And I saw, you know, how hard it is to get all of the details right in a specification. And even if you do get the details right in what you write down in a specification, like actually getting implementations to interoperate or, produce the same results given a specification is really hard. So I'm a much bigger fan of like test cases, for example.

And actually, if you look at the work I've done on Bitcoin Core, you know, one of the first things I did was implement the test net. So we have a place to test things out. And alternative implementations have used the test net as a place to test things out. You know, a bunch of early blocks in the test net have all sorts of weird transactions in them. So that if you are writing an alternative implementation, you know, syncing with the test nets, actually a pretty good first pass of have I implemented the Bitcoin protocol correctly. And so that kind of thing, you know, that kind of like actual code you can run to find out if you're

correct or not. I'm a much bigger fan of that kind of approach rather than just writing words on paper that are subject to interpretation. And I know people will, you know, read the same sentence and come across with a completely different idea about, you know, what does that really mean? you know, how should I put that into code? Yeah. And what's also important to notice regarding Ethereum, because we just did the episode with Vitalik,

where we actually asked about that too. And he did say that it was sort of a mistake, that they tried to do so many implementations at the same time. And they sort of abandoned that and felt that resources wasted, kind of. And because right now they didn't launch with several implementation, right? That's interesting. So if anything, he said, it was a mistake to do that.

Or at least to have that many, maybe they would have had two or something instead of four. Yeah, yeah, yeah. I think two or three, yeah, four is a lot. Two is probably enough that you would find, you know, almost all of the little nasty edge cases that will, you know, that you wish weren't in there, right? There are a bunch of things in Bitcoin that are kind of there by accident

that we really wish weren't there. We just got rid of one of them with BIP 66, and that soft work that we just did was to get rid of a nasty little edge case. It was actually a consensus bug, right? It could have, if people had known about it, they could have forked the network. They could have caused machines running 32-bit operating systems to disagree with machines running 64-bit operating systems, which would have been a mess. So, you know, it's a kind of thing that it takes a long time to find. And, you know, it just, it takes time and experience. And, you know, having another implementation does help find those sorts of things. It doesn't guarantee you that you'll find those sorts of things.

But it certainly helps. So just to point out, there are other, there are forks of Bitcoin. So there's another C++ client called Basepoint XT, which we've talked about. And we'll talk a bit more later. I believe there's a JavaScript one as well. I think, yeah, I think BitPay. I don't know if BitPay's implementation is fully validating yet or not. But yeah, certainly we're seeing other people tackling doing other implementations of the protocol in other languages.

And of course, some companies have their own proprietary implementation. Yeah, like there's Toshi. Yeah, certainly there's Toshi at Coinbase, which is a Ruby implementation that they use quite a lot. So yeah, I mean, this is happening, right? We are getting alternative implementations of the protocol. And in my view, that's healthy. That's a good thing. So one other thing I wanted to point out with regards to what Brian mentioned regarding

forking the code or forking the blockchain is that the way I see this, if you fork the blockchain, it implicitly probably means that you forked a client and made some changes to the protocol. However, you can fork a client. and not necessarily fork the blockchain because it can be compatible with the reference implementation. That's right, yes.

So yeah, when we say forking the blockchain, we mean changing the consensus rules of Bitcoin in a way that's not compatible with the way it used to be. And so, you know, that is on the kind of consensus side. And that almost always means you've changed some code And so you've maybe forked the code.

Although we've certainly had problems with forks with Bitcoin Core, where there was no fork in the source code. It's just kind of old versions of Bitcoin disagreed with newer versions. Or like with BIP 66, the same code running on a 32-bit operating system might disagree with it running on the 64-bit operating system. And that could have caused a blockchain fork. It didn't in this case. Peter Ville found the problem and fixed it before it became a problem.

So you can't have blockchain forks without software forks. You certainly have software forks without blockchain forks. You can have a fork of the Bitcoin software that's completely compatible with the reference implementation and all the other implementations. Let's take a short break so I can take you to Paris. I dropped into La Maison du Bitcoin. the house of Bitcoin in the heart of Silicon Sentier, home to many startups, including Ledger, and I spoke with Nicodabaca Ledger's CTO about the level of security in their devices.

Well, Ledger is based on a smart card chip that is exactly the same smart card chip that you have in banking chips and in passports today. So that's something that has been validated for the industry for more than 20 years. Today the favorite second factor is the phone. When using a phone, you are transmitting an encrypted version of your transaction to the phone, to the screen that can be displayed to you and validated to you. So we leverage on two insecure devices, your desktop and your phone to create a secure validation with ledger. We believe that hardware wallet are very primitive today. They are just used to confirm transactions and to display some validation, and that's it.

In the future, as Bitcoin Protocol moves towards smart contracts, to add a lot more use cases, we believe that those devices will evolve into something that I would call consensus devices, which basically will be able to confirm for specific services, specific rules. How easy would it be to hack a ledger? It wouldn't be very easy, to be honest. I think the best would be for you to try physical attacks first, like glitching, like side-channel attack.

If you want to really attack it, you will need to get a bit more equipped with like a focused young beam work station or a scanning electron microscope. So that's going to cost you probably a few millions. And as well, you are going to be able to decad the chip. So that's going to be a bit risky for you at well. But you are free to try, of course, and let us know if you manage to do anything. Ledger is building an infrastructure, which will provide the best level of security for the Bitcoin industry. You two can benefit from this technology and get an affordable secure setup for storing your bitcoins with the Ledger Nano.

So go to LedgerWallet.com and use the offer code EB0,000. to get 10% off your first order. That offer code is valid until September 30th of 2015. We'd like to thank Ledger for the continued support of a Pesenter Bitcoin. Now, you know, you mentioned in the beginning there was Satoshi. He was making the decisions and it was a, you know, it was a small world back then. And of course, there was no payment processes. Their governance, governments were interested in it.

But today it's a very different world, right? So we have miners, they're startups, there's the users. there's the Bitcoin holders, there's the developers, there's merchants, then there's regulators, there are all kinds of different people who care about what Bitcoin does and where it goes. So who of those entities should have a say in how Bitcoin evolves and where it goes? And how should that be, you know, how much weight should each of those entities or groups of entities have? I think everybody should have a say. It's hard to balance, you know, letting everybody speak and not just being drowned out by the noise. So, you know, if you look on

Reddit, anybody can speak there and talk about, you know, whatever issue about Bitcoin they care about. You know, it's hard to, it's hard to, it's hard to kind of listen, find a signal above all the noise. I don't think it's impossible. And I think, you know, I think it is fairly clear kind of what the consensus on Reddit is about the block size issue. But, you know, it's hard to find more than kind of, kind of a, you know, a high level, you know, we think something should be done about this issue.

When it gets down in the details of, you know, exactly what should be done, I think then it gets even harder. You know, who should have the influence? I mean, well, it really comes down to, you know, who has the, you know, what code are people running and, you know, how influential are the people who are the people who are running the code. So, for example, exchanges are incredibly influential at this stage of Bitcoin's life, right? Exchanges are the place where a lot of trading is done. Right now there's a lot of speculation. exchanges are where that speculation happens.

So what the exchanges want to do matters a lot. Miners are also very influential. So kind of what the end more than miners, the mining pools, right, that pool together miners are very influential. So I think they have a big influence and a big voice in what happens. Ordinary users, they're Bitcoin holders. it's harder for them to have a huge influence. You know, I think if you're not a, if you're not a technical developer,

you know, you can have some fantastic idea about, you know, how we could improve Bitcoin. And if it's like a technical idea, you need to convince a developer that it's a great idea. And that's going to be hard because developers are busy, for example. So I think, you know, the people who have the really the biggest voices right now are the developers. the exchanges and kind of the mining pools. Those are kind of the three, I think, biggest players. I like to think that, you know, as a developer, I try to listen to all the stakeholders. I try to listen to, you know, kind of one long-term Bitcoin holders want, what people who are actually

transaction, transactory Bitcoin want, what the companies like BitPay who are supporting merchants want and try to balance all of those things when I think about kind of what should the, you know, What am I personally going to be working on as I write code, as I submit pull requests, as I decide what pull requests I'm going to review? I try to channel, you know, kind of everybody to prioritize what I work on. And I think all the other developers do that too. We probably have different opinions on kind of what's important to work on next. And through what channels do you get all of those?

opinions. I mean, it seems like you'd have to be everywhere to get everyone's opinion. It's hard. You know, for the, kind of for the big exchanges, merchants, you know, I'm on the technical advisory board of a few companies. So I hear there kind of what their concerns are, you know, if they're concerned about transaction malleability or they're concerned about instant zero confirmation transactions if they're concerned about the block size. So I get that from there. I think the best we can do right now for like ordinary people transacting with Bitcoin are channels like Bitcoin Talk and Reddit.

And again, it's really hard to kind of hear above the trolling and the noise. I think at the Amsterdam conference last year, it's part of my state of Bitcoin speech. I said, I want a better way of communicating. I want some way for the best ideas to rise to the top and for a better way of measuring consensus. We'll see going forward what happens. I don't know.

Maybe prediction markets will be a good way of gauging consensus. I know that's an idea that people have. I think that would be fantastic to see kind of wisdom of crowds, condensed in that way where people actually have some value at stake. But I think it's still an open problem as to, you know, how do you get these diverse stakeholders to come together, come to consensus, to communicate? It's not an easy problem. I think, I don't think it's been completely solved kind of anywhere where you have

the distributed way of making decisions. Do you think that discussion about our governance, how decisions are reached, is that important now? Do you think things the way they are right now are broken or do you think they work well enough? I think it's important to have the discussion. I don't think it's going to make or break Bitcoin if the discussion goes nowhere. Because when it comes right down to it, you know, the governance is whatever code people are willing to run. So, you know, it's, it's the, the, the, the, the blocks and transactions that get mined and then the blocks and transactions that get accepted by whatever merchant or person

you're paying, um, or exchange you're, you know, transferring into kind of, you know, it's the code that people are running that defines the consensus. Um, and that will continue to be true, uh, no matter what happens kind of at a higher level of how to, and, and I think, Eli Dorado wrote what I thought was a great blog post on how should Bitcoin be governed. And he talked about this about how, you know, the Nakamoto consensus algorithm, this consensus for coming to, you know, what is the blockchain and what are the valid transactions, doesn't care about other consensus processes, right? We could slap whatever consensus process we want on top.

And it ultimately comes down to, you know, what is a lot of. the code that people are running, that is the consensus at base. And that is what governs kind of what Bitcoin transactions are accepted, which is really, you know, the whole purpose of the Bitcoin network. Yeah, I mean, I thought that was a good article, but there's, there's one thing that I don't really agree with there. And he says that we can arrive to this consensus more easily by improving communication between groups and stakeholders and ensuring that the debate is grounded and realistic assumptions about the world. So the first part about improving communication between groups,

I think that that's quite a challenge because not all the groups, I mean, now we're a relatively small community, all the stakeholders that are pretty active are communicating. But as Bitcoin grows, you're not going to necessarily have all stakeholders on one channel of communication where they can communicate. And a lot of them overlap and are separated by geographic, barriers, right? So I think that's complicated.

And the other part, ensuring that the debate is grounded in realistic assumptions of the world. I mean, we can see now how realistic that is, right? With most of the bitcoins in, for instance, North America thinking that remittances are going to save Africa or the developing world, I think that that just goes to show how these realistic views are not always. very founded. I think that the what's important to perhaps realize is that the stakeholders that we have now are not necessarily the ones for whom this technology can benefit in the future. So if we look at the internet for instance, perhaps very similarly in the beginning we had a small amount of actors involved and then as I mean now everyone's online,

and if there were some fundamental changes made to the internet, it would affect a lot of people. And I sort of see Bitcoin going in the same direction where I'm worried about the future stakeholders, the people for whom the technology is going to be really important in the future that perhaps aren't even born yet. And I don't know if the interests of Coinbase or today's miners or today's startups are necessarily those of those future.

stakeholders. I think that might be right. I mean, I tend to be pretty pragmatic. So I tend not to try to plan, you know, 10 years ahead. I would much rather plan 10 weeks ahead. Just because I think if you try to plan too far ahead, you never get anything done. You just you'll ignore, if you ignore short-term problems because you're trying to solve some long-term problem, never get to the long term, right? You won't get past those short-term problems to actually get to the long term. So, I mean, yeah, I kind of, it's fun to think about future stakeholders, but it's hard for me to imagine that I know who those future stakeholders are going to be. I just don't know how Bitcoin's going to evolve. I don't know if it's going to be, you know, if it's going to take over Africa. And instead of having all these, you know, little currencies that are, that are,

that hyperinflate every once in a while that, you know, everybody in Africa will be using Bitcoin as kind of the pan-African currency. I don't know. That's a possible future. And, you know, if I knew that that was going to be the future, then they're probably technical decisions we'd make that might be different. I don't know. You know, maybe Bitcoin will become the, you know, the replacement for. some financial transaction that's inefficient right now that I don't know about because I know almost nothing about, you know, stock and bond and derivative trading transactions.

But I know that there are people experimenting with that on the Bitcoin blockchain. If I thought that that was going to be big, that was going to be the win. You know, maybe it would make technical decisions differently now to kind of satisfy those future stakeholders. I'm actually not that interested in those future stakeholders. but, you know, who am I to decide, you know, how this technology should evolve? So, I don't know, I have trouble, you know, I have, I want to find solutions that, you know, no matter how Bitcoin evolves in the future.

Well, first, I want to make sure we get there. And second, I want to, I want the technology to be like the Internet, to be as kind of general as possible so that it satisfies as many stakeholders, potential future stakeholders as possible. Absolutely. And I agree with that. And I think that that is fundamentally what needs the sort of the fundamental core principle is that moving forward whatever governance or whatever decisions get made, that that is always what's sort of a front of mind is making it possible for anyone to innovate, permissionless innovation, transactions at low cost, et cetera. That's just my opinion.

No, I agree. I mean, that's the part of Bitcoin that I find really interesting, is that for really the first time online, we do have permissionless innovation when it comes to money and transacting. And we didn't have that before. You had to go through a gatekeeper. And I think fantastic things are going to happen. just exactly because of that. Today's magic word is fork, F-O-R-K.

Head over to let's talkbidcoin.com to sign in, enter the magic word, and claim your part of the listener reward. I would like to come back to what you said regarding, you know, the governance of the code and the blockchain is sort of two separate issues because I don't know if I agree with you on that one. Because it seems like, you know, most people, they just default to running whatever code comes from that reference implementation. So I think that that sort of, I mean, yes, it is true.

In the extreme case, people could switch the code and stuff like that. But I do think there is sort of an enormous weight that the reference implementation has. I mean, I think, well, I look at the history of the internet, right? I was around back when NCSA Mosaic was the web browser that you used if you wanted to, you know, browse the internet. Right? This was the original web browser written by Mark Andreessen when he was at the National Center for Supercomputing Applications. And then he founded Netscape and everybody was using Netscape as the browser that everybody was using until Microsoft invented Internet Explorer, which actually was fork of the Mosaic web browser initially, if I recall correctly.

And then suddenly you had an explosion of web browsers. And way back when it was NCSA Mosaic, that was incredibly influential on web standards. But then web standards, once there was more than one browser, we went through a really nasty kind of transition period where you had to write your website, one version for Netscape and one version for Internet Explorer and that sucked and everybody knew it sucked. I was a web developer during that period. Oh, it was terrible, wasn't it? Oh, man, that was bad.

I was learning to code web development of that period and then the 2000s just killed me. Yeah. No, it was bad. You know, I was doing some web development back then too. Down with IE5, you know, it's terrible. And then, you know, kind of people got together and now we're in a better place where I think there is a better model for kind of evolving HTML as you go forward. It's still not perfect. It's still messy. It's still, you know, the browser manufacturers still try to be proprietary and still try

to, you know, get market share by playing in the standard space. And I think Bitcoin will be going through a similar evolution, right? I think we will evolve past just there being one reference implementation that everybody uses. I think it's natural for things to specialize. So, you know, the code that Satoshi wrote was a miner. It was a wallet. It was a full node. It, you know, it did everything in one package. And I think he had to do it that way because you wouldn't want to download six different pieces of code to be an early adopter because you did need a wallet. And you probably did want to mine. And you probably, you know, you definitely wanted to be part of the network. But as Bitcoin gets bigger, kind of we're seeing the pieces specialize.

So you're seeing the Bitcoin reference implementation is not the wallet that most people use anymore. Most people are using a lightweight wallet on their phone. I have three or four lightweight wallets on my phone. I have hardware devices that are Bitcoin wallets. And that kind of specialization is good and it's natural. and we're going to see that at kind of all layers of the Bitcoin stack. So, you know, I think we will see an implementation of the code that's targeted just at miners, or mining pool operators, that, you know, has super fast validation,

make sure that blocks propagate insanely quickly. And then they just kind of focus on kind of what do miners and mining pool operators need in terms of software. And I don't think that'll be the reference implementation. I don't think the, I think the reference limitation will continue to be kind of trying to do everything for everybody. And so I think we will see this natural evolution of, you know, it won't just be the one piece of code. There will be, you know, lots of different pieces of code implementing the Bitcoin protocol. It's time for our work from our sponsors, volatoro.com, the goal to Bitcoin Exchange. Now, we all know there's been no shortage of Bitcoin exchange scams and hacks in these research.

recent years. And that's why when Philip and Josh, the two brothers behind Voltro, decided to start that exchange in the wake of the Mount Gawks disaster, they wanted to do things differently. So they're really pushing the bar forward and innovating in terms of security, transparency, and auditability to ensure that customer funds are safe, secure, auditable. And so there's no, there's no this Mount Gox, you know, stuff going on. It's all on the up and up. So if you've been listening to the podcast, of course, you know Voltaur and perhaps you like Voltour and you like what they do. Well, something new is happening, something really exciting is happening.

And that's, Voltaur is doing an equity crowdfunding campaign through Bank to the future of Simon Dixon, of course, you know as well by this point. So if you're interested, you now have the chance of actually owning some equity in a startup, which is sort of a new thing, equity crowdfunding, and not just a startup, but a great Bitcoin startup. a great startup in the space and you can even invest with bitcoin so if you're interested check it out that's on bank to the future so bnk to the future.com and of course we'll put a link in the show notes and we would like to thank vultura for their support of ebb sent of bitcoin and hope they're

going to have a fantastic crowdfunding campaign so some people have called for to have like a more formalized governance model where you know it's sort of there's a little bit more sort of structure to that. But it sounds like from sort of the way you talk about it, it really doesn't make any sense to talk about that on a network level, right? Because on the network, it's just whatever client people choose and whatever that client's rules are, the majority, you know, that that's just sort of de facto standard for the network. It is. I mean, you know, you always want to encourage interoperability, right? You want all of these pieces of software to be able to talk to each other. So whenever you have issues that are, you know, that need these multiple implementations to

cooperate, I think there is a role for some sort of governance process there, some sort of way of, you know, everybody's writing these implementations to come together and say, yeah, we want to do this new thing on the peer-to-peer network. What should the message be called? How should it behave? And you know, right now we have this BIP process, Bitcoin Improvement Proposal Process. The last year, actually, the Bitcoin Foundation was putting money into kind of talking to stakeholders and trying to figure out, do we need a more formal BIP process? Does the current BIP process work for everybody to kind of define new, new protocol messages, new, you know, consensus rules, you know, whatever.

And unfortunately, again, kind of the Bitcoin Foundation had a horrible year last year. That work stopped because the foundation basically ran out of money to fund it anymore. But, you know, I do think that there, you know, that's something that we should be thinking about. And we should be looking at role models like the way the Internet is governed for, you know, how do we come to consensus on Internet protocols, right? If you want to improve SMTP, right, the mail protocols, a call we all use to send email to maybe support security. How did that happen? How did the people who are interested in that all come together to decide that it should happen? And actually, that

hasn't, maybe that's an anti-example because email security is terrible. And that didn't happen. But, you know, I think that's the kind of thing that we should be thinking about. And that is a place where I think more formalism may be a good idea. Maybe, maybe not. I don't know. I think that's debatable. So if we look at existing institutions, which formalize standards on the internet,

we have the ICANN, for instance. We have the W3C. There's another one you mentioned earlier. I can't remember. Which one should we be looking at for potential guidance or to model and which one should we be really trying to not emulate. I like the Internet Engineering Task Force, IETF.

They have a pretty distributed model where kind of people get together in working groups and anybody can join a working group. It's whoever shows up. And then working groups produce standards documents that in the IATF's case are called RFCs, requests for comments. And then RFCs either become standards or they don't, right? I mean, it depends on kind of what code people run, which I also like. You know, there are a bunch of IETF

standards that nobody pays attention to because they turned out to be bad ideas. There are a whole bunch of IETF standards that people do pay very close attention to, you know, including the standards for email, the standards for, you know, I don't know, all sorts of networking standards that we're all using every day that, you know, we don't think about. We just use them because they just work. And so I like the IETF model as a way of going forward. And there's been talk of, of, you know, perhaps the Bitcoin BIP process, maybe parts of Bitcoin should become an IETF working group. And, you know, that's one possibility for, you know, how standards in the Bitcoin space evolve is that, you know, we, we create.

create IETF RFCs that are related to Bitcoin. And maybe that's a future path forward. Again, there's been debate about whether that's a good idea or not. And whether Bitcoin's ready to do that or not. Yeah, I think it's an interesting idea. If you think of this BIP process or something like IETF, if that's like sort of separate from the reference implementation, right? So if it's just working group coming together, thinking like, oh, what's the best way of going about something?

And then they maybe can do pull requests to all the implementations and use, or they just integrated independently if they feel like this is something sensible. And we're actually already seeing that with the BIP process. There are a bunch of BIPs that related to wallets that the reference implementation wallet doesn't implement. So, you know, we have HD wallets, Heracle, the deterministic wallets, that are a BIP that the reference implementation wallet doesn't follow right now, which is a, it's a bug in the reference supplementation. It really should.

But the BIP is useful, and a bunch of wallets are following that BIP, and they do interoperate because of it. So that's a good example of where I think the BIP process is working pretty well. I mean, you know, none of this is going to be perfect. None of this is a panacea. Just because you write a spec doesn't mean everybody's going to agree and follow that spec. But, you know, I think it's better than just, you know, having no communication, letting people go off in 100 different directions.

Yeah, no, I agree. One thing that has been brought up, and of course we know that from other open source project, is this benevolent dictator for life, right? So some projects have that like Linux or Python, and I'm sure some others do that too. What do you think of that? Do you think that's a good model for Bitcoin or maybe for some of the implementations for Bitcoin? So, yeah. So I think it makes sense for a particular code base, a particular set of code to have a clear kind of structure for.

how are decisions made? You know, who ultimately makes the decision? Or is there some voting process that makes decisions or whatever? And I think, you know, Bitcoin Core, the reference implementation, has had kind of this fuzzy process. You know, when I was the lead maintainer of Bitcoin Core, basically the process was, you know, anything that there was broad consensus would go in. If there was something that we just seemed like we couldn't come to consensus, I'd make the decision. I would just arbitrarily decide we're going to go this way instead of that way. And I think that that worked. I was acting as benevolent dictator for Bitcoin Core. When I stepped down from Bitcoin Core and Vladimir became lead maintainer,

he's not willing to have that kind of benevolent dictator role. So he will not, he's more conservative. He will not merge things that don't have consensus. Which, I don't know, watching that dynamic, it really means that, you know, changes can be vetoed, right? It just takes a loud developer to say, I don't like that change. I'm going to veto it, basically. And I don't think that's actually healthy. I think for a software project, it does help for a software project to have a clear way of making decisions. and coming decisions. And I think Core recently has been having problems with, you know,

how does it come to decisions? What should the governance model for Core be? And, you know, that's one of the reasons why I think we're going to see more forks of Bitcoin Core is, is just, I think people need more kind of, it's better if there's a clear process as opposed to, you know, some fuzzy, you know, if it's not controversial, then it's okay. I think, you know, if we want to, if we want to remain innovative, I think it's important that there would be room to take risks and that somebody who's contributing, you know, can at least have some idea that, you know, their contribution will, will come to a decision at some point. It just won't be in limbo forever, which I think is, you know, one of the big problems with contributing changes to the core.

Is it's just, it's hard to, you know, there are certain changes. that it's unclear whether there's consensus or not. And so they just kind of hang around for months and months and months, which if you're a developer is really frustrating. Yeah, I know. I mean, I think one sees that. So I was giving a talk two months ago, something about block size thing.

So before that, I read through the whole Bitcoin Dev mailing list for like on the topic basically since it started. I mean, I'm not up to date anymore on like what the discussion is. They seemed like it was just sort of, yeah, there's no process of reaching a decision, right? So it's just back and forth and anybody shouts in and people get angry with each other. And it's just, it obviously isn't really working that process.

And then somebody says, no, the block size really should be lower and just kind of shake your head. But yeah, and, you know, having been in the position of lead maintainer and knowing that kind of this whole, multi-billion dollar industry kind of sorter rests on your shoulder because you're in charge of the code that everybody is running. That's a horrible place to be, right? I was just going to say that.

Yeah, I mean, there must be enormous pressure to make the right decision. It's insane pressure to make the right decision, which is part of the reason why I think we need to evolve beyond that so that no one person or group of people feels like the whole weight of this system rests on their decisions. So there is more room to make decisions, to innovate, and to even make mistakes. And just the impact of those mistakes will be smaller if you have a more diverse system where maybe not everybody is running the same version of the code on the network. There are lots of different versions of the code.

If anyone breaks, it's not that big a deal because the whole system doesn't break. It's just more diversity really does bring robustness in this case. And Bitcoin is sort of unique. in the fact that, I mean, if you look at Linux, for example, okay, there's Linux, there's a Linux kernel, and then there are multiple distributions of Linux. Those all use the Linux kernel, but essentially, you know, you can make your own distribution

and it can be significantly different from the, I guess, reference implementation, which you would probably call the Linux kernel. I'm not like super well versed on OS design, but I don't think that the, what is this name, Linus Torval? Alton. Linus is actually I pronounce it.

I'm told. I don't think he feels this pressure to make everyone happy and that there's a whole industry counting on him. I mean, maybe he does, but certainly the economic repercussions of his decisions are probably not as important as they are with Bitcoin. Yeah, well, they're certainly more indirect. And I think he has more kind of checks and balances just because it's a more mature infrastructure between him and, you know, people losing money, right?

So if there was some kernel bug that, you know, allowed a hacker to get in, right? That would be really bad. Right. And that has happened to Linux. I don't know if it was Linus's fault or not. I mean, probably, you know, there is someone. bug that caused a bunch of people to lose money because their servers got hacked. It's a little more indirect than some bug in the reference implementation of wallet that

lets your funds get stolen. It just, I don't know, it feels one step removed if you're working on kind of like operating system level software as opposed to financial software, which is really what we're doing. Yeah. So we mentioned earlier that, and we've talked about this with Mike Hearn that there was a potential fork to Mike's client, which is Bitcoin XT. Can you talk to us about what the status of that is and more importantly, why that decision is, why you're considering that fork? Sure. So, yeah, Mike has had a fork of the

Bitcoin reference implementation called Bitcoin XT for a while now, where he added some features on top that he wanted in there, that he needed in there, that were controversial for whatever reason, and weren't added to Bitcoin core. He, like me, believes that we need to scale up, and the easiest way to scale up is increasing the maximum block size. So the latest release of Bitcoin XT will support bigger blocks, and specifically it supports my proposal, BIP 101, which increases to an 8 megabyte block size immediately and then scales up over time so that that maximum block size grows with technology. We've been working on that the last several weeks, both Mike and I.

Bineries should be available very soon. So you'll actually be able to download it and run it. It will behave just like Bitcoin Core. So if you're running Bitcoin Core, you can drop in Bitcoin XT and you won't notice any difference. It will behave exactly the same as Bitcoin XT because it's essentially the same code base just with a few changes on top, including this support for larger blocks. The rollout of Bitcoin XT, I think, you know, we talk about stakeholders and we talk about who's important in the ecosystem. So, you know, the way BIP 101 works is it requires a super majority of miners to support it before it actually happens, before we allow larger blocks and before there would be any blockchain fork. Even before we get to there, it's really important to get big merchants and exchanges on board so that they're ready for big blocks.

And that's actually my next task is to circle back around and talk to BitPlay and Coinbase and BitFinex. And, you know, all of these other kind of big players in the space to say, you know, are you willing to support BIP 101? If not, why not? You know, is there anything you can do to help make the transition easier? And really to get those players on board first and have them come to consensus that, yeah, this is what we want to do. This is the code that we want to support. until that happens, I'm not going to be trying to convince the miners to support BIP 101 or to produce bigger blocks because it doesn't make sense for them to produce big blocks

if the transaction in those blocks are just going to be rejected by Coinbase, by exchanges, by BitPay, by whoever. So it's really a process of making sure that we have what some people call the economic majority, kind of the big players who are making lots of transactions, make sure that, you know, there's a general kind of rough consensus that, yeah, okay, Gavin, we'll go along with, we'll go along with BIP 101. Seems to be the most reasonable compromise. And then, you know, assuming that we get buy-in from them, go forward and get buy-in from the miners. But, you know, the first step was actually getting code that we can test, that we can make sure that it, you know, behaves the way we

expect it to behave. And then we can ask people to start running, because the way people will express their support is by actually running the code. So how exactly where that works? So you will go to BidPay and Coinbase, et cetera, and then they will start, I don't know, if they switch to XT or if they just add that code

to support bigger blocks to their existing, you know, maybe Coinbase's own implementation BitPayzone implementation and stuff. And how will you know, for example, when the support is enough? Is there some way that, for example, they signal that? Yeah, we're going to be asking big companies if we can put their logos on, there will be a Bitcoin XT website. And we're going to be asking them if they, you know,

we're willing to put their logo as, you know, we support bigger blocks. And again, you know, we'll have to talk to them about do they want to support XT? Do they just want to support BIP 101? Or they just want to support the idea of we need to scale up. I don't really care what it is, but just bigger blocks. So I don't know. Maybe there'll be multiple categories of support. But again, until I start talking to these companies and people and finding out kind of what they want to do, you know, I won't know how that plays out.

We'll see. It'll probably be somewhat chaotic and messy. And there won't be a great way of knowing whether we really do have, you know, buy-in. And I'm sure there will be some companies that are like, no, you know, we think one megabyte blocks are great forever. Maybe. At least, I know of at least one small company that will say that. So I somehow missed this BIP proposal. I mean, I knew that you were proposing eight megabytes, but I hadn't read through this BIP. Can you explain how exactly the function, this max block size function, will work and how block size will increase over time? Oh, for BIP 101? Yeah, I can because I know exactly how it works. I wrote the code.

Of course. So BIP 101 proposes that after a super majority of miners have said that they will support big blocks, and that supermajority is set at 75%. So they express support by putting a different version number in the blocks that they produce. And so we can look at the blockchain and see that 750 out of the last 1,000 blocks said that they would support BIP 101. And so once that happens, that sets a trigger in the code. The code then waits two weeks to give everybody a chance to upgrade.

So if there are those 25% of miners who weren't, supporting it, they have two weeks notice that says, you know, this change is going to happen, guys, you better get on board. Otherwise, you're going to be forked off the blockchain. Once the super majority plus the two-week grace period happens, then the new rule for the maximum block size kicks in. And the old rule was a block could be up to one megabyte big. The new rule is that a block can be eight megabytes or larger. and where the larger is measured by how far away are we from January, I think it's January 11th, 2016.

So January 11th, 2016 was picked as an arbitrary start date. And then there's this, the maximum block size is set based on that. It starts at eight megabytes on January 11th, and then it doubles every two years. And so January 11th, 2018, assuming that this change rolls out and miners are on board, the maximum block size will be 16 megabytes. and 32 megabytes, two years later, and 64, and so on, all the way up to a really scary sounding

number of 8 gigabytes, which freaks people out because I think people aren't good at imagining what our technology will look like in 20 years. And I'm pretty confident that in 20 years, 8 gigabyte blocks will not be a big deal, just because I've seen the last 20 years of technological progress, and it's amazing. So this voting system, you say that it has to be 75% of miners, but if you had one mining pool that had a large portion of the hashing power and they were mining more blocks, doesn't that put them in advantage? Yes. I mean, yeah, it is hash rate based. So, well, I mean, and that works.

on both sides, right? So a mining pool with 30% of hash power can veto this change, right? They could decide, I like one megabyte blocks. We're not going to change it. I'm just the 30% of blocks that I create aren't going to support this change and the change wouldn't happen. So yes, I mean, you know, your the, the, when it comes down to actual blockchain fork, yes, I mean, it's a hash power vote. The more hash power you have or control. the bigger you influence. And again, you know, that's why the task over the next several months is going to be to, you know, talk to the economic majority, talk to the big exchanges, merchants, talk to users, talk to the developers, and try to get everybody on board with this

change. So I also read, I mean, we don't have to spend a lot of time on this, but I also read Jeff Garzik's proposal, BIP 100, which also has some sort of a mechanism by which the blocks increase, but I believe that the values are voted upon every time it doesn't increase. Is that right? Yeah, Jeff's proposal is that basically the miners get to decide kind of what the next maximum block size should be. And so there's kind of a regular vote. I forget, on the order of months.

Isn't that more cautious than simply saying, eight megabytes and then we doubled that, we doubled that, we doubled that. Maybe. I mean, his, he starts with the status quo, so he has no jump up until the first minor vote. So it's more cautious there. I mean, theoretically, miners could double up to, he has a maximum of 32 megabyte blocks, could double up more quickly. So if miners wanted to, and they all were voting for the maximum increase every time, you know, we could be at 32 megabytes more quickly than BIP 101, which would probably be okay, right? If the miners are comfortable with that and they think the network can support it,

then okay, so be it. So, yeah, I mean, on it, I don't know, depending on how you look at it, it's either less conservative or more conservative. It's probably more conservative. I don't like it as much as BIP 101. I just, I don't really care what the rule is. I, but I really like predictable rules. I really like rules that are, I know exactly what the maximum block size is going to be on,

you know, February 15th, 2020, right? And with BIP 101, we know that, right? It's set down there in the spec. We know exactly what it's going to be in much the same way that, you know, we know what the supply of Bitcoin is going to be on that date too, pretty much, right? I mean, you know, Satoshi's very predictable money supply algorithm for introducing new bitcoins is kind of what inspires me to to propose that we just have this limit be, you know, very predictable so that people can can plan, right? If you know what it's going to be,

it's much easier to plan in advance. You can do some modeling of, you know, what I think the demand for transactions is going to be. You might be able to figure out what the fees are likely to be. You know, all those kinds of things I think are easier to do if you kind of fix this rule as opposed to kind of letting it be minor consensus over time? One question on that. You know, as we all know, the block reward halves every four years. And that to me seems to be not such a great design choice, right? Because it presents a lot of risk, right?

All of a sudden, you're mining. Well, the revenues drop by half, you know, next year. We'll see if something bad happens there or not, right? But you might have that a lot of miners all of a sudden become. unprofitable shutdown, their mining hardware, hash rate drops, all that sort of thing. I mean, I guess Satoshi, you know, didn't necessarily think of that

or just wanted to have something simpler instead of like, so, I mean, I understand why he made the choices there. But, yeah, like, I think, well, yeah, I don't know, if, if, you know, I could go back in time, I would probably urge Satoshi to make the block reward kind of. Continuously. Continue, yeah, every single block,

take the timestamp and use that to, calculate kind of, you know, what the reward ought to be. So, so don't you think that that would be better for the block size increase as well? They have like a continuous increase because, I mean, I can imagine in the future. It is. It is. I mean, BIP 101 has, the block size changes every single block. So it actually is doing exactly that.

It's taking the timestamp that's part of the block header. Oh, it is continuous. And using that to, yes. So when I say it doubles every two years, it doubles, but it's continuously, right? linear. So it is continuous. It's not a sudden jump. Okay. That makes sense. Okay. So perhaps BIP 102 then should be that the block reward also follows that same pattern. Changing the, well, I mean, yeah, no, I don't think we should do that. That would be too much risk for not enough reward, right?

I mean, it's not a big enough problem that the mining reward has. And it's going to be less of a problem over time because the mining reward gets smaller and smaller over time, right? So I think I would, I would be against, you know, that proposal. Yeah, it certainly would create a lot of controversy and I think it would be almost impossible, very, very hard to get through. Reddit would explode. And, you know, I mean, when we're talking about mining reward, they're weird, like, incentives, like if you can get more reward by tweaking the timestamp in your block, maybe you try to tweak the timestamp in your block to get a few extra Satoshi's reward.

You know, there's stuff. So, yeah, and I think we're stuck with the step function every four years for that. So what exactly is the timeline on? So you mentioned that actually the bigger blocks would come in early 2016. Hopefully. Right, if all goes well. So you said you were talking to companies now and then you will try to get people to switch to XT, I guess, sometime this fall or next year? Well, the next, I mean, XT binaries will be available probably this week, assuming that we get,

and we're actually getting Gittian building, you know, reproducibly building the binaries. As we speak, my machine is actually working on that. And so we should have binaries out for XT this week. Anybody who wants to, who thinks that, you know, BIP 101 is a good idea, and they think that's scaling up this way, you know, we'll be free to download and run those binaries. I would encourage people not to mine on it quite yet, you know, wait a little while if you're a mining pool or miner. The TestNet, BIP 101 has a test net switchover happening earlier. It actually already happened.

So, you know, we could mine big blocks on test net. And, you know, when I'm not talking to companies about this, I will be doing more testing to make sure that, you know, big blocks don't cause any problems on. on VPS machines, on machines with maybe limited bandwidth, all those kinds of things, all that kind of testing will be happening. One thing I forgot to ask before, so let's say everything goes well or poorly in the minds of those against this, but let's say the switch to XT happens.

How will decisions be made in XT? Is that you're going to step back into that lead developer paying, is Mike going to do that? Mike Hearn will be the benevolent dictator for XT. He will be the ultimate decision maker. I've said that I'm happy to help out with maintaining that project, accepting pull requests. I frankly don't really want to be a benevolent dictator

of an open source software project. It just sucks up a ton of time. But yeah, Mike will be the ultimate kind of decision maker there. And part of the philosophy, talking with Mike, Part of the philosophy for the XT project will be that decisions will happen fairly quickly. So there won't be this, you know, hanging about in limbo. Will my pull request be accepted or not? So between Mike and myself, you know, we will commit to making decisions fairly quickly about, you know,

whether a given change is going to be accepted or not. And how confident are you? Because Mike seemed to be under the impression that like a lot of the major stakeholders exchanges and payment process, processors were on board, we're changing to XT. How confident are you that at least this part of the coming to consensus will come true? I think they're all on board with bigger blocks. You know, we'll need to talk to them about XT and the other changes that are in XT. There are a few other patches that Mike maintains on top of XT.

And I think they're fine. You know, one of them I actually wrote myself and submitted decor and then it became controversial and didn't get accepted. But we'll see. talk to them. I mean, you know, if you're a big enough infrastructure company, then probably you're compiling the code yourself and you might even have some patches that you apply yourself on top of Bitcoin Core's code to, I don't know, do whatever you need doing. And certainly, you know, the code for BIP 101 is available and, you know, I will be maintaining patches against all the major Bitcoin Core releases. So it'll be easier to,

for people to pull just that change, if they only wanna run just that change. And we'll see, I don't know, I need to talk to folks and see what they're thinking. Cool. I know a lot of people just, they just want there to be consensus. They don't really care what it is. I think that's kind of the default position

for a lot of people in the space. And they really wish the developers could just go into a room and I don't know, arm wrestle until we came to consensus. And I don't know, I don't know how to get a bunch independent-minded developers who have different ideas and priorities to come to consensus. It's a really hard problem. Definitely, yeah. That is one thing that's been apparent.

So, well, Cameron, thanks so much for coming on. It was really interesting talking with you. And I think it's a crucial conversation at sort of a very important stage in big-ons development, and I do think it would be a great thing if you can end up with different implementation and more diversity when it comes to, because how did this run? And of course, I do think also larger blocks would be a laudable thing. Oh, good. Yeah, and I don't know.

There's been lots of extreme positions, I think, on all sides of the block size debate. And, I mean, truth be told, you know, Bitcoin will be fine no matter what. I think it will evolve and, you know, it will be good. I just think kind of the path can be smoother if we can get past, you know, kind of the extreme sides and come to a compromise. And it's not going to be perfect. It'll probably make everybody unhappy in some way. But we'll see. I don't know.

Even if we don't, again, as I said, I think Bitcoin will be okay. Cool. Excellent. Well, Gammon, thanks so much for coming on. Thanks for having me. Good talking to you. And so one last thing. So we've started this t-shirt bribing, bribery contest.

So these t-shirts are once a week we do a lottery, sort of. So if you leave an iTunes for you, then you'll be in the draw to get one of those. Some of you have already won it, and we'll send them out soon. And, yeah, of course, your opinion shall remain unbiased, so you can say negative things as well as wonderful things. So, yeah, thanks so much. So, you know, our podcast comes out every Monday, so you can download it, of course, get it through your podcast app or also get a video on YouTube.

That's YouTube.com slash Epicenter BTC. And, well, thanks so much for listening, and we look forward to being back next week.