Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Amaury Séchet: Bitcoin Cash

Episode Date: February 28, 2019

Amaury Séchet is the lead developer of Bitcoin ABC, the largest client for the Bitcoin Cash blockchain. Amaury first got started with Bitcoin in 2010 and closely followed the Bitcoin block size debate as it progressed through the early years of Bitcoin. Predicting the eventual failure of SegWit2x, Amaury was part of the original team that helped coordinate the Bitcoin Cash hard fork, timing it with the activation of SegWit on the main Bitcoin blockchain. We discuss with Amaury the roadmap for Bitcoin Cash, especially with regards to their approach to scalability. We cover many of the novel features the Bitcoin Cash development teams are innovating on such as Canonical Transaction Ordering and Avalanche Pre-Consensus, as well as cover some of the more juicy drama that plagued the Bitcoin Cash community in late 2018, leading to split off of Bitcoin SV. Topics covered in this episode: Block Size Debates in Bitcoin Origins of Bitcoin Cash and the Fork Year 1 Technical Development of Bitcoin Cash Bitcoin ABC vs Bitcoin SV Future Roadmap Episode links: Bitcoin Cash Roadmap Graphene Whitepaper Avalanche Post-Consensus The Case for Canonical Transaction Ordering Bitcoin ABC vs Bitcoin SV Hashwar Bitcoin NG Episode EthCC Meetup Thank you to our sponsors for their support: Deploy enterprise-ready consortium blockchain networks that scale in just a few clicks. More at aka.ms/epicenter. This episode is hosted by Brian Fabian Crain and Sunny Aggarwal. Show notes and listening options: epicenter.tv/276

This is Epicenter, Episode 276 with guest Amory Sese. This episode of Epicenter is brought to you by Microsoft Azure. Do you have an idea for a blockchain app but are worried about the time and cost it will take to develop? The new Azure blockchain dev kit is a free download that brings together the tools you need to get your first app running in less than 30 minutes. Learn more at aka.m.s. slash epicenter. Hi and welcome to Epicenter. My name is from. I'm having train.

And my name is Sunny. I'm going to be starting off quickly with some announcements. Epicenter is going to be holding a meetup next week in Paris, right, coinciding with ETHCC. And myself and Sebastian will both be there. And it will be cool meetup. You can come meet, you know, the hosts, some other past guests that we've had, as well as, you know, other listeners.

And it should be a good time. And also at ETHC, I'll go ahead. I'll be going and giving a workshop on the Cosmos SDK. And so it's a two-hour hands-on workshop. So if you're interested in getting started with developing using that, come check that out. Cool. Yeah, unfortunately, I won't be able to make it this year, but I was here, I think, two years ago, and it was lots of fun. So I am envious of the meetup, and hopefully next time I'll be part of it, too.

It's definitely my favorite Ethereum conference I've been to. So today we're going to speak with Amory Setshe. He's the elite developer of Bitcoin ABC. We can speak about Bitcoin Cash, something we haven't covered before. Now, we felt there was so much to talk about here that we ended up splitting it up into two episodes. So that's just a heads up. So this is going to be part one that we listen to today. We spoke a lot about, you know, kind of his early getting into Bitcoin, the block size debate and the whole

scalability debates that happened years ago, but they were really kind of the genesis to Bitcoin Cash and a lot that came afterwards. He spoke about Segwit 2X. So there's a little bit of a history tour as well, and I think it's, and maybe some newer listeners, they don't remember those times, but they were, you know, there were a lot of heated debates about this topic years ago, and we did countless episodes on this topic. So if you're interested, and it was definitely a very, very interesting time. And that, of course, Bitcoin Cash arose. out of. And then we also spoke a bit about some of the different technical views around scaling, around hard forks, around, you know, transaction ordering. And yeah, it was a,

what was a great conversation. Yep. So with that, let's go to interview with Amory. So we're here with Amory Seseech. Amory is the lead developer of Bitcoin ABC. And he's been working on Bitcoin in cash for a long time. Of course, Bitcoin Cash is something that we've never really talked about on this podcast, even though it's been around for quite some time. And at some point, you know, took up so much mind space in the cryptocurrency world, but still there's a lot of interesting things going on in Bitcoin Cash. We're really looking forward to diving into both the history as well as, you know, the technological differentiation that has come up in Bitcoin Cash. Yeah, thanks so much for joining us.

summary. Yeah, thanks for having me. So I remember we spoke about a year ago for a while. And one of the things I remember that you talk quite a bit about how you got into Bitcoin originally, which was like very early on, do you mind sharing that kind of your early exploration of Bitcoin? Yes. Well, at first I was very interested in like digital currency event before it existed.

was something that was interesting to me and I discovered Bitcoin in late 2010 I think it was November or December and so that was kind of like the first instantiation of that idea that was actually working there was you know produced at them but they all were flowed in some way so I was very interested and started following what's going on and then after say more like in 2012 or so it started growing very big so i was like okay this is not just me that is seeing something there that is interesting but actually it seems that there are a lot of people in the world that start to catching up with that idea so um yeah you know in 2012 around that i was uh you know

this is where i had the realization that it would become very very big and so at the time did you but you're just kind of watching it afar, or did you start maybe working on some little things or exploring different aspects of the code? Or in what way did you engage with Bitcoin back then? So I was more interested by the economic aspect of it to begin with. So I didn't look in the cup right away. I looked in the code more recently when, you know, because in the early days, it seems that there was a team of developer that were, you know, doing just fine.

So it's not like there was much of a need for me to get involved in the code. But so I probably started to look in the code in 2015 maybe or so. I see. And so, you know, instead of jumping in full time, I know when we were discussing, you mentioned you were spending, you spent a lot of time at Facebook along during that time from like, you know, 2010, up until, like, you know, 2015 or so. And so, you know, was like, what was Facebook at all, like, interested in, like, what was going on? Or was this, like, sort of something that was just on your side interest?

And, like, also, how did your time at Facebook, like, help, you know, maybe impact the way you look at blockchain development and whatnot? Okay. So, so the main problem for a company like Facebook is that right now there are many open question when it come to scaling blockchain. And so if a company like Facebook were to say, okay, you know, like Facebook, for instance, has a payment system within their messaging app, right? If they were to say, okay, we enable Bitcoin in Messenger like next week, it would be a giant disaster, right, because there would be so much people using it at some point. And, you know, the network just couldn't handle it.

So some engineer at Facebook were interested by Bitcoin. coin and Evan some engineer I know at the time wrote some code to support it but it was not scalable enough for it to make a lot of sense for Facebook you know to adopt that and so so that was a bit of the situation that was at Facebook though my experience as Facebook I think was useful in many ways because so first I've worked on I worked in the gross department of Facebook. So what is gross at Facebook? It's people building technology to improve Facebook so that more people use it essentially

to simplify it out. And that gave me a lot of insight about how to make a product that people want to use and how to grow that from a technical standpoint, but not only. And, and, yeah, so that was useful to bring that in crypto. I think it gives me a different mindset that most people may have in the space. And so recently there's been lots of, you know, some news that Facebook is starting to have a serious blockchain effort and they're acquiring some teams and supposedly there's like, you know, substantial effort in there. But now that you have some distance, you don't work at Facebook anymore, you can feel, share you. opinion, what do you think, what's your expectation of Facebook will end up doing with blockchain?

