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

Episode Date: March 5, 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: Join the most interoperable ecosystem of connected blockchains. Learn more at cosmos.network/epicenter. 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/277

This is Epicenter, Episode 277 with guest Amory Sese. This episode of Epicenter is brought you by Cosmos. Cosmos is building the Internet of Blockchains, an ecosystem where thousands of blockchains can interoperate, creating the foundation for a new token economy. If you have an idea for a DAP, visit cosmos.network slash Epicenter to learn more and to get in touch with the Cosmos team.

And by Microsoft Azure. Do you have an idea for a blockchain app but are worried about the time and costs it will take to develop? The new Azure Blockchain DevKit 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.ms slash epicenter. Hi and welcome to Epicenter.

My name is Brian Harmon-Krain. And my name is Sunny Agarwal. So, you know, once again, jumping right into some announcements. This week, like I said, mentioned last week, we're holding a meetup in Paris, an epicenter meetup where you can come meet the hosts, the guests, and some other listeners. And, you know, it should be a good time. ETC as well, I'll be giving a talk there this

week on a workshop on the Cosmos SDK. So if you're interested in checking that out, come check out my workshop. Oh, and what we forgot to mention last time we put this link in the show notes too. If you want to register for this meetup, then go to the website, epi-center.rox slash e-ccc. So we're going to have this link in the show notes too. So if you, if you can sign up there, RSVP, you're going to get informed about the venue or by the time you go there. I think the venue will probably already be there. But so, so go to that, make sure to go to that URL. Sunny, before we get into the episode, tell me the story of how you became sorrow of Bitcoin Cash.

Yeah, so a couple, about a year ago, the Rick Falkvind, who is the founder of the Pirate Party, I'm a huge fan of him. I remember in our five-year AMA episode. I mentioned he's a guest I'd really love to have on at some point. So he wrote this really great, it was called The Letter from the CEO of Bitcoin Cash, and it was just like this joke kind of thing.

Very good points. you know, it's very similar to his book Swarm-wise, but he was kind of critiquing, like, formal positions of power and kind of saying, like, talking about how Bitcoin Cash has to be this, like, decentralized community, and we shouldn't be, like, going with, like, figureheads. And so he kind of said that, like, you know, everyone should just give themselves made up titles just to, like, make fun of the legacy title. So he gave himself CEO of Bitcoin Cash. So, you know, I decided, you know, I'm going to give myself the Tsar of Bitcoin Cash. And so I went ahead And I did a little bit of Photoshop magic.

And now if you ever go on my Twitter profile, my Twitter profile is myself as the czar Bitcoin Cash. And so, you know, I wasn't actually, I didn't really get too involved with Bitcoin Cash until, like, just this past December, I was in, like, I went to this conference in Hong Kong where I was speaking about Cosmos. And I met, that's where actually where I first met Amari as well as, you know, Jason Cox, another one of the core developers and some of the other developers from the other Bitcoin cash implementations that we mentioned last week like big beat bitcoin unlimited and whatnot and so you know after talking to amari there i got like you know i got kind of got actually like okay that was like

the first time i really actually took the time to understand like what was going on in bitcoin cash and i thought it was really exciting um i got this cool mug out of it which i'll be drinking from this entire episode my bitcoin cash mug which is nice but uh yeah i'm i'm honestly like pretty excited in this episode we'll definitely talk a lot more about you know some of the future development which is is kind of what intrigued me a lot in this Bitcoin Cash narrative. Yeah, absolutely. So with that, let's go to our conversations from Murray. So we're here again this week with Amory Seche.

He's the lead developer of Bitcoin ABC, which is the main implementation, the main client for Bitcoin Cash. So this is our big, kind of our big exploration of all things Bitcoin Cash. If you haven't heard last week's episode, I would recommend you go about. back to last week's episode, we spoke a lot about Amory's early work in Bitcoin, then kind of the block size debate, Segway 2X. It's kind of a little bit of a history expedition in both Bitcoin and Bitcoin Cash, and then how Bitcoin Cash came about.

And also the kind of the first technological things where Bitcoin Cash really differentiated. So specifically transaction ordering and, and a thing called graphene, and we spoke about hard forks, a bunch of other things. So I recommend people check that out. But this week, we want to kind of move, you know, continue our exploration of Bitcoin Cash

and dive a bit deeper into some more recent events, as well as the future roadmap. Yeah, so thanks for joining us again, Amory. Hi, hi again. So we left off the last time when we had, you know, Bitcoin Cash is this new chain with, you know, different vision, right, a vision that was more focused on, you know, improving quickly, being okay with hard forks, being maybe okay taking more risks and really trying to do the cash part, right? So having a direct-to-peer

blockchain rather than kind of a settlement layer. And, you know, that seemed like a unified kind of community back then. And now over time, it seemed to have grown more apart. And of course, this ended up resulting in the fork of Bitcoin ABC and Bitcoin Cash and then Bitcoin became known as Bitcoin SV. Can you tell us a little bit? How did the, did their divisions in the Bitcoin Cash community emerge early on? And what were they?

Yeah, but I think. Craig Wright, especially with probably the most public figure behind DSV, was always a very polarizing figure. Because some people believe is Satoshi and some people believe in the scammer, right? So that was always a very controversial figure. So, you know, no, the controversy probably came up to its apotheos and we can move on. Craig Wright started entering the Bitcoin Cash ecosystem. So we announced Bitcoin Cash at a conference in the Netherlands in Harlem. And at the time, Craig Wright was promising to do a mining pool on BTC that would block Segwit.

And obviously, it never happened. But while he was making those claims, he made a lot of declaration about bid blocks and stuff like that that several people of her liked. And so what happened subsequently is that he had an easy time inserting himself into that community, essentially by saying what people wanted to hear. And many people were not very careful about that. And so that's how it happened. I guess I have to ask this question.