I don't have any particular insight because as you mentioned, I'm not working for Facebook anymore. What I would expect from that is maybe something that is very repel-like to settle payments because Facebook has a lot of international payment system in there. And right now, they rely on soft party to settle like PayPal and Venmo and these kind of people. So if they can develop something that is similar to repo, it could help their system quite a bit. And I think this is, I think this is what they are doing. But I don't know any better than anyone else. So that's more of an internal enterprise product than a consumer-facing thing.

I would expect it. Yeah, I would expect it. Because, you know, Facebook doesn't have very much this culture of, you know, let's build an alternative currency to subvert the system or whatever. This is not something that is built in the DNA of a company like Facebook. So I would be very surprised if this is what they were doing. Yeah, absolutely. So then you mentioned 2015, you started getting seriously involved in the Bitcoin space. And I guess that's also sort of when the blockchain or the debacle.

or the debate around the block size was really, you know, heating up. And of course, on this podcast, we did countless episodes on it. So what triggered this involvement back then? And how do you remember the block size debate? Okay. So, yeah, it's very interesting because one of the question, I actually had a small intervention in the community in like 2012 or something like that. So, okay, for people to know, I was there very early on, but for the most time, I was, you know, keeping a very low profile.

And the reason is, I mean, I think most people in the space can understand. This is like a very subversive technology. And so it's not always the best idea to, you know, attach your name to it early on. And I think this is why people like Satoshi, you know, choose to stay anonymous. And I was kind of in the same mindset. But I still had some interaction with the community in 2012 around the block size because that was kind of like my last question. At that time, I saw the technology is there, it's working, it has the potential to be big, but there's this block size stuff. And it was very clear to me at the time that if the block size stuff stay, then eventually we're going to run to the limit.

And so, you know, it's going to prevent the growth of the system. So I went in there, I asked people, but at the time people, almost everybody was like, yeah, no problem. You know, like when we get anywhere close to the actual limit, we're going to raise it and everything. So I was like, okay, so this seems to be moving in the right direction. So I should, you know, I should consider this to be something very serious. And then what happened is that the people that are more on the side where the block size limit should stay small, starting having more and more influence into the community. I think the people that were for raising the block size

made a lot of strategic mistake along the way that allowed those people to gain a lot of influence. And so it resulted in the situation where at some point those people were more influential and more numerous than the one that wanted to increase the blog size. And this is where this whole thing started to turn into war of some kind of. What are some of these strategic mistakes that like some of these big block opponents made?

Would one of them be backing Craig Wright's claim to being Satoshi perhaps? Yeah, but that was fairly late. I think even before that there were various mistakes. So what do you see in most open source projects? So there is another project that participating a lot that is called LLVM. It's a compiler infrastructure project. For people who don't know, it's software that takes source code that is written by developer in a way that human being can understand and turn it into binary data chip can execute.

And this project is, you know, as participants from many big company in, you know, the computer science space. So you have company like Google and Facebook and Amazon and these kind of people, they are going to contribute. they contribute because they have millions of servers literally, right? And if you have one million server, you improve the performance of application by 1%. It's 10,000 server that you don't need anymore that you can use to do something else. So when you have millions of machines, it's really quickly added up to very substantial amount of money.

So they're participating for those reasons. You have people from Intel or AMD or ARM or chip manufacturer. And why? because they want to make sure that the cut generated for their chip is, you know, very high quality. They also want to ensure that maybe the engineers that work for Intel, they care a lot about the performance on the cut generated for Intel, but they don't care that much about the performance on AMD chips, right? So if you let the Intel engineer do all the work and you are IMD,

this is probably a strategic mistake because, you know, your processor are going to end up being worse. for your customer because the software support or indeed for compiler is not as good. And I think the big blocker made that mistake. So the people that were more for small block invested very heavily in infrastructure, right? Like company like Blockstream, for instance, hired a lot of developer of the core software client.

And the OSHA company, not as much. And as a result, you have this effect where if you depend on some infrastructure, but you are not really invested in it, then the people that are actually, like you know, you are at the mercy of the people building it. And so I think that was a bit of a strategic mistake. So right.

And probably the first one and the biggest one. So the small block or narrative has been kind of like, you know, in line with that where they've been saying like, look, all the core developers and main infrastructure people are relatively, you know, very pro small blocks. And then like, you know, a lot of these companies and miners are very like pro big blocks. But you know, you, they,

They actually flip the reasoning. Their claim is that, like, you know, the reason the core developers are overwhelmingly pro-small blocks is because they have like some technical insight that makes them realize that big blocks are infeasible. Do you think that's a fair, like, you know, how valid that claim is of them? I don't think that is the case. I think it's more of a difference of opinion on what's important and where the project should go.

So for people in the Bitcoin cash community, peer-to-peer, electronic cash is like, you know, the most important thing. And you want to have the best property for the system, you know, that fit that bill. People that were more in the small block size, they sell Bitcoin more as a settlement layer. And you would use other systems to transact like L2 and Lightning Network and maybe liquid and, you know, various other stuff like that. And so you transact using those systems. and you use BTC just as a settlement layer for those systems. So there is a very important difference of vision. And so when you don't want to build the same stuff,

then obviously the trade-off that you are making are not going to be the same. And I think this is where the main difference is. But so why do you think there was a lack of big block support amongst core developers? Like why did the big blockers never? really take step up and take like a big role in a lot of this core infrastructure development well i think the people on the big block size they were more um coming from the economic standpoint and i came

to bitcoin from the economic standpoint and maybe that community was a bit weaker on the technical fundamental for quite some time i think i see i see they i think a lot of people in the big block improvement. What he did not realize, how important it was to make sure you have a solid infrastructure, but the people on the small box size, they realize that very much, very early on. Yeah, that's very interesting.

And then one of the things that is noteworthy is that most or a majority of the co-developers were in favor of small blocks, but at the same time, the miners tended to be in favor of bigger blocks. Why is that?

I mean, why do you think there's any economic reasons? Why miners would prefer something like electronic cash approach to, you know, this settlement vision? It always seemed a little bit counterintuitive to me because you'd think that minors would want higher transaction fees. So, thus smaller blocks. Well, no, like the revenue of the minor is the transaction fee times the number of transaction. So for miner to generate high revenue, you essentially have two general direction. They can go into. They can try to increase the volume of transaction or they can try to increase the transaction fee.

And I think that the increase the transaction fee approach actually don't make a lot of sense. The reason is that everything else being equal, you'd rather use the product that have smaller fee. So if there is one product that have very high transaction fee and limited capacity and another one that have a very very large capacity but low transaction fee, then on the long run, you should see most of the volumes, you know, moving to the one that have high capacity and low fees. So I think if you are a minor and you are thinking about this long term, the second, you know, the second one makes more sense, I think. Okay, so early on, there was a lot of these, you know, it's not fair to say that there was no development support behind, you know, big blocks.