Where do you personally stand on this issue of Craig Wright being Satoshi or not? So there is no proof that Craig Wright is Satoshi. So in that sense, Craig Wright is as much Satoshi as anyone else. If you were to produce a proof, I would have to ask myself the question, do I believe that proof or anything? But as long as there is no proof, there is not much value in that question. I would say it is unlikely for many reasons. One would be very similar to what Vitalik Bertrand said at the time.

If you have an easy way to prove something and instead you choose very convoluted and not very convincing ways, it probably, most likely it means that, you know, it's not. Right. And, you know, Evan, if it turned out to be Satoshi, which I don't believe is very likely, even if that was the case, it doesn't remove from the fact that, you know, largerized many scientific paper, it produced many fake documents. You know, like generally is not the kind of person I would want to follow. So it would more, you know, it would change my opinion of Satoshi more and it would change my opinion of Craig, if that makes sense.

Yeah, I mean, one thing that stands out to me, so there's this book called The Book of Satoshi. And I mean, you probably read many of these foreign posts originally, but this is a person who just went through the big, and talk for him and basically compiled a lot of the answers from Satoshi and then kind of published as a book. So I read that at one point. And it was actually really, really interesting. I thought it was super fascinating to kind of get a sort of look into the discussions they had back in, the way he was arguing. And, you know, I came away really impressed. I was like, wow, this guy is so, you know, smart, articulate, balanced. He seemed to be very open-minded. And then you see like, Craig, right? show up and that guy is just, you know, constantly making these false statements being super

loud, obnoxious, angry, belligerent. And it's like, these obviously are not the same people. That makes no sense. No, it's not the same people. Yeah. I mean, I remember, uh, I met a lot of like Bitcoin cash, uh, people in the Bitcoin cash community, even people who are very anti, like, you know, disagree with a lot of Craig says, who still buy into this narrative that Craig has like spun that he, you know, he maybe wasn't the only one who was part of Satoshi, but like, you know, was part of this group of Satoshi. The most common narrative I've heard is just like Dave Clyman's story and like Craig was like working with him.

And so like, you know, maybe the original Satoshi was Dave and Craig kind of like took over that mantle kind of. It's possible, but there is no, you know, there is there is not that much proof that it is true or false one way or another. So all of that is just speculation. People always have loved, you know, speculate about who Satochi may be and all of that, but it's just that. Okay. So, you know, Craig and N-Chain kind of, you know, got, by the way, for those who aren't aware, N-Chain is the name of Craig's company.

They kind of got involved with the Bitcoin Cash Project a little bit early on, like you said, you know. So when did, was there like a sense of growing division like from that early on or like I remember, I remember there was this like big conference called the Satoshi's Vision conference about a year and a half ago or so. And it seemed that everything had like a very unified front back at that point. And I don't know. Have you seen his entry at that conference? I think that was extremely cringing.

I actually don't know anything about this. So could you? Okay. So, so he went up on stage with like. some kind of rock music, you know, blepping ends of people along the way or whatever. That was, that was extremely cringy.

I don't, I don't think Craig can feel shame, but, you know, I think a lot of people felt shame for him that day. I see. And so you think, like,

so you think that there was like an early division showing up just purely around, like, the cult of personality that Craig has built up. And like, so, you know, maybe it wasn't any, maybe early on there wasn't much technical division,

but there was a feeling of like, oh, what's this guy doing? Like he's building this cult of personality and it might be a threat to like the success of the project or what? Oh, yeah, yeah. Even before it started, like even before before, that was something that was there. A lot of people were very worried of him. The problem is or, you know, it's a problem or it's not a problem.

It's a problem in that case. I think it's generally, you know, it's generally a good thing, but it's a problem in that case. If you have a decentralized community that is, you know, like very informed itself from the ground up, then there is nobody that can say, okay, this guy is not part of the community and needs to go. Right. Right. And as long as you have a significant portion of the community that is willing to have him around, then, you know, he's going to be around. I see.

And so why do you think there was like, you know, at least for like, you know, I guess what we talked about last week was, you know, the year. one of Bitcoin Cash. And so why did you think during that year one of Bitcoin Cash, like there weren't many people calling him out in that, like at least publicly? I don't know. They were, though. Like, almost all the technical people called him out at some point, especially when he did his, you know, it's stuff about selfish mining.

A lot of people called him out. The problem is that those ID are fairly complex. like, you know, the idea of selfish mining is, you know, fairly difficult to crush to someone that doesn't have a technical background. And it's fairly contrary intuitive, right? So if you just have a cursory knowledge of all that work, it seems that something like selfish mining would not be, but it turns out that when you run the math, it actually works out. And so when that happened, a lot of people called him out.

this is when he came up with the negative gamma where for people who don't know, gamma is like a proportion of node that takes some action compared to the total number of nodes. So it's obviously a number that is between zero and one. It cannot even be a zero or one actually. It's like between zero and one excluded. And so obviously gamma cannot be negative.

So that was a lot of fun. That's the one where like Vitalik, called him out on like state well vitally called him out i mean gusier called him out i called him out peter rison for bitcoin unlimited called him out like almost everybody that have a solid technical background was about to call him out on that one actually it's it's very funny because then it was like okay negative gamma is possible because the notion of negative probability is the same and he he quoted a paper supposedly that would you know support its claim and it tells us that a friend of mine know the guy that wrote the paper.

So that friend of mine, you know, got in touch with the person writing the paper. And that person essentially came out and said that the interpretation of the paper that Craig was making is obviously completely wrong. And this is, I don't know, famous, it is very famous in the BCH space. There is this quote, risk finance, where Craig essentially like his whole argument was crumbling down and he understood by risk finance

in like in the tweet or two words that you already don't mean anything but that was quite funny so no no people use risk finance as like a go-to-gat phrase when you want to when you want to like when you want to say that something is completely nonsense some people like that I use that now I think with Bitcoin SV

I haven't, I mean, it was a mystery to me why anybody, uh, anybody would buy this, why this was. So I think Bitcoin SV doesn't seem like a particularly serious project. And Craig Wright, I think we all share our skepticism about him. So I don't think we should have spent too much time on. But just briefly, so I mean, were there really any, can you talk about the fork or like, what were there, were there some technical differences?

in, you know, different opinions about where Bitcoin should technically go. And can you talk a little bit about that? Yeah, sure. So one of the, essentially there were two very big argument coming from the SDICB before the fork. One was about this wormhole projects. So one hole is a token solution that works on BCH. And to ensure scarcity, so that you cannot use

of the resources available on the system, they use a mechanism where you burn some coin. And so that was very to the dislike of the BSV camp, which I find rather funny because if people want to burn their coin as far as I'm concerned,

like I wouldn't burn my coin, but if people want to burn their coin, this is theirs, right? This is like exactly the financial freedom that we want to deliver to people, If people want to hotel, they can hold on. If people want to spend their coin, they can spend their coin. They want to burn and it's up to every single individual to decide what they want to do with that coin.

So that part was a bit of a problem. And the second part that they argued a lot about was canonical transaction of the ring. But what happened is that early on, you can even find on the ancient website, well, probably they removed it by now. But it was at the time for like the whole year that it was. in their road map because it was something that was discussed a long time ago. And then Craig was again and then we had a meeting in Paris with a few of people where the bag ring again and then it was against it again. So it was like constant flip-flopping.

So I don't think this is the actual reason. I think those people wanted to fight essentially and they picked up whatever reason was, you know, available at the time. but I cannot read my right so that's just that just what seems to be the case to me so is there anything left to this story like do you think bitcoin SV is just going to disappear or is there still kind of issues remaining from the split well I don't think that roadmap makes a lot sense but you know if they want to do it you know good for them this is this is this This is the freedom that fork brings to the table. Right.

This episode of Epicenter is brought to you by Cosmos, the internet of blockchains. We couldn't be more excited about the upcoming mainnet launch and to see so many projects already building on it. Blockchain technologies are evolving fast and development shouldn't be one size fits all. As a DAP developer, you need the tools that will allow your DAP to scale, grow, and evolve over time. The Cosmos SDK is a user-friendly modular framework which allows you, to customize your DAP to best suit your needs. It's powered by tenement core, an advanced

implementation of the BFT proof of state protocol. Cosmos takes care of networking and consensus, and allows you to focus on building your application in your language of choice. Ethereum smart contracts will be supported soon, and the SDK makes it simple for you to connect to other blockchains in the Cosmos network. If you have an idea for ADAP and would like to learn more about the Cosmos SDK, or if you'd like to connect your existing DAPD to Cosmos, visit cosmos. For Epicenter listeners, the Cosmos team will reach out to answer your questions and help you get started. We'd like to thank Cosmos for those supportive Epicenter. So what exactly is their roadmap here?

Like, you know, they have this like tagline of Satoshi's vision. And so I know what it's right? It comes from the conference, Satoshi's vision that were recognized by other people. Everything they have like it comes from somewhere else. The whole stuff is a giant copy paste. So from my understanding, there was this like, that they're bringing in Bitcoin SV, where they're trying to like push it back to essentially like the, oh, Bitcoin 0.1 was the ultimate perfect version of Bitcoin. And that's why they're

like reenabling op codes. I don't know. I think they have a strategy that is more interesting than that, not from a technical standpoint, but from more of a social logic at standpoint. Because the motto they are going for is that it's what Bitcoin was intended to be. And what What is great is that Satoshi is not around anymore. So Satoshi is not going to say, you know, oh, this is not what I intended, right? So when you do that, you don't even have to do exactly what was in 0.1 or whatever. You can claim that, oh, this is what Satoshi intended. And so there is a very religious aspect to it, you know, like people that are going to preach are going to say,

okay, this is what Jesus met when, you know, whatever story from the Bible happened, right? and you have like different, different priests that have different interpretation of what that is. But they are all like, okay, this is what Jesus met, right? And you have a very similar phenomenon where the leader of PSV, they pose themselves in kind of a high priest who can interpret the Holy Scripture of Satoshi and told the people what Satoshi intended there, which I find a very, it's a very fascinating phenomenon from a socialistic standpoint,

But I don't think it's very solid base to build the cryptocurrency on. I see. And so I remember also, like, part of what led up to the split was that Enchain, like, submitted a proposal about adding, like, some specific opcos and those were chosen not to be included in this hard fork, but rather than the next one. Can you tell us a little bit about, like, what exactly was that, like, you know, timeline there of, like, that, of the technical roadmap, which caused this, like, final, the last, straw to break essentially.

Okay, yeah, sure. So Enchain wanted a series of upcode to be re-enabled that used to exist in the very initial version of Bitcoin, but that were disabled because the implementation was buggy. And so they were disabled at the time. And Enchained wanted to re-enable those upcodes. And so in the fork in May before the one where there was a split, the one before that, we were enabled some of the upcodes and Shane said they would do the work and everything, but at the end, a ton of the work ended up being done by Shabaston Cilor and Jizen Cox and myself

to make it happen. Because there is a lot of work to do between, you know, something that works and something that is production quality. And they were not quite willing. to, you know, they delivered something that works, but, you know, they were not willing to push it to the kind of quality requirement that we wanted. And so the first time we did it, but the second time we don't want it to do it. And so it did not happen. That's pretty much what happened there.

Okay, so we had these like two conflicting technical visions and, you know, largely fueled a lot by, personal issues. Yeah, personal issues. So could you walk us through a little bit about the timeline of like what exactly it happened during the heart fork? Because like, you know, a lot of people, I think a lot of people may have like, you know, heard of this and like, you know, they're like, oh, there's something going on, some hash war or something.

I know what, like Roger Vair keeps flip-flopping back and forth. So could you explain to us like, okay, so, you know, and, you know, there was some drama around replay protection. So can you just take us through a walkthrough for people who aren't really that familiar with what exactly happened? What was the timeline of the month or two leading up to this fork and as the fork was happening?