Rather, it just was missing from a lot of the, you know, Bitcoin core development team. But, you know, early on, we are, we, we already started to see, you know, many alternative clients start to pop up, things like, you know, Bitcoin Classic, Bitcoin at BU. So could you, you know, tell us a little bit maybe about the history of these alternative dev teams, alternative client implementations? So I was not involved very closely with all of them. So I'm, you know, I cannot go to every detail because, you know, some of it I don't know. But essentially there was three big effort on the big block side.

There was XT, there was Classic, and there was BU. So I have a little internal knowledge about what happened with XT. So I'm not quite sure. I think it got a amount of traction early on. but it was essentially disabled mostly by political move, if I understand the history correctly. So there was this Hong Kong agreement, for instance, where car developers and miners agreed to not run X-C and run car and in exchange car would eventually be a two to bigabyte increase, something like that. And so it's essentially like remove the wind of the sale of XT.

But then later on there was a classic on BU and the two of them, you know, went pretty strong. I think they made a few mistakes. And one of them is like not presenting a unified front. There was a lot of, you know, infighting between the two. And they were not 100% compatible in terms of the consensus room that they implemented. It resulted in a fork in test net. So then, you know, everybody gets cold feet because it's not quite clear which one of the two, you got to support and everything, right?

So I think there was a bit of a strategic mistake. And on the other side, the other camp was also willing to play dirty. So when the other side is willing to play dirty, you really need to have your, you know, your act together. What do you mean with playing dirty? Can you expand on that? Yeah. So I mentioned already they think that they were doing well, like investing in infrastructure

and stuff like that. But there was also agreements like the Hong Kong agreement, for instance, that was more of a political move than anything else because they made some promise there that they had never, you know, they did not really intend to keep. Or maybe they changed their mind later and they intended to keep it at the time. It's not quite sure. But the whole stuff was, you know, very much political, much more than it was for the benefit of the coin or for technical reasons. there was also a fair like you know the core developer that were more on the big block side there were a few like Mike Erl and Gavin and Dresson but they found themselves isolated very quickly and eventually removed from the project there was there was a fair bit of stuff shit going on on Reddit and and Bitcoin talk and a few places like that so yeah no I just wanted to

because you know we are speaking about these things years ago and probably many of our listeners are not, not very up to date with that. So I just wanted to spend like three minutes kind of recapping what happened. Okay. Yeah, sure. So basically, right, you had, you had on the one hand people who wanted to have bigger blocks, right, and we spoke a little bit about that and kind of division around that. And then a lot of the core developers, they wanted to have this other thing called Segwit,

which would give a lot of, you know, extra technical capabilities. And we can speak about that later to exactly what Segwit was. and then you had these different factions and there was a division and lots of drama around it and we did many episodes back then we had Mike Hearn on several times we had Adam Back on and Greg Maxwell and like so with lots of discussions on this

but basically had these differing visions and then there was this sort of agreement to do kind of both right so the core developer says okay we'll do as two megabyte block size increase at least we'll double it and then the other one the miners said, okay, we'll go ahead with Segwit and activate that.

But the 2 megabyte thing came first. No, the Segret thing came first, right? So the Segret thing got activated. Yeah, so that was Segwit 2X, yeah. Yeah. I think there were strategic mistake made with Segwit 2X as well. Like you mentioned, the fact that the two don't activate at the same time was a bit of a mistake. I think there is also probably a bigger mistake.

This was the mistake that led me to believe that Segwit 2x will fail with very high probability at the time. And so that BCH was very important. It was that at some point the activation of Segwit 2X was modified in no way so that it's compatible with the way UASF activates Segwit. So for people who don't know, UASF is essentially a group of people that decided on August 1st, we're going to enable Segwit, no matter what, and we're going to run a modified version of the Bitcoin Core software that does that. And, you know, even if there is no majority support for the miner or whatever, we just are going to activate Segwit and essentially fork the network with the Segwit branch on August 1.

And that made a lot of people very scared because a lot of people at the time were very scared of forks. And so they choose to activate SegWi 2X in a way I was compatible with USF. And I think that was a mistake because clearly the USF people, they were not really there to find a compromise or have any kind of negotiation. They wanted to, you know, it was a movement that was very much, you know, my way or the highway. And if you, if you, so rather, if you don't modify the activation to be, be compatible with them. On August 1, they would fork themselves off the network.

And they would find themselves on a minority chain. And then, you know, like, maybe they want it, maybe they don't want it, maybe they come back or whatever. But essentially, it removes a lot of wind due up their sale. On the other end, if you activate Segwit in the way that is compatible with what they want it, then they stay on the chain. They can claim that Segwit activated because of their effort. And so you give them much more leverage in the negotiation. suddenly. And you do that in between the time where they get what they want and when the other side is supposed to get what they want. So it's pretty much a guarantee that you're

going to have a bait on switch if you do it that way. Like if you empower the people in the negotiation, you give them more leverage that don't want the second part to happen. By the way you do the first part, you're pretty much guaranteed that the second part is not going to happen. So that was what I saw at the time. So, you know, I've seen this, like, debate happened countless, endless times on Twitter already about, like, you know, was that August 1st Segwit activation caused by UASF or by the Segwit 2X agreement? And it's like, you know, it's kind of impossible for anyone to really decide. It's kind of impossible.

Like, the way the way Segwit 2X was made, essentially made it impossible to know. This episode of Epicenter is brought to you by Microsoft and the Azure blockchain workbench. Getting your blockchain from the whiteboard to production can be a big undertaking. And something as simple as connecting your blockchain to IoT devices or existing ERP systems is a project in itself. Well, the folks at Microsoft had you covered. You already know about the Azure Blockchain Workbench and how easy it makes bootstrapping your blockchain network preconfigured with all the cloud services you need for your enterprise app.

Their new development kit is the IFTTTTT for blockchains. Suppose you want to collect data from someone in a remote location via SMS and half that data package in a transaction for your HyperLedger Fabric blockchain. The development kit allows you to build this integration in just a few steps in a simple drag-and-drop interface. Here's another great example. Perhaps you're an institution working with Ethereum and rely on CSV files sent by email. One click in the Devkit and you can parse these files and have the data embedded in transactions. Whatever you're working with, the Dev kit can read, transform, and act on the data. To learn more and to build your first application in less than 30 minutes, visit aka.ms slash epicenter. And be sure to follow them on Twitter

at MSFT blockchain. We'd like to thank Microsoft and Azure for their supportive epicenter. Before we continue talking about Segwit 2X and like, you know, kind of the origins of Bitcoin cash then, one thing I want to just bring it back for one second and is discuss really quickly, you know, we often like see that, you know, there's this like, you know, block size increase versus Segwit and, you know, these are usually the two like main, popular proposals that are well known. But there's like other proposals, right, as well, like, you know, extension blocks, which is like, you know, how you...

I want to go back to you something that you guys said a few times, while it was very much big block versus segwit, and I think it's a bit of a strange representation. It may be what it looks like, no, but it was not like it was then. If you go back in the past, there was this proposal to do Segwit as a, hard fork instead of doing it as a soft fork. And a lot of the people that would be know in the big block camp were actually in support of that. And I was in support of that.

I know people like Gavin and Drison were in support of that. So it's not per said that everything is bad about Segwit. But the way Segwit was made as a soft fork creates another serial case of four megabyte for the, so. When you implement Segwit, essentially you can create a block that is up to 4 megabytes. But effectively in terms of capacity, you get 1.4 to 1.7x the capacity, depending on the assumption you make. We are probably going to see in a few months, you know, what is the real number. But in that ballpark. So let's say less than 2x.

But you get 4x adversarial case, which means your software need to be able to support up to 4x. you know the base base block size and that is not really a problem if you plan to keep the block small right but that's a very big problem if you want to increase the size of the block because suddenly you add an adversarial case that get incredibly big and someone can craft a special block that exploit that adversarial case and bring the network to its needs right like yeah I know like a lot of my issues with like the Segwit soft work proposal mostly just around technical debt where it just seemed to be a very complex change, a touch like the all parts of every piece of the code. Yeah, that's another. That's another thing. The way, so the way it was done as a soft

torque was significantly more complex than the way as a hard fork. Because obviously, you need to retrofit everything into the existing rules, but the existing rules has never been made with the consideration that you would retrofit all of that in them. So it was a bit more complicated but that's the role they choose to go into so yeah to get back to your question there was also proposal like extension block this was actually what I was working on initially and so extension block was essentially a way where you don't do anything special in the base block the base block stay similar to what it always was before Segwit or before big block or anything but you create this

extension block which you can put Segwit like transaction in them. And this exchange shot book would be 8 megabyte as per the proposal. And so you would create a situation where you get most of the benefit of Segwit. And you also don't get the main drawback of Segwit that is the 4 megabyte adversarial case. And you get a bigger capacity as well. And this is a soft fork. So that seems to fit the requirement that, you know, many different parts.

wanted or at least they said they want it. So I started working on that. But then Segwit 2x started becoming big. So it kind of removed the winhood of the sale of the extension block ID. And at the same time, they were doing it in a way that I thought was likely to fail. So I had to change plan. One of the things that was also interesting around the genesis of Bitcoin cash is because the Bitcoin cash started that was before, uh,

You know, this was, so August 1st was this key date, right where UASF, the threat was there's going to be a Bitcoin fork in UASF, and people still thought Segway 2X is going to happen, at least most people thought that. And Bitcoin Cash was actually on beforehand, and people were not really paying attention to it. There was like, what's this weird thing, Bitcoin Cash? And then, you know, when Segret 2X started failing, that's really when Bitcoin Cash picked up. So can you

speak a little bit? Because did you start working on Bitcoin Cash? I mean, you initiated this initial fork as well. Yeah, I wrote most of the software and most of the spec for it. There was also this also guy that

goes by the name of free trader that brought maybe the second biggest part of it. For you, it was very clear even at the time, okay, Segre 2X is going to fail. Bitcoin Cash is the right thing to do now. Maybe people don't see it this way, but soon they'll realize Segway 2x fails, and then, you know,

there's going to start being momentum around Bitcoin Cash. Yeah, so maybe I would put it as strongly because you get to realize at the time this is in the future, you never know 100% what's going to happen in the future. But I thought it was more likely than now that Segway 2x was, okay. But question about the timeline here. So, you know, I don't know if these dates are exactly right, but this is just what I was able to pull from like some articles and stuff. But it seems that, you know, the Bitcoin cash chain was announced on May 15th of 2017, but the Segwit 2X, like New York Agreement, didn't come out until May 23rd of 2017.

So was the Bitcoin Cash like plan like happening with, did these initial seeds? Are they like the result of the Segwit 2X or is it a like, you know, did you already have this idea going in even before the New York agreement? So there was an idea to effectively fork the chain and create a big blockchain, but I was working on extension block at the time, as I mentioned. It was more of an effort that was supported by Classic and VU and XT as well. But what I jumped in is that,

so there was this segue with two X-F. I was convinced it was unlikely to work. And at the same time, there was like a lot of discussion between Classic and XT and B-D. but they seem to not be able to agree on what the spec gonna look like. So roughly two months before, yeah, two months, two months and a half before the actual form date, this is when I jumped in. I see.

And so, you know, so it was sort of this like, um, this like frustration, I guess that like, you know, uh, you saw that this like Seguit 2x thing wasn't going to work and it's just like, you know, you decided what, what, what, what? Yeah, there was a lot of frustration on my side. Yeah. What I was seeing at the time is that on one side, you have people that build something I'm not very interested in, but they are executing very well,

both on the business side and the infrastructure side, the development and everything. They are doing what it takes to make their thing work, except this was not the thing that I was interested in. And on the other side, there was a group of people that tried to do something that was more in line with what I wanted, but they seemed to make mistake again and again. And so that was, yeah, that was very frustrating. And so how did this, you know, coalition come together? So like you, so you mentioned, like, you know,

the XT classic and BU developers are kind of already, you know, talking about this for, but, you know, the Bitcoin Cash, like what I see as that coalition was bigger. Like, you know, you had a lot of these big miners like Bitman, you had like, you know, public figures, I'll call them like Roger Vair. Like who, how did this like, you know, thing just like in a short period of time of like, like you mentioned, two to two and a half months, like really come together and coordinate to like, it seemed, if I remember from my memory, like, you know, this Bitcoin Cash, Hard Fork actually seemed very well coordinated.

There was like, you know, somewhat of like unified messaging there. How did like all that coordination come? Who's the one who really stepped up and organized this? Well, it probably looked more organized than it actually was from the outside, from what you're saying. So who stepped up? So I stepped up for this back on the code and did some coordination, obviously. But a lot of those are people, actually. A lot of people that were in, you know, the big block movement wanted to see that happen.

And it was very organic. There was no, you know, there was no mastermind being made. It was very organic. And so let's speak a little bit about, I mean, you touched on it before, right? That there was a big disagreement was not so much around Seguid, but around Seguid as a soft fork. And there was, there was this strong argument in fear, which I honestly never fully understood that softwork were such, a soft forks were such a dangerous thing. And of course, other blockchains have taken a different approach,

Bitcoin Cash is taking a different approach, Ethereum's taking a different approach and kind of do regularly hard forks. But what is, why is this such a big disagreement around that? And what's, what's the sort of your perspective and maybe a Bitcoin cash approach to Forks versus the Bitcoin one? So, yeah, I think it's a big, like, both positions are a bit strange to me.

the like the no hard fork ever whatsoever and the one we need to do everything as a hard fork or you know like weird kind of ideological positions right um i'd say you know it really depends on it really depends on what you want to deploy in the network some something just make more sense as a hard fork or soft fork if you have if you have a natural way so say you want to add something new to the protocol If you have a very natural extension point where you can include that stuff, then you should do it that way and it's going to end up being a soft fork. But if there is no natural extension point, you should probably not try to retrofit something very weird

in a place it doesn't quite fit and just do a hard fork instead. There is also this interesting idea that there is actually no difference between a soft fork and a 51% attack. It's just like a software, it's just a miner refusing to mine on top of blocks that have some properties, and a 51% attack is the same, right? So the main difference is not a difference of what it is. It's the difference of perception. If you like the new rules that the miner are enforcing, then it's a soft fork.