Okay, so three months before the fork, it's when we have a freeze date or what's going to be in the fork so the ecosystem can get ready and we can have a lot of time to test and if there is some problem, and we have time to readjust everything. So three months before the fork, we end up with the freeze date,

and it turned about that those upcodes don't make the cut. After that, there was a meeting in Bangkok, where essentially there was a meeting to try to find a common ground or try to find if there was a common ground that existed. You have to the audio recording of that meeting are available online. if you want to look for them. But essentially what happened is that the first day in the morning, Craig Wright stoned out of the room, screaming,

screaming insults and stuff. And so they ended up not being a very productive meeting because then they were two people remaining, or three maybe were people remaining representing in shame and stuff, but they were not the one having too much decision-making power. So in order to being not very productive, right? I have nothing happened there. So moving forward, they decided of that to start an alternative client.

So they forked Bitcoin ABC before we, you know, at the stage before we implement the fork. And they call it Bitcoin Satoshi's vision because there was the Satoshi's vision conference and it was a name that, you know, it was a a name that was popular, so they reused that. And then they decided to run that client. And then they were ensuring everybody that there would be no fork. There would be like one coins. And what everybody that knew of all this technology is working, right? It was like, okay, if you are running a client that have different consensus rooms,

then they're going to be two chain, right? This is not that work, right? But all those people were like, no, no, there are not. going to be any for it blah blah blah so you know and the day happened and there is two clients with two different rules so no there's two chains that's that's that's that's simple as this okay so then you know we have this fork happen um there was this hash war that happened once the fork started right and could you tell us what the what exactly the goal was here like who are the major mining pools that were supporting bitcoin cash or bitcoin abc and who were the major major

to mining pool supporting Bitcoin SV and why did people make such a big deal out of the whole the whole ash war narrative was always very bizarre to me because i don't think it makes a lot of sense because once you have two chains right they are never going to emerge into each other or anything right like it doesn't really matter how much ash there is on which one or you have two coins and it's it's not going to change anything so um what happened is that you uh mostly Kongheek and BMG, which is the mining branch of N-chain. So those people were mining BSV at a fairly significant loss. And then they made threat of 51% attack and stuff like that.

So there were some other miners that were friendly to BCH decided to put extra hash on BCH to disincentivize any kind of 51% attack. And there was, you know, that was the end of, so much. There's a little bit of, I remember there was also a little bit of, like, controversy around, like, I think Bitcoin.com, I think it was, who, like, you know, started to move a lot of its hash power over to Bitcoin cash from Bitcoin. But, like, you know, without really informing their constituent miners that, like,

oh, your hash power is being used for a purpose other than what you maybe expect it's being used for. And so do you think, like, you know, I guess this is kind of like a, separate question, but do you think this is like, you know, an okay thing to do on the behalf of a mining pool operator? Or do you think like we should put more accountability on these mining pool operators to prevent them from doing these kind of things? Okay. So I'm not exactly sure. I don't have like all the internal information of what's going on at Bitcoin.com. So if you want the specific data on that one, you would have to

have an episode maybe with Roger or someone else from Bitcoin.com. But generally, right, it really depends on the contract that the mining pool and the mire have between each other. A lot of the mining pools nowadays have the kind of contract where the mining pools say, we're going to mine BTC and BCH and try to equilibrate between the two. And then, you know, payback depending on what the reward is. The payback may not even be in the coin that the people have chosen. So if this is the kind of contract that people are under, I don't think this is that much of a deal.

But if the contract is very clear that I am mining BTC or I'm mining BCH, then that's a bit of a different issue. It's all about, you know, what was the agreement between the people on the miner, right? Yeah. So let's just a final thing on this. And then I would say let's move on from this topic. So there's a lawsuit going on now, Craig Ruff. suing you and some other people. Can you tell us what's this lawsuit about?

Yeah, so I'm not a lawyer, so it's a bit difficult, but there is a lawsuit where some company in Florida that is apparented to the BSV community is suing, so myself, as you mentioned, but Gianhoo, Road Driver, Jess Powell from Cracken, few other BCH developers. And I think that's it from the morning. Yeah.

So they essentially sue those people because supposedly there is a great collusion that happened to not respect what was written. Like it's very bizarre. It seems to me, but I'm not a lawyer, right? But it seems to me that they are interpreting the white paper as some legally binding documents. or something like that, and they are extracting some part of it,

and then they are, you know, saying that there is some grand conspiracy around indeed to subvert illegally the white paper between, you know, myself and those other people. Which is, yeah, we'll see how that goes, but I don't think it makes it all of sense. You get to take it seriously, though. It's always legal stuff. But from the aspect that is of interest to us, like the cryptocurrency and stuff like that, I don't think what a,

I don't know what a judge is going to think of it. And I'm not qualifying. Wasn't there also this issue? But from a crypto or a technical perspective, I don't also make sense. And part of the law should I remember was also around something around the ticker, where like, you know, there was some grand conspiracy of like stealing the Bitcoin.

Yeah, exactly. Yeah, yeah. That's what they're saying. And they are interpreting so part of the white paper saying that, you know, according to the white paper or something else should have happened according to their interpretation of the white paper. And it seems to me that they're considering it a legally binding document. I would say the interpretation of the white paper is wrong, but it doesn't even matter

because it's probably not a legally binding document. But, you know, like, I'm really not. I'm really not the best person to us that. You should ask a lawyer or, you know, a judge or someone like that. I'm not even an American citizen. I'm not a super funny opposite. All right. So, you know, let's go ahead and move on, you know, past the fork and like, you know,

into the future of Bitcoin Cash. So, you know, when I met you for the first time last December, one of the proposals you were talking to me about, which I thought was actually very fascinating and exciting was this. idea of Avalanche pre-consensus. And so really helping, and especially like, you know, you talked a lot about why it will help improve the security of zero-conference actions. So could you go ahead and tell us, one, why do you care so much about the security of