It's not a 51% attack. But if you don't like the new thing that the miner are enforcing, you are facing a 51% attack. So some people are a bit, you know, put off by this. Yeah, I remember that was one of the arguments that my current made. And I think we talked about it back then, where his argument was basically that a soft fork is like more dangerous, right, for users because they don't explicitly,

they don't kind of explicitly agree with this update. And they just kind of go along because that's a new rule. Whereas in the hard fork, okay, if you don't actually download the new client and run the new client, then you're not like kind of participating in this. Yeah, that's why it's similar in the 51% attack in many ways because as a user, you don't have a, you know, have a lot of say about what's going on in case of a soft form. Right. You know, a censorship of a, you know, let's say we decide to censure a certain account that that is a soft fork really. that and so yeah the main difference between a soft fork and a 51% attack is very much do you see the change as a good thing or a bad team that's that's the difference it's very much of a

it's a perception difference on the technical level there's no difference and so what does the bitcoin cash ecosystem look like today so what are the different teams and uh you know the different clients. Okay, so in terms of not software, uh, Bitcoin ABC is still the main client. And this is the client that we wrote and continue to write. Uh, BU is still very big within the BCH ecosystem. And I'd say one of the client that is quite interesting is BCH, because those guys are, you know, so it's a bit more of an experimental client. Maybe I would not recommend the miner to use it to mine block. or whatever.

But because they are more experimental, they can innovate much faster. So they are playing with a bunch of new IDs faster than other clients are doing it. So it's an interesting client to keep an eye on. And maybe, I don't know, what is it like specifically about no software or more generally about the different actors? Yeah, and also more generally, like, what else? Like, what does the community look like today and how has it evolved? since the split.

Oh, okay. Since the split in August or the one in? No, no, I mean the original split away from, from Bitcoin. Okay. I think the community is actually stronger now, even though it's the bar market, so the situation looks worse if you, you know, if you look at it from the outside,

but I think the community is much stronger. It took, you know, at the beginning, like we mentioned, it was put together very quickly, actually. And so it took a bit of time for everything to settle down, to identify who are the good people doing solid work, who are the people that were just doing noise or making noise rather. And so it takes some time for everything to emerge and for people to take position that makes sense for them. And I think we are in a better position on that front. We are more organized and generally like everything.

is much higher level, let's say. So another question then, actually, as well that I had about, like, you know, the planning of the fork was, how did you guys come upon the name, like Bitcoin Cash? Like, why was this name chosen? And, like, you know, obviously one of the most contentious things about this name is that, like, you know, people like to say, oh, you're trying to, like, subvert the brand of Bitcoin. So how did this come about? And, you know, the famous, like, Roger Ver, catchphrase is, like, Bitcoin Cash is Bitcoin.

Like to what extent do you agree with that statement? And is that like what you're trying to do? Are you trying to replace Bitcoin? Are you just trying to create some alternative that's like, you know, that that will coexist? What's the goal here? Okay. So yeah, we kept the name Bitcoin with Bitcoin Cash because I think it has it has a legitimate claim to the name Bitcoin, but in a bit of a different way than people who say Bitcoin

is the real Bitcoin or something like that. I don't think the question of who is the real Bitcoin makes a lot of sense. I think it's so, you know, if you say a Bitcoin Cash is the real Bitcoin, right? The people within Bitcoin Cash are going to be happy with that statement, but the people within BTC are probably going to see that as a bit scammy. The people outside of crypto are like, you know, don't care about what's the real Bitcoin or what's not, right? It's not even on there. It's not even a question they are interested in.

So I think it's a bit of a red airing, right? People are putting way too much attention on that. So I have a opportunity to say that Bitcoin cash is one Bitcoin, maybe, and there are other flavors of Bitcoin. No, there is not like, you know, there is not just one Bitcoin like it used to be. And so then the name cash is there obviously to say that, you know, this is this is, this is, This is what we think is important about Bitcoin, right? This is the peer-to-peer cash system aspect of it, like in the title of the white paper.

And it's a bit of a statement that what we think is important is, you know, like the entente building this peer-to-peer cash system rather than adhering strictly to every single detail of what was coded and described in various early stuff. We recognize that, you know, maybe some of those. stuff need to be improved, like the blog size need to be increased, for instance. So, so it's, you know, it's, it's a bit of a, yeah, it's a bit of a statement that this is, this is a kind of Bitcoin and this is what we think is important about Bitcoin. And so how do you personally feel about the nickname B-cash? Like, is that, you know, do you think

that's a okay to use term? So the problem I have with it is that it's used often, and pejorative manner. There wouldn't be so much people being like, oh, be cash, be cash. Then I probably wouldn't see a problem with it. It's probably a useful, you know, sharp hand. But because it, because it no has acquired that negative connotation, then I don't like it too much. Now today, you know, at one point Bitcoin Cash was up to, you know,

20% of the Bitcoin, I think, market cap, or maybe even higher. And, you know, in terms of the hash rate, too, the two chains were at some point almost that parity, I think, in terms of the hash rate. But like today, of course, Bitcoin is like much, much higher in the price. I think today Bitcoin is around, you know, $4,000 when we record this and Bitcoin cash, I don't know, in the 100-ish, 130.

So, and also that hash rate, there's a big difference now, right? Bitcoin has a very high hash rate. And, you know, as you would expect, right, Bitcoin Cash. Yeah, I'm trying to buy a price. So that's not very surprising on that front. Yeah, it's not very surprising, right? But of course, the whole security assumptions of proof of work and of Bitcoin are really that a 51% attack is, you know, expensive. And that was what makes it secure.

But so with Bitcoin Cash today, that's not really the case, right? Like a big Bitcoin miner on its own could maybe do, you know, 51% attack on Bitcoin Cash. So is that something? that concerns you? Yes and no. So obviously the security on BCH is going to be smaller than on BTC because the price is smaller. When you put in in dollar term, they're running an attack is still fairly expensive.

And also, mine have demonstrated in the past that they were willing to pull a hash rate from BTC to put them on BCH temporarily, even at a loss to protect the chain. So I think it's a very, very strong sign that, you know, the miners that are mining BCH right now are eternally committed to protect it if the needs, if the needs is there, right? But doesn't that putting a lot of dependence on like the altruism of certain miners or like, you know, the external incentives of certain mining pools to protect the network? Because we've already seen like a number of like minority hash rate chains get 51% intact in the last year and a half. Like, you know, the biggest example I think is probably Ethereum Classic, which, you know, you know, I guess shares a lot of similarities in its positioning as Bitcoin Cash where like, you know, it's positioned to its like older brother, we'll say, right? Yeah, so GPU coins tend to be weaker in that regard because with GPU you can mine any other GPU coins, right? So the pool of available ash rate can be much bigger than what it looks like.

It's not like people can just pull from ETH to attack ETC. They can actually pull from almost every coin on the market. But don't you think the pool of Bitcoin miners is even bigger than the pool of all GPU miners from all coins? Probably not. Like except if you are ETH, that is very big. But for most GPU coins, it's much worse. I mean, I think your point is sort of fair that, okay, the miners have kind of proven that they will, to some extent protect Bitcoin cash and maybe step up.

But that feels like, it feels like very weak. You know, it feels like in Bitcoin, you have, you know, you have this game theoretic assumptions. And then you say, okay, it's actually economically infeasible to attack this at some, you know, at some scale. And then in this scenario, you say, okay, I mean, maybe that's kind of broken, but at least we kind of trust the entities that control is. So, I mean, it feels something essential was lost here. You always trust the miner. Though the tradeoff that you're making here is a bit different. It's actually fairly interesting.

And so I don't agree with that. I kind of agree with you that is weaker. But actually, some people agree that is stronger. And the argument goes as you are paying for that hash rate all the time, if you're in the majority chain. But actually, having so much hash rate on the chain is only, useful when you are under attack. So in various ways, you are overpaying for security. Whereas if you have a pool of available hash that can, you know, be used to defend in case there is an attack,

then it's more economically efficient. And I would actually both of those arguments are true in some way. So the security is weaker, but it's more efficient. Was merge mining ever a consideration? So, because this is something I've talked about, extensively with the Ethereum classic dev team. So, you know, has this ever been open on the table, like potentially merge mining with Bitcoin? Well, the problem is, so the problem here is that if you ever get close to the size of the chain you are managing from, then you are in the world of trouble because the incentive don't work anymore. And I think, I think this is likely to, to happen. So we talked about, oh, BCH ended up being like a non-negligible portion of BTC before.

In this condition, Merch Manning would not have worked very well. It would have been a big problem. And actually, I kind of predicted that the share of BCH compared to BTC would decrease the bit during the bear market. And the reason is that people are more sensible to the problem that cause immediate pain, rather than possible problem that's going to happen in the future, right? And so right now, Bitcoin is not running at capacity. So Bitcoin is working fairly well if you want to transact. It's maybe not as cheap as BCH, but it's fairly cheap right now. But what's going to happen is that when you, like, you know, during the next

bull run, when people are going to come in, you're going to see the same problem that we saw last year on BTC. And I expect that this, I expect when that happened that the share of BCH compared to BDC to increase again. And so that would be a mistake to do much mining in those conditions. And do you think you'll ever make sense to explore like really very different approaches to securing pick on cash, whether I don't know that's proof of stake or something else? So we have in the pipeline that technology called Avalanche. Maybe we want to talk about it later.

But Avalanche essentially, this is something we want to use to improve zero conf. But one of the side effect you get out of it is that it's much more difficult to do a 51% attack on the coin. And so that is the kind of stuff that is in the pipeline as well. I think it's probably a better approach than the number of money. If you buy this narrative that like, you know, the majority of the miners, so a miners on Bitcoin were like, you know, big blockers. Couldn't you do, was it ever in the books or like thought process of, you know, soft forking a block size increase into Bitcoin? And so obviously by that, I, you know, I mean things like extension blocks or like, you know, you merge mine Bitcoin cash and, and, and, and, and, and. soft fork a drive chain between them and like you know force them to be act in parity and stuff like

were any of these kind of things ever in the consideration of like forcing big blocks upon bitcoin through soft work um yeah well obviously i worked on extension blocks so that was kind of uh one of the idea behind extension blocks um though i don't know i don't like this idea of forcing and to people whatever. If there is a disagreement on something, I think it's better to fork. So, okay, it's better to find an agreement, right? But if no agreement can be found, it's, I think, better to fork and see what the market value at the end.

When this kind of stuff happened, you actually saw both branch of the fork increase in value. so the case of PTC and VCH or the case of ETH and ETC. In both cases, the sum of the two coin is larger than the sum of what was before. And the reason is you have two vision, right? And none of the vision can realize itself while everybody is fighting with each other. And after that, you have two vision that can be realized. So the overall value is increased. Obviously, if you fall for a more frivolous reason, then

this doesn't happen, right? You see a net destruction of value. But if the situation is really such as you have two vision and the people that have those two visions are fighting with each other and they cannot come with an agreement, then you are better of working than forcing, you know, off of the community to something they don't want. Now, can we like shift gears and talk a little bit more about, like, you know,

Bitcoin Cash's approach to scalability? And so, you know, you had this great, blog post talking about like, you know, how you guys are really focused heavily on like client like improvements and how we can create clients that can like start to support bigger blocks. And so yeah, can you go ahead and just give us a bit of a summary of that, you know, vision there? Okay. Yes.

So on the high level, there are many agreements that were made by the people that are more in the smoke block size that, uh, there are probably. when you increase the size of the block. And those arguments tend to be right on the qualitative aspect, but not very right on the quantitative aspect, right? So you don't run into all those problems when you increase immediately to a few megabyte and, you know, instead of one megabyte. But if you want to go to very large block, then there is,

there are actually many problems that you run into. And basically, they boil down to, you know, to that assumption. So for a blockchain that is based on proof of work to work well and all the incentive to work properly, you need that the time required to propagate a block on the network and validate it. You need that time to be small compared to the block time. Because when that's not the case, you first start to have perverse incentive in the mining that start to occur. And after that, the next step is that it doesn't work anymore, right? So if the time you need to propagate a block and validate it is more than 10 minutes on a Bitcoin or, you know, any variation of Bitcoin that have a 10 minute block time, then what's going to happen is that you're going to find block faster than block can propagate on the network.

So suddenly the situation is that the network doesn't converge to one, you know, one truth anymore. it's just like forks more and more and more and more faster than it can converge. And so if you want to have bigger blocks, you cannot just say, okay, we change that number in the software and everything is going to work great. You actually need to have solution for those values problem that makes the propagation and the validation of a block slower. And so on the very high level, it's not like it's more of a desk-by-a-sousand-cut kind of problem than there is like this big issue you want to solve. But generally, you want first, if you want to make the propagation faster, you need to propagate less information, right? That means that you need the node to be able to predict what the next block is going to look like as much as possible.

And so then you need only to transmit the difference between. what they're not expect and what the reality is. And you want to keep that difference as small as possible. So that's the first thing. And then the second thing is that you want to be able to validate the blog very quickly. And to do that, you need to be able to validate the blog in such a way that you have many small, independent chunk of work to do that don't depend on each other. And that way you can have different core of the machine to do each of them, or even if we

scale very big, you can have a rack of machine and each of them do a portion of the work. But if you have work that depend on each other, like what we call serial, then it's a bit of a challenge. So the general idea is like limit the serial stuff and deploy technology that allow not to synchronize with each other as much as possible ahead of time so that they have, you know, less work to do when the block arrives. Right. Just last week, we actually had Alexy Akunov from TurboGeth, and he's like kind of approaching a lot of these very, very similar approach to the scalability issues in Ethereum where like, you know, a lot of other people are focusing on like sharding and stuff. But Alexi, he's been really focusing on like, you know, let's push down the propagation time. Let's like improve the sync speed. Let's improve the validation speed. So a lot of similarities there.