zero-con transactions? And then, two, what is Avalanche and how will that help? So to begin with, if we go back to the goal of the project, the goal of the project, the goal of the project is to create a form of digital cache that as best as possible property, like monetary property, right? And so very only on what was identified as a point we need to work on our confirmation time and fungibility and scaling, right? So we talked a bit about scaling before, but,

zero confis something else because right now in Bitcoin or any Bitcoin derivative, the block time is 10 minutes. And so it takes on average 10 minutes when you, between the time you make a transaction and the time this transaction. Right. And during that 10 minute window, there is a lot of opportunity to do a double spend. So we don't think that's ideal. And one of the solution people are working on to make some sort of the solution. beta on that front is a technology called Avalanche. So Avalanche is a technology where essentially when there is a double spend going on, Nods are going to run a protocol between themselves to decide which one is the correct one

and which one is not. And then the result of that algorithm can be used by miner to mine one or the other. And so that can give you a very fast, very fast information about which one. which transaction are going to be valid and are going to eventually be mine and which one are not. We want to dig more in some detail. It was very high level, but that's a general idea. This episode of Epicenter is brought 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 pre-configured with all the cloud services you need for your enterprise app. Their new development kit is the IFTTT for blockchains. Suppose you want to collect data from someone in a remote location via SMS and have that data packaged 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 Devkit can read, transform, and act on the data.

To learn more and to build your first application in less than 30 minutes, visit AKA.m.m.s And be sure to follow them on Twitter at MSFT blockchain. We'd like to thank Microsoft and Azure for their supportive epicenter. There was the paper that came out from, you know, this, you know, secret team called Team Rocket, but, you know, I mean, Gunsire kind of sort of become a little bit of the face of it. And so, you know, we definitely love to have him on. We just haven't, you know, gotten time to organize that around and talking a bit about avalanche. But, you know, so this avalanche that you're talking about, is it at all related to that paper?

Or is it, are these two different things or just like, you know, loosely inspired? What's the relationship between this Avalanche pre-consensus we're talking about here versus the Avalanche consensus protocol that was supposed in that paper? This is what is explained in the paper. We use it in a different way from what Eamon-Gon-Gon-Syser team wants to do. So what Eamon-Gunz-R-10 wants to do is something called Ava-Coyn. And this is a cryptocurrency that is going to be based on Avalanche-only, avalanche being the only consensus mechanism that this is going to use.

and this is not what we want to do with BCH. So what we want to do with BCH is a bit different. What we want to do with BCH is keep the blockchain like it is, not change anything on that front as per Avalanche, because there is a huge amount of software that rely on that, and it's actually a very strong consensus mechanism. It's very hard to rewrite history and so on. So it has very, very good properties.

But it has one property that is not very good. It's that it's slow to converge. And there is no way to make it fast enough for what we want. You want a transaction to be essentially final within a few seconds, right? And the more you reduce the block time, the faster you need to propagate the blocks and validate them at a given scale, right? Because you always have this constraint. that the time you need to propagate and validate the block

need to be small compared to the block time. So you already have a tension here between how fast you can validate, validate that a transaction is not going to have a double spend and how much scaling you want. And because we want both scaling and fast confirmation on BCH, we have a bit of a problem here. So the plan is to keep the blockchain as it is

with 10 minute block time. But in between the block, the node can run avalanche to decide essentially what's going to go in the next block. And if you do it that way, you still have all the good property of the blockchain, but you can improve that. You can improve that with the avalanche. But in order to do this avalanche pre-consensus, you need some notion of choosing who the nodes are. Right. And so usually you either do this through some sort of proof of work mechanism or through proof of stake. And so what's the, is the idea here to use proof of stake essentially to choose the nodes in this Appalach consensus?

So the proposal right now is still a bit up in the air. It seems that, you know, like some people want to do it based on proof of work. So you can have like, you know, the set of previous miners. that choose, you know, that run the avalanche consensus mechanism. You can also have people that have a certain amount of coins that do it. We haven't really settled on one of the odds or yet. And the reason is there is a lot of incentives to be considered, right? It's a very difficult problem and you don't want to screw up the incentive of the system.

So we haven't finalized a decision on that one. I would love if we can just explain that Avalanche a little, like take a step back and try to explain Avalanche for somebody who doesn't understand it. I mean, I think the zero confirmation challenge, I think that's kind of clear, right? So issue is basically I do, let's say I send some Bitcoin Cash to Sony. and the problem is I can just send another transaction sending it to myself. And now before it's in the next block, Sonny can't really rely on that payment too much. And I could go to a minor and say,

hey, listen, I send one Bitcoin to Sonny. He gives me, I don't know, some product for it. And then I go to the minor and say, hey, listen, this is a transaction made one Bitcoin to me. I give you 10% of it, but like put that in not Sunnis and I can defraud Sonny. right? So that's the kind of traditional fear there. Of course, historically, I mean, that's some risk, but it hasn't actually happened often. And traditionally, you had Bitcoin payment processes like BitPay. They would just accept your confirmation payments for, at least for a lot of things. Maybe it depends on the amount and stuff. But it always was considered to be insecure. Many Bitcoin developers thought this was reckless, shouldn't be done. But quite obviously, right? So I think the case for, or if you can make zero confirmation secure, like, that's fantastic.

But can he explain again, like, how does Avalanche accomplish this? First, I need to explain maybe why it's a difficult problem. And in traditional payment system, it's not a very difficult problem, right? So if you send two transactions to PayPal and one that's in money to Sony and one that sent money somewhere else, then PayPal is going to decide, you know, is one or the other is valid and reject the other, and this is the end of it, and they can do that very quickly.

But because Bitcoin is a decentralized system, then there is not one authority that can decide. Here is the one and here is the one that is the one that is right and the one that is wrong, right? And because it's distributed, then, you know, maybe some people are going to see the transaction that send the money to Sunny first, and maybe some people are going to see the transaction

where you send the money maybe to yourself first. Right? And those they are not going to agree which transaction is the real one. So what they are going to do is that each node is going to randomly choose a set of peers and query them. And they're going to ask them,

do you think the transaction to Sunny or the transaction to yourself is the correct one? And the node itself has its own opinion, depending on which one it has seen first. Right? And so what's going to happen is that depending on the result of that polling, the node is going to say, okay, is the result of that polling agrees with what I think is true? If the answer is no, then the node is going to change his mind and start again from scratch,

but with the answer position. And if the polling agree with what the node is thinking, then the node is going to increase its confidence that this is the correct rule. result. And you run several rounds of that. And once a node reach a certain level of confidence, once it's high enough, then they're not considering, okay, this is the final, this is the final decision on that matter. And so what happened is that you can prove that all the honest node on such network are going to converge toward the same result. And what you see in practice is that it happen very quickly, typically in about two seconds.

Okay, okay. So I'm getting this transaction from, or like, let's say you're the minor, you're getting the transaction for me and then you like you query the other notes and, and now you're getting another transaction spending the same output after that. Now you have both transactions, you query the other notes and you basically. So, so would it be like? Like whichever transaction you get first, that's kind of the one. You say that's the valid one unless others convince you that the other one was propagated.

Yes, yes, exactly. Yeah. Okay, okay. And then I guess the risk scenario here would be, of course, some minor, the next minor who minds a block, I mean, he could just put the other one in there anyway. because and then you this gets reverted nonetheless? Well, in that case, what minor are going to do is that this block is not going to match what the preconcesses agreed upon.

And what the proposal is a bit more subtle than that. The proposal is that you're going to outfond a block that has something that contradicts the decision that has been made, if that makes sense. it's a bit different because you don't have to mine exactly what the preconcensus has decided maybe you want to mine an empty block maybe you want to mine some transaction that you know nobody agreed upon yet but if there is something that people have agreed upon so if people have agreed that the transaction to sunny is the right one and the miner decide to put the transaction when you send the coin to yourself then the network is going to consider that this

minor is not an honest minor. And also minor, I'm not going to mine on top of this block. Okay, okay. So basically the different transactions get sent around and there starts to be some agreement that, okay, you know, this is a, this is sort of a transaction. We have some loose agreement on. And once that becomes pretty strong, if somebody else minds a block and they include the transaction that, you know, contradicts that, then, you know, start orphaning it.

And I guess that becomes sort of not like a clear binary thing, but more rough. So the general idea is that, yeah, you do what we call you park the block. So the block is not invalid per se in respect all the consensus rules, but you're not just going to activate it yet. And you can run around an avalanche on the block itself to know if also people are accepting the block or not. But what's going to happen is that most people are going to reject that block. and so it's going to be declared all the fun. So what do you start giving it like some sort of like negative bias

and like the different like if in its difficulty calculation maybe that's how you would do it or? So what you do is that every time you do a round of avalanche and that the result is conformant with what you expect, you increase your confidence. Right. And when the confidence goes above a certain threshold, then you consider that

this decision is finalized. I see. So this is like a, you know, essentially a very heavy change to the consensus algorithm. It's no longer like a minor change anymore. You're essentially changing the fork choice rules themselves on. Yes. What is interesting, though, is that it's actually what is described in the white paper. Like, yeah, the NACTA, what people refer as NACAMOTO consensus.

In the white paper, it is said that if a miner consider a block to be valid, they are going to vote for that block to be valid by trying to mine on top of it. If they consider a block to not be valid, they are going to vote against it by refusing to mine on top of it. But so far in Bitcoin, there was no mechanism for any miner to be able to agree on anything. there, right? They cannot communicate for the direction on that front and they cannot coordinate in any way. So what ended up happening is that

the miner, so far, have been voting yes, always. Every time you receive a block, if it's valid that has spared the consensus through, everybody was yes all the time. The idea is to change this so that, you know, a miner can vote

yes or no, but if you don't have some kind of synchronization mechanism, then voting no is very disincentivized. But by offering a way for minor remote vote no to coordinate, we can make that happen. Do you have like some sort of like paper or something in the process of like, you know, analyzing this? Because like I said, this just sounds like a very large change and it would be very interesting to read like something like proving the safety and liveliness of this system.

So the lifeness is not ensured. Right. That's actually kind of what I'm more worried about is the liveness where like, you know, you have a bunch of miners mining on one thing, but everyone else is rejecting it and it's just like, yeah. Well, but this is where the economic incentive of the system, you know, getting in place. If you mine something that nobody accepts, you are essentially burning electricity away with no revenue.

So you cannot be doing that for so long. I see. This is, this is where the last come out of the same. consensus is actually quite brilliant because you have a very strong economic incentive to following processes with everybody else. So you know the goal of this is to solve the zero con problem. Isn't the zero con problem also solved by a other one of Emmen's proposals Bitcoin NG like I feel like Bitcoin NG actually.

Okay. So two things on that from the fact that it's so zero call is actually not the primary, well, it's actually not what it does. It's the consequences of what it does, but what it does is maybe a bit deeper. What it does is allow nodes to synchronize their state on an ongoing basis instead of doing once every 10 minutes. And if you do that, you have better zero-conf, you know, insurance about zero-conf, but it's also easier to scale the system because now the reconciliation, that you have to do when you receive a new block is smaller, right?

You can prepare most of the block ahead of time because you know what it's going to look like. You also get stronger property when it comes to 51% attack. But NG have similar ideas. So NG, the way it works is that the minor that find the block essentially becomes a leader for the next 10 minutes. And when there is a double spend or something like that, the leader is going to be essentially,

the leader is going to be Visa or MasterCard or PayPal or whatever for 10 minutes. And it's going to say, okay, there is a double spend here. Here is what is the correct one. Here is what is the wrong one. So this is a system that works, though it has different tradeoff when it comes to Avalanche. And the first one is because you elect the leader, if the leader screw up or if the leader,