Well, those are not, you know, those are not very new. ID, this is all many large-scale systems. This is all Facebook works, for instance, where the work is done in such a way, like there would be no way to do any kind of serial work at Facebook scale, right? It's just impossible. So all the work is organized in such a way that you can distribute on many machines a small amount of work and this small amount of work don't depend on the work that the other machine are doing, right? And then all the machine propagate a result

back to you and you can aggregate those results and deduce whatever you want to compute from it. I would say let's go into, so you mentioned a little bit that the performance increase comes when, you know, propagation happens more quickly and propagation can happen more quickly if, you know, I as a note can already kind of like tell what the next block is going to look like without having, you know, whole blocks being sent around. I guess that tag. into the topic of transaction ordering and then the changes you guys have made there. I mean, but first of all, let's like, how does transaction ordering work today in Bitcoin? And what were the downsize of this?

Okay, so right now in Bitcoin, the transaction ordering is such as, we call it topological in computer science term. And what that means is that you can essentially put transaction in any order in there. With the only constraint that if one transaction spent from another, they need to be order such as the, you know, the parent transaction is first, and then the one that's spent from the parent, the check transaction is after in the block. So you have, you have this constraint, but you have no other constraint in the block. Okay. And so that means that if I am as a miner, I create a new block and, you know,

Sonny is a different minor, then Sonny has basically like no, I mean, he may be able to sort of predict what transactions will be in that block, but he doesn't know kind of the structure of the block. Yes, exactly. Because there are many possible valid ordering, then when you find a block, you not only need to transmit to the author party what transaction are in the block, but you also need to transmit the order in the block.

And when you do the computation based on information theory, let's say assume you know of a set of transaction and sony knows also of a set of transaction that is almost the same as you right because you are both connected to the same network and the transaction propagate on the network so you both know of about the same transaction so let's assume that you want you find a block and you want to tell sony what this block is looking you know what what the block looks like well if you know of the same transaction you just need to say sending one bit yes or no for each transaction. So if there is any transaction flying around,

theoretically, you could transmit n bit of information to Sony to tell him what transaction is in the block and what transaction is not in the block. Obviously, in practice, you need to send more than that, but that's the theory can limit. Now, if the ordering is important, then you need to send also the information

about in what order they are. And obviously, if you have N transaction, then the first transaction can be in N different position, right? And the second one in N minus one position, because it cannot be where the first one is and so on. So you get n factorial possible ordering. And to transmit that, you need n-log-end bits of information. So you have a factor log-end here of difference between the two. So say if you have a thousand transaction in your block, then you literally have 10 times more information. that is about ordering,

then transaction that is about what is in the block and what is not. And as you grow bigger, it only gets worse. So any kind of technology that rely on you and Sony, having a common knowledge of what the state of the work is and up essentially transmitting almost only information about ordering and very legal information about what's actually in the block. And so those are the theoretical limit,

theoretical limit but in practice you have this technology called graphin that allows to transmit block and there are two versions of graphene that have been implemented right now they are in the prototype stage and one that transmit the other and one that doesn't and you see that the one that doesn't transmit the order needs seven times less information to to propagate a block so it's not as good as the 10x you would expect from the theoretical perspective but we can see that it's in the same ballpark. Okay, that's amazing.

And I mean, I know in Bitcoin, there's also been, you know, some kind of efforts on, you know, reducing propagation time. There's a relay network. But that works differently because that only transmits the headers or like, is there, what are the similarities and differences with the efforts that have happened on the Bitcoin side to reduce propagation time? So the general idea is the same, right? The general idea of all the fast-relay techniques being like compact block or the fast-frey network or graphene or whatever, right?

They all rely on the same assumption that if you want to send a block to Sunny, the two of you have a lot of information in common already. You know about most of the transactions that possibly can be included in the block. And so instead of transmitting the content of the block to Sunny, you transmit it a special, you transmit to him a special data structure that's going to say usually there is a short ID that is associated with each transaction. And you're going to say to Sunny, the block have this, this, this, this, this, this, and that transaction by sending a list of short IDs. And then Sunny is going to look into the transaction he knows about

and match the short ID. to know which one are in the block. And you need to have those short ID that are ordered in the way they appear in the block. And that's almost, you know, mass fast block relay. You know, they all do some kind of variation of this. And I guess in Bitcoin, the thing is that what you guys are, or what you guys are trying to do here with having a kind of a predefined order, right, where it's exactly like if I

produce a block with a certain number, a certain list of transaction in it, that block is going to look the same as if Sonny produced a block with the same transactions. Is that basically? Yeah. So let's imagine we continue on the same technique, right? So you send to Sunny a list of short ID that correspond to each transaction. Then for the first one, Sunny need to match all the transaction it knows about to know if it matched that short ID. And for the second one, the same and the short one the same and so on. But if you have a predefined ordering, Sonny is only going to need to match the transaction

that could possibly fit at that position in the block. So if there are 10 transactions in the block, then for each ID, Sunny needs to essentially have like one tenths of the amount of transaction to match that short ID, which means you can get much more aggressive on how small the short IDs are because they need to discriminate

between much less transactions. That's the intuition behind why you can transmit much less information. But the change that, so you said that's in tests now and in exploration, is this graphene, but when this graphene would come to Bitcoin Cash, you would basically have, you know, canon, like a predefined transaction ordering. And if I have, I produce a block certain amount of transactions, it will look the same as with Sunny. And so then we can, we can cut down. the amount of data that's being propagated.

Yes. And this would, of course, be a hard fork as well. No, no. The outfork is enforcing transaction ordering, which we do. So no, we can deploy graphene, you know, whenever, whenever it's ready. Right now it's in prototype stage, but, you know, it's probably going to be ready during the year. So now you do have a transaction ordering, which is enforced already,

but there isn't the technology. to kind of take advantage of that order to, like, reduce the amount of data that's being sent around. And that's the graphene thing. Exactly, exactly. That technology is in prototype stage at this point. It's not yet deployed. But so really quick, though, this does come at a cost, though, right? Because so once you've gotten rid of this, the, what was the term you use, the natural transaction ordering or whatever the topological, topological transaction ordering. Once you get rid of that. Now you have, now you put an extra burden on any full note or anyone who's verifying a block to basically make sure that you don't have like, you know, you don't have, how do you

deal with like these child pays for parent and whatnot? Okay. So, um, from the client's perspective, uh, the person that received the block and need to validate it. What actually happens is that topological ordering is exceedingly difficult to, um, um, um, you know, um, um, you validate in parallel. And this is one of the reasons we wanted to remove it, because you can parallelize the block validation. You know, it's easier to parallelize the block validation. And the way you do it is that you pass over the block twice. So once you pass over the block and go over all the outputs of all the transaction and you add them all to the UTXO set. So that part can be done in parallel. It's like very embargo.

single parallel. And then you do a second pass on the block and you go over all the input and you mark all the input that have been spent in the block as spent. And if you do it that way, you essentially have a two-step process to validate the block and each one of this step is, you know, very parallelizable. Yeah, I don't see how this helps with the parallelizability here. It seems like you could do something similar with topological. I don't see why top. So in the optimistic case and topological, you could be doing it in parallel and only when you hit like a child pays for parent, then you have to deal with that, right? Yeah. So, yes. Yes, absolutely.