is dishonest or if the leader screw up or if the leader fails for some reason, then the old system need to wait for 10 minutes for a new block to be found and a new leader to be elected. Right. So it's not as reliable. And then you have an obvious attack is that if you know who the leader is, you can deduce the leader continuously, right? And have the system never deliver. Another concern about it is that the economic incentive are not.

very strong for the leader to behave properly because the economic incentive are based on fees and fees are low on BCH. So as a result, the incentive for the miner to behave properly are low. And so it was not an ideal solution, but it's a solution we looked into, but we think that Avalanche is a superior proposal. So are there any major downsides to this? Like, do, or maybe new attacks, new vectors of maybe centralization get opened up by adding

Avalanche? Yes and no. So Avalanche is, so just like the blockchain, actually, the blockchain is a consensus mechanism. A LaValc is another consensus mechanism that have a bit of a different trade-off. One of them is that even though most of

the time it converged towards the solutions very quickly, it's not guaranteed. It's not guaranteed by the protocol. So if you have a large amount of hostile actor in there, they can prevent avalanche for from finalizing any decision, especially by flip-flopping themselves, right? So with a large proportion of the node flip-flop constantly,

it's going to be very difficult for the network as a whole to come to a conclusion. Whereas this kind of flow doesn't exist on the blockchain, right? If a miner puts something in the blog, this is in the block, right? There is no situation where something is going to be unknown for forever. And so having a combination of the two essentially ensure that worst case scenario in 10 minutes you will know, but most of the time you will know in two seconds. You know, another tradeoff that you make is that when you have a blockchain, you have a very easily verifiable record of history.

So if I boost up a new node, I can connect to the blockchain, see what is the longest chain and synchronized to that. If I have another launch code of system, well, I wasn't there when Avalanche made the decision to begin with, so I don't quite know what was the decision at the time, so I need to

repole all the nodes, but that means that you need to have a whole story of transaction indexed so that new node can run that on those nodes or so note can change their mind later, right? Like you can collect to a new network and

is a bunch of malicious nut that after you take the wrong branch or whatever, there is a ton of problem that exists with Avalanche on that role, that don't exist with the blockchain. And so you got to see Avalanche as a mechanism that is much faster most of the time, but that is not very good if you are not there to participate at the moment. right? If you are there and you see everything going on, then it's very good. But if you, you know, catch up later on or if you are a mobile device, you know, that connect to the network once in a while to see what your coins are, like a mobile wallet, it's not very good either. So I think the combination of the two makes most sense.

It's like Avalanche is not this magical stuff that solve every single problem. You guys have this like really nice graphic roadmap on your, on the Bitcoin Cash. website and it's a very like nice roadmap and it kind of has these are three um pillars to it and so you know we've talked which i i remember being scalability usability and extensibility and so you know we've we've talked quite a bit about the scalability side of things as now and as well as like you know the usability with the uh you know improving zero conf and you know there's many other things on that roadmap we obviously don't have time to get to all of them today but i'd like to touch a little bit now on that third pillar, which is the extensibility.

And so what is the goal for, what does this mean in Bitcoin Cash? What does this extensibility mean? And, you know, could you tell us a little bit about this new op code that I've been hearing buzz or buzz about op check data say and like how that contributes to extensibility? Yeah, so extensibility, the general idea of extensibility is provide way for people's to do more, like to implement new functionality or whatever. And yeah, one of the big steps that have been made recently is object datac. So object datac is an upcode in script that is going to check a signature on arbitrary data.

So right now all the all the operation that check a signature, check a signature based on the transaction itself. So that's good for raw payments. You can, you know, sign the transaction and someone can verify that you are the actor creator of the transaction. But if you can sign any piece of data, you can implement a bunch of new features. So one very interesting one is what is called zero-con forfeit. So this is a technology where you can make a script. And the script is such as, if I can produce several signatures for the same public key, that means that someone tried to spend the same coin twice.

Right. And so you can attach a mountain to that and you can attach an amount to that. And it's essentially an insurance against fraud. Like I can essentially put some coin in some smart contract with you. And this is, okay, this is a guarantee that I'm not going to double spend you. And if I ever try to double spend you, then you can claim those coins. right so that's that's one idea that people have with it and other idea is oracles

so the blockchain you can write contract in the blockchain based on any information that exists in the blockchain but you always run into some problem when you want to base the contract based on something that is not in the blockchain right so maybe we want to bet about who is going to be the next

president of the United States like in I think two years 2020 I think the next election it is in the US. Anyway, we can bet on that, for instance. But it turns out that the president is not in the blockchain, right? So we don't quite know how to write a smart contract between the two of us to make that

happen. And what you can do is actually you can ask an oracle. So an Oracle is someone that we both trust. Or maybe we can ask a set of Oracle instead of one oracle if we want to be more, you you know, have less trust into one specific entity. And this Oracle is going to authenticate some results, some information from the real world, and sign that with his public key,

and then we can use that within our contracts. And so we can make all kinds of, like, the possibility are truly endless with Oracle. We can make any kind of contract. As long as we have some Oracle that is willing to certify some information from the word, that we bustress, we can do anything. We can say, okay, if the price of Bitcoin next week is, you know, more than that,

then do X, right? And then we can have an Oracle that's saying sign the price of Bitcoin, you know, every hour or every day or whatever, and we can use that to build our contract. Really, yeah, the possibility of very, very, very wide and people are doing all kind of stuff with that. There's a new op code that's being added into Bitcoin called Check Signature from Stack. And so that's very similar. And they're working on a lot of stuff around things like, you know, scriptless scripts

and like a lot of these things that will basically add like complete smart contracting functionality to Bitcoin. Is this something that you guys are also looking at for Bitcoin Cash or kind of is anything, or I'm sure like, you know, is there anything that you guys are actively developing or are you kind of just letting, you know, the Bitcoin core team, like, develop this and maybe if it works, like port it over to Bitcoin Cash? So far, we have been developing those stuff. It's quite funny that you mentioned the Czech Signature Farm Stack, or I'm not sure what

the upcut his name, but something like that. Because we had several iterations on Czech Datasik, and the final iteration ended up being exceedingly similar to Czech Signature from Stack. But I assume that they must have went through a similar process. and you know I've discovered a similar issue because we kind of realized that at the end of the process that we have we have done something that is you know it's really similar to what they were doing. But for those other up codes and other things, well, you know, we'll see I guess it depends on you know case by case basis. One thing that is missing on BCH that I would like to see happen is script versioning. So, script versioning is something that's been

introduced by Segwit, that people have not talked about that much because they were focused on the capacity increase and variability fix for Lightning Network and not, that this is what everybody was talking about. But what I think is one of the interesting feature of Segwit is script versioning. And script versioning

is essentially, you know, what the name is, right? There is a version number that is attached to Segwit script. And that allows you to add new version number that do new stuff over time. So that's a very, that's a very nice to, a very nice way to extend the scripting capability of Bitcoin. And this is something I would like to see up on BCH, but right

now it's not the case. So speaking of Sedwick and Lightning and extensibility, what is like, you know, one of the big questions. So, you know, we kind of talked in the last episode about, you know, partially Bitcoin Cash was a rejection of the soft fork Segwit. But, but, you know, But, you know, why hasn't said Bitcoin Cash provided any alternative solution yet to transaction value billion? There are, there were proposals. I know there's one called like flexible transactions and stuff. But like, you know, is there like, I'm sure like, you know, you don't think that the lightning

network is useful, right? And like, so, no, Bitcoin Cash, like, you know, I understand that you guys want these larger block sizes. But at some point, you also want to enable things like second layer solutions and stuff. So where is this, where is this on the roadmap of like putting the feet, putting the pieces there to enable lightning on Bitcoin cash? Yeah. So that would definitely fall into the the extensibility, you know, bucket. I'm all for personally, I'm all for fixing reliability and allowing people to

play with second layer solution. What I'm against in the case of BBC is, you know, betting everything at the second layer. and essentially preventing people to use the first layer. So that I'm not very fan of. But if people want to build second layer on VCH, then I'm more than happy to have them if they need something. So in our case specifically, we've fixed some vector of liability that are enough to do payment channel and stuff like that.

So if people want to do payment channel, they can do that. Actually, someone used that to implement Atomic Swap on BCH, not so long ago, MacLedenberg. But personally, I would like to see my ability fixed completely, but I know that a lot of people in the BCH community disagree with that. So I'm not quite sure what's going to happen on that front. I would love to spend like a few minutes before we wrap up just on, you know, what is your high level vision for Bitcoin Cash in the long run? So we talked a little bit about, you know, mentioned Oracle and smart contracts and

layer two. Do you think, I mean, is your vision that Bitcoin Cash kind of becomes like the blockchain where a lot of these things happen? Or do you think it makes sense that there is, you know, let's say a Bitcoin Cash blockchain, which is focused on electronic cash and payment? and then there's something like Ethereum, which is focused on smart contracts, and then there will be some other blockchain focused on, I don't know, gaming.

Do you think ideally? Yeah, yeah, so I get it. My vision personally is that during the whole human history, we had to make a choice between technology for money that have good are monoe property, meaning like they are very scarce and very hard to counterfeit and so on. And also technology for money that didn't add those arm money properties, but that were much more convenient as a medium of exchange.

And so the way, like the thing that I see being truly revolutionary in what we're doing is that maybe for the first time in history over the past 10 years, we had technology that can do both. Very good medium of exchange and very hard money. property. So for me, that's what is the most important. And everything else on top of that is nice to have, but it's not the groundbreaking, you know, it's not the groundbreaking aspect of it. And I don't quite believe in the fact that we are going to have just one blockchain to root them all. And the reason is in engineering, you almost always need to make tradeoffs, right? So let's take, let's take BCH on

Ethereum, for instance. BCH has a UTXO model similar to Bitcoin, which means that you can evaluate the script for every single transaction when you spend in isolation, right? You just need the UTXO and the transaction that's spent it, and you can do the computation. So the nice aspect of it is that it's much more scalable than what Ethereum is doing,

because in Ethereum can make transactions that rely on some global state, in the blockchain and query that state or even modify it. And that allowed them to do all kind of very cool smart contract, but that is much more difficult to scale. And so there is clearly a tradeoff here, and we are making the tradeoff in the direction to be easier to scale. And that means that we don't have smart contract capability

that are as rich as Ethereum. And Ethereum does the opposite. You know, they have very rich smart contract capabilities, but as a result they are much more difficult to scale. And because those trade-off exists, unless there is some technology at some point that, you know, essentially remove that trade-up because we find a new trick,

you know, there are probably going to be a handful of blockchain that make different trade-off that people are interested in for different reasons. So, yeah. I see a technology like BCH and a TVG like Ethereum, you know, both becoming big and both, you know, having their own stuff that they do well. I don't, yeah. I don't think this idea of one blockchain to root them all is really going to materialize.

Though right now we also have a ton of different coins. I'm not sure this is very sustainable, but I don't think the opposite vision that one coin is going to root them all makes a lot of sense. Cool. Then well, Amory, thanks so much for joining us. Both of these episodes, I think there was a super thorough exploration of Bitcoin Cash, and it's really very impressive, like all of the different things you guys are working on. And I think what stands out to me most of all, it's just, you know, Bitcoin and Bitcoin Cash really, like, diverged in a significant way, right? This is like very different vision, different technology, different priorities, different

roadmaps and these are two very independent projects at this point. You know, with each there are different pros and cons. But like, it's not just a sort of, you know, simple fork running of Bitcoin. So thanks so much for exploring that. It's so deeply with us. Well, thank you for having me. 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.