You can do it optimistically in parallel and then fall back to the topological stuff. But your fallback is going to be serial, right? Always. So I can produce a block with a lot of chain transaction in them and get you to validate it in Like, you know, you have no essentially, you have no parallelism. Would have that. So I can poison you with a bad block. But isn't that true in this as well?

Can't I just trade a block of like a chain of child pays for parents and just like, and then you basically essentially end up falling back to sequential as well because you're going to have to do iterations like. No, because you are going to add all the output to the UTXO set. Right. So say you have a thousand chain transaction and they all have one input, one output to me. you know, to make it simpler to understand. Then you're going to add the 100 output to the UTXO set.

And then second pass, you're going to spend 100 output. And so at the end, you're going to have, like, you know, one that is spent and one that is created in the UTXA set. Great. No, that's, that's very helpful. And that sounds like a very interesting change. Now, another, another thing that's interesting. So Bitcoin Cash, when you guys forked, the new,

block size in Bitcoin Cash is 8 megabytes. And since then, there's been a third of blocks is increased to 32 megabytes. Why is that? I mean, the Bitcoin Cash today, there's not that much usage to blocks are mostly empty, who's never really at capacity. So what was the reason to go to 32? I'd say probably because we can. Yeah, you got to understand that because, because

there was so much contention to increase the block size to begin with, there is a bit of a apprehension within the BCH community that the block size is going to be stuck. And so I think this is mostly why, even though it's not needed right now, we would have 8 meg right now, we would be perfectly fine. Like we are not, you know, we're not using that much capacity. But people are afraid that by the time we need that much capacity, then maybe, you know, the ecosystem would have drawn a lot and we would have like another class of smoke blocker in there maybe.

Yeah, okay, that makes a lot of sense. So basically saying you want to default, to change the default now when, you know, there's no real controversy around it rather than get into a situation again, like in Bitcoin. And of course, in Bitcoin too, I mean, I know initially when Bitcoin was launched, I think there was, I don't know, block limit or it was like a really big one. and then at some point it was added as a sort of hack, oh, let's just put this in for the moment so that somebody can create a giant block.

And then later, when you reach it, we get rid of it. I think that was the thinking of Satoshi back then. And it didn't seem like he anticipated that this was going to become a contentious issue. Yeah, I think this is what happened. Yeah. So because that happened once, you know, people are kind of afraid that it's going to happen twice.

So right now there is a discussion. within the BCH community to have an algorithm set the blog sites rather than having people deciding once in a while to increase it. Yeah, that was the original idea behind like the original Bitcoin Unlimited proposal, right? No, Bitcoin Unlimited is a bit of a different proposal. What they were doing is what they call emergent consensus. So essentially it creates the notion of a soft consensus. So if you have a block that is very big and that is bigger than you block size,

instead of marking that block invalid, you would mark it excessive, right? Which means it's not invalid, but you are not going to follow that chain right now. And then what happened is that if you see that most of the network is building on top of that other block that you consider excessive, rather than on top of what you consider is, you know, main chain, then you are going to reconsider that block and try to actually validate it. So that is the idea behind emergent consensus. One of the problem with that is that it creates, it creates a situation where it's quite difficult to upgrade actually,

because everybody needs to do it at the same time, because if you do it by yourself, you know, may end up creating blocks that are too big that everybody reject and you lose a bunch of money. So it puts minor in a bit of of a tough spot. So I think this is why wasn't widely adopted. I see. I also heard like some stuff about like the Bitcoin Unlimited team

working on what they call gigabyte blocks. Is that like, you know, how realistic of a proposal is this? And like is this like some sort of like, you know, long-term vision thing? Or it's just like something that you guys are looking into in like the very near future? So the Bitcoin only people are running what they call the G. gigablock test net. That is what the name say. That's the test net with like ridiculously large block size and they have tool to generate a ton of transaction on there. The main goal is not

to do like gigabyte block right now, but it's to identify what kind of bottlenecks exist and what kind of challenge exists when you want to grow the capacity of the network. And then we can have, you know, we can take lesson and have data that from that experiment and use that to improve the software today. But there is no immediate plan to move to 1 gigabytes. Though, you mean, like, if the software can support it and if it works and everything, why not? Right. But it's not the case right now that we can do that very safely.

Okay, cool. And then, so, you know, I guess the last thing, you know, as we're running up on time for this week, one of the last thing I want to ask about, like, you know, one of the reasons that I actually personally got like, you know, pretty interested in Bitcoin Cash was, uh, you guys seem to ever, like, you know, we've discussed this throughout, uh, but you guys seem to have a very open policy on hard forks. And so, you know, to me, Bitcoin Cash just seemed as this place where like, okay, all of these like ideas that could be done as hard forks on Bitcoin, now we actually have a place to like try them out and test them. And so I know that you guys came up like,

like some roadmap process where like you are committing to like six hard forks every six months or something similar to that. Could you go ahead and discuss a little bit about, you know, how this was agreed upon and like why it was agreed upon? Yeah. So there was, yeah, this is what we do. We do an upgrade that usually bundle a few outfork and a few soft fork change every six months. And we end up the first. first to do that. Actually, Monero have been doing that for a fairly long time. And you have other coins that don't have a very specific schedule,

but that also do work on a regular basis like ETH. So the reason why we went that way is because we knew that if we want to increase the capacity a lot, we're going to need to change a few stuff. It's not enough to just change a number and expect everything to work well. right because the number is more of a security measure because there are stuff that don't work when you go bigger and it's not because you change that number that suddenly it becomes secure to you know do big blocks and so we knew that we would need to improve all that thing works to be able to create and propagate and validate those large block faster if we wanted to you know realize that vision essentially. So we needed to have some way to do out for it to do that. And doing it on the schedule

that is set ahead of time makes things easier for everybody because now everybody know what to expect. Well, then thanks so much, Armarie. This was a really, really great discussion. And so I think that concludes our first part of this Bitcoin, big Bitcoin cash episode or interview. And so we're going to be going to do a second part, which comes out next week, and we're going to speak about, you know, the split. You know, there was a fork of Bitcoin Cash. And then, of course, there was the fork between Bitcoin Cash and now what became Bitcoin SV. So we'll speak about that. And then we'll also speak about, you know, a lot of other things that you guys are working on technically because Bitcoin Cash is certainly like experimental

in exploring a lot of interesting new technology. So, yeah, we'll come. back to that interview next week. Thank you for joining us on this week's episode. We release new episodes every week. You can find and subscribe to the show on iTunes, Spotify, YouTube, SoundCloud, or wherever you listen to podcasts. And if you have a Google Home or Alexa device, you can tell it to listen to the latest episode of the Epicenter podcast.

Go to epicenter.tv slash subscribe for a full list of places where you can watch and listen. And while you're there, be sure to sign up for the newsletter, so you get new episodes in your inbox as they're released. If you want to interact with us, the guests or other podcast listeners, you can follow us on Twitter. And please leave us a review on iTunes. It helps people find the show, and we're always happy to read them. So thanks so much, and we look forward to being back next week.