BCH Network Discussion on Smart Bitcoin Cash: An EVM Compatible sidechain for Bitcoin Cash

BCH Network Discussion May 1 2021

Smart Bitcoin Cash: An EVM Compatible sidechain for Bitcoin Cash

Watch on YouTube

Watch on Odysee

This latest discussion was recorded on May 1st with attendees:

John Moriarty

Josh Ellithorpe

Rosco Kalis

Mark Lamb

Kui Wang

Cindy Wang

John Moriarty: Hello and welcome to the May 1st, 2021 Bitcoin Cash Network Discussion.Today’s topic is SmartBCH, and Ethereum Virtual Machine or EVM Compatible sidechain for Bitcoin Cash. While SmartBCH doesn’t require Network Consensus to be activated, we’d still like to take this opportunity to discuss the proposal and its implications.

 Joining me today are Wang Kui, lead developer at SmartBCH, Josh Ellithorpe, developer for BCHD and software engineer at CoinBase, Rosco Kalis, software engineer at General Protocols and creator of CashScript and Trufflesuite tooling. Mark Lamb, CEO at CoinFlex, and Cindy Wang of Satoshi’s Angels.

 Thank you all very much for joining me for this discussion, I appreciate you taking the time.

Josh Ellithorpe: Thanks for having us.

John Moriarty: So usually we start with the problem statement or use case of the proposal we’re covering, and I think that will translate pretty well over to SmartBCH, so Mr. Wang could I ask you to start tell us what, and without even going into what SmartBCH is, could you tell us what the goal for SmartBCH is as far as use cases are concerned? What is the use and goal, as far as uses are concerned.

Kui Wang: OK. SmartBCH as the name proposes, is a tool to make the porting process of existing DeFi applications to the BCH ecosystem much easier. You know that there is a lot of code and a lot of applications which have already been developed on Ethereum. And they have already been put into other chains like BSC and HECO and even TRON with little effort, because they all support something like EVM and they support web3 RPC.

So I believe that EVM and the web3 ecosystem is so rich, why can’t we borrow its strength to enrich what we can do on the BCH ecosystem. Since, you know, this is open source. The crypto currency open source communities can borrow ideas from each other. So I think it is quite OK to borrow this idea from Ethereum to build some specific applications on BCH.

 And another thing is that, you know they guys at Ethereum they believe that Ethereum must be run on small computers which are not so strong. And they actually limit the gas limit, and they go to sharding for high throughput instead of bigger blocks. I think that there may be some need, I just guess, I guess there may be some people who need a bigger block version of EVM compatible applications. That is, we want to keep as much traffic as possible on the same chain instead of putting them to rollups or another shard to have better interoperation between DeFi smart contracts. So I think maybe we can meet some of the market’s needs. Which those needs are not fulfilled by Ethereum itself. So maybe we can serve such applications and such demands. This is a two sided problem, one is BCH and EVM, and maybe developers on EVM need a bigger block version of EVM.

John Moriarty: Very good, thanks for taking the time to explain that. I’d like to open it up to everyone, I mean maybe there isn’t much more to add, but it there is, if anyone would like to comment specifically on the use cases or problems that things like SmartBCH, or specifically smartBCH allows for.

Josh Ellithorpe: So I look at SmartBCH as just a solution for smart contract developers that don’t want super high fees, that don’t want to get into the more centralized environments, that are able to give them a simulated environment that is lower-fee. And so I look at things like Binance Smart Chain. And other people are testing their applications on the other networks because they don’t wanna have to pay high Ethereum fees. And they are very similar infrastructure. However, the liquidity on those coins is only for certain chains, you know, Binance Smart Chain is not traded on all exchanges, it doesn’t have nearly the liquidity that a coin like BCH has.

 So all of a sudden you have a very easy to acquire, high liquidity coin that also has these EVM capabilities, and we can be able to do that with very low fees. And then by backing with Proof of Work and being able to elect the validator that way, you that the people that are being elected as validators actually have the hardware to run a bigger block version of Ethereum that can do the throughput promises that SmartBCH is saying that it can do. This could be extremely useful. And I see it as a good alternative as long as the tooling is very similar.

John Moriarty: Thanks very much, would anyone like to add? Alright, then maybe we’ll move on to something that’s pretty closely related is the properties of a good solution or implementation. This use case or problem statement of, you know, maybe people want to do things like Ethereum but with lower fees. Or people wanting to use the Bitcoin Cash ecosystem to do smrt contract type things. 

 What, and I’ll direct this towards Kui first, if you would. What do you think makes a good implementation of something like that, versus a bad one. And you can talk about what decisions have you made when making Smart BCH that you think will make it a success?

Wang Kui: OK, so actually I am a technical guy, to make a chain successful, there are a lot of things, more than technique. You know you must have a better community and better companies to support it. Better from the technical view, I’ve always been working on one thing, that is to enlarge the overall throughput through hardware-friendly design. You know, that actually what I added for my doctorate degree, is a very low-level computer architecture, and I know very low-level details of the computers. How the CPU works, how the DRAM, and how the SSD work. So I always look at the states from a low level. And I saw that there is a lot of opportunity to enlarge the throughputs of the chains by optimising the software to exploit more parallelism from the hardware. This is a totally different approach I believe is not tried by other designers. So SmartBCH is not a forked version of Ethereum. It is designed from the ground up. We borrowed some code from other projects but the overall architecture is brand new. And so we believe we can enlarge the throughput, which means we can keep a low gas price, even if there is a lot of traffic. If we just copy the code from Go-ethereum or parity and bridge it to BCH as a sidechain then you still limit when the traffic goes heavy and is crowded, the gas fee is sure to rise because the overall gas limit is so low. So what we do is to design a new architecture to run EVM and Web3 which can utilize the hardware so good that they can keep the gas price low. Even if the transaction is very busy, is very crowded. We can handle it. That is my understanding about the big-block. Big-block can make the block bigger in some brute force way, not some sharding or tricky way. We just optimize the hardware and the software for a co-optimization and make the block bigger.

Mark Lamb: I think it might be worth comparing scaling approaches, and sort of what each project is thinking about doing, because I think there’s Ethereum, there’s BSC, Solana, and then something like Smart BCH, and then there’s maybe everything else that’s sort of similar to ETH.

 And when you think about Ethereum, they’re like the nightclub that have realized they’re super popular and now wants to raise their price. Because what they’re doing with EIP 1559, which, for those not familiar, basically that’s gonna take a lot of the gas that’s spent on transaction fees and burnt it, instead of pay it to miners. This is really an approach of like, “hey we’ve been successful, rather than focus on making it cheaper for people, why don’t we use these high fees that people have been paying and pump ETH as a token.” Which is great, I mean, it’s great for the tokenomics of ETH, but it’s bad for the ETH ecosystem, the ETH user base.

 And if you think about BSC, it’s going the route of SmartBCH, but without, you know, it’s trying to have improvements to the scalability and low fees, but without any fundamental, architectural, low level, machine level improvements. And so that’s why BSC fees are now starting to hit the dollar plus range. Which really, a dollar transaction fee is higher than, you know, imagine paying for a beer and then, it’s a dollar, you know. Right?

 For many, many types of DeFi applications, even they break down at this kind of range. 

 And then you have approaches like Solana, which basically take the approach of, “we’re gonna completely do away with the promise of decentralization” and both BSC and Solana are very limited set of validators, that are limited in number and have to amass it in scale because the latency demands are so high. Whereas with SmartBCH it’s basically a kill-your-kings approach. There is no proof-of-stake, always in power type of dynamic. In SmartBCH if you are not mining on the BCH network you will lose your ability to run a validator.

 So it’s proof-of-work in every sense of the, constantly trying to improve and increase the security you’re providing to the BCH mainchain. And that’s also what it ties back to, the BCH mainchain, which I think is very important.

 But I think these differences in scalability are very interesting from the perspective of someone who’s trying to build on SmartBCH, and making a new ecosystem to build on. Because obviously ETH is way too expensive. And from that perspective SmartBCH has the longest horizon approach because they’re not taking the short-sighted Ethereum approach. Which is probably going to be good for the ETH price, but bad for the overall adoption and probably will alienate people. And they’re not taking the super centralized approaches. So the centralized approaches will harm adoption with exchanges. You know, if you’re an exchange that isn’t Binance. It’s a difficult proposition to just integrate BSC. And just sort of tip the hat to your competition.

Josh Ellithorpe: Yeah the way that validators are selected is absolutely crucial. Wn we look at the long term economics of the projects. Which is why I was actually really happy about having this sidechain approach and being able to vote on validators. And that way people in the community technically might be able to become a validator, and miners definitely will. And sometimes miners will want certain people to be running infrastructure, and they can choose to if they have those kind of dynamics with people.

 But anybody can kind of come in and start mining, and start voting for new validators. And it’s not a “whoever gets there first before the price pumps owns the network”, or ownership by exchange. Which is also a really real fear. If you have your validator stacked by how much someone can stake, then a major exchange that starts staking for their customers all of a sudden has a really disproportionate amount of the staking pool. And can make basically whatever decisions they want. And it can lead to cartel-like behavior between the exchanges and/or other operators. And the mining situation really helps with that long term.

 Now, I’m actually kind of curious, Kui, the improvements that you made to SmartBCH, are these things that are portable to Ethereum today, or are there fundamental, low-level differences that may be slightly different for Ethereum developers, that are why you decided to take this as a completely new project, rather than kind of work with some of the other EVM projects.

Kui Wang: OK. The first question is that the overall architecture is very different from Ethereum, I believe some of the libraries can be ported in to Ethereum but *interference* even though the Yellow Paper defined a lot of the low-level semantics of the Ethereum. And if Ethereum wants to use some of our low-level libraries they must change the semantics of the Yellow Paper. I think that it can be done but it is very hard, very hard.

 So I don’t think in the near future they will choose to use SmartBCH’s approach.

 We are quite open because the Moeing libraries are open source, and we welcome anyone who wants to use them, to use them. But I don’t think Ethereum will use them in the near future.

 Would you please repeat your second question?

Josh Ellithorpe: You covered it pretty well. I think that we can have John kind of move on, it was just kind of elaboration on the first one, I think.

John Moriarty: Sure, so… Oh would someone like to add something?

Rosco Kalis: Yeah. I think the points that Mark and also Josh made about the miners actually choosing or voting on the validators is a very good one and makes it very different from something like BSC. But I’m wondering how you think, Kui, how that compares to, for example, the merged mining that RSK employs where actually the miners of BTC are also validating transactions on RSK through merge mining?

Kui Wang: OK, so the network is still a little bit unstable, I repeat your question. You just want to know what’s the difference from the other merge mining projects such as RSK or Vcash or something like that right?

Rosco Kalis: Yes so what the consequences would be of, like with SmartBCH, the miners choose validators and then those validators use proof of stake versus something like RSK where the miners themselves use merge mining.

Kui Wang: Yes so I think the other merge mining projects actually they are still POW And they just… When you try to use hash compute to produce BTC block, you are also trying to produce a RSK block. So this is a very tight process. And in our approach I hated to call it merge mining, it’s just the election based on coinbase transactions. So in the block to block level you can count the consensus algorithm as a pure POS algorithm. So in a way uses a tendermint library. Which means we can have per block finalization and a very fast block interval. So you can see it as something like EOS you have epochs and you elect the validators of the supernodes in one epoch and they take on their duty for another epoch. And in the epoch the POW as no effect on the validating side, it just decides the next epoch. So this is a different approach. We chose this approach in that.. Actually I think POW is not a good consensus algorithm for the block to block basis. It is just good for the long run, because in the long run it is open and it is fair and it can welcome new joiners. We think in the long run POW has an advantage. But in the short run POS has it’s advantage. So we decided on this hybrid scheme for the consensus algorithm.

Rosco Kalis: Well that’s interesting, so is it accurate to say that you’re basically on the short term for every epoch you're sacrificing some decentralisation for more performance? And then in the long run you still have the decentralization of POW. 

Kui Wang: Yes.

Rosco Kalis: Interesting, thank you.

John Moriarty: Very good. So before we move on I would just like to ask, given what’s already been said, are there any other specific aspects of this implementation or generally of an implementation of something like this that we should know that are valuable. I guess maybe the question is what would a bad implementation of this look like maybe? And if there’s nothing else then we could move on, but I just want to make sure before we keep going.

Josh Ellithorpe: I wanna call out one other really nice advantage of this, is in Ethereum, because of the way gas works and the way the block interval works, it doesn’t really perform very well as cash. It doesn’t really provide any kind of instantaneous response, there’s failure modes, there’s high fees. And there isn’t a good protection of the cash experience within an Ethereum environment. Now, that’s not their goal of their project, they wanna do financial services and those types of things. But that’s where SmartBCH really shines. It’s that even if SmartBCH becomes tremendously popular, and even if the fees started to go up, at the end of the day the cash use case is completely unaffected. The cash use case of BCH being able to be used all over the world with cheap fees - completely unaffected.

 And so, that’s the type of projects that I really like to welcome. Is there really isn’t a disaster scenario for the things that I think the community deems is so important. Which is making sure that peer-to-peer cash for the world is something that is achievable. And being able to piggyback on the same token that is doing peer-to-peer cash, and being able to use it in a DeFi environment is something that Ethereum can’t offer. Technically can’t offer. And is something that we might be able to have very real in the next couple of months because of SmartBCH.

Mark Lamb: I think it’s really valuable, like, there’s huge advantages to the UTXO approach of Bitcoin and Bitcoin Cash. Namely it’s just way simpler and it does have huge advantages for just very simple payments. And there’s huge advantages, obviously, to the ETH approach and the DeFi approach and having these on separate networks, separate blockchains, but with the same token and the same proof of work underpinning it all.

John Moriarty: Very good. So there we did cover not just the properties of a good solution but also a lot of how that applies to smart BCH. Let’s move on then to recognition of costs. Now, specifically because this doesn’t require consensus changes. Ideally the costs for some people will be lower but I’m sure that people will have some thoughts on other potential costs implementing this even though it requires, you know, no permission.

 Kui, is this something that you’ve thought of? Are there any potential downsides you see to the implementation of SmartBCH for the rest of the Bitcoin Cash ecosystem.

Kui Wang: Currently I guess there is no downside because we only take a very tiny output from the coinbase transaction, it’s about less that one hundred bytes. So it does not take anything at all as a technical view. Maybe some economics, there will be some, maybe some economic issues because if a master transfers a lot of BCH from the Mainnet to the the SmartBCH sidechain, through a bridge, in a way, we have a lot of things to worry about. The bridge. Is it secure? Is it trusted? Can we trust it? Will it take the coins away? A lot of things to worry about. If there are some accidents in the cross chain bridge…

 Maybe the most important thing for us on BCH is that we must design the cross chain bridge secure enough, and decentralised enough. You know that the best thing if the code is not perfect on smartBCH then the largest damage is the damage, itself, right? But if we damage the coin transferred from the Mainnet to SmartBCH that will be a big issue.

 So, in the next month I will put a lot of effort and communication into the cross chain bridge design. And the talk with mining pools

So how can we organize the cross chain bridge? Actually I think in the near future the traffic on the SmartBCH would not be as high as the Mainnet. I think it’s the main risk but we are risking in the long run. So a way to not worry about the volume of the SmartBCH in the near future. Maybe in the far future. Ok I’m finished.

Josh Ellithorpe: The cross-chain bridge is something that is absolutely important in how that’s developed. The one thing I have noticed in talking to other developers, though, is that this is something that everybody really kind of agrees on in the smart contract space within BCH, is trying to figure out a nice way to be able do these bridges and atomic swaps. And being able to have these kinds of features in BCH to allow this type of functionality. So I think we have a lot...

John Moriarty: Actually Josh if I may interrupt you there, could I ask you to just give us a really quick overview of what we’re talking about; this bridge. Because the idea, you know, so far I’m guessing a lot of people think, OK there’s this tool that should give us.. it's a “side chain” and it should give us smart contracts. So what do we actually need to do?

Josh Ellithorpe: So you need some way to send BCH somewhere, and guarantee that that BCH can’t move and is frozen effectively. And it needs to magically be unfrozen in this SmartBCH land so that I can use it there. And then I need some way to get from Smart BCH land and unlock coins on the other side on Mainnet, and get them back as regular BCH in a way that doesn’t require a centralized 3rd party to help with the facilitation of that trade.

 Now, there are a lot of different techniques to do that and in the beginning it might be a trusted relationship with a set of people and you kind of choose who you’re going to work with. But within the community there’s a lot of support for figuring out how we can use smart contracts to implement these kind of inter-chain locks. And I think for the most part developers are in agreement that a solution for that problem is something that is important. Now what the details of that are, I don’t know of any specific specs or, you know, chips or anything like that talk about that integration. But what I’m hoping is that that conversation starts to happen in a real way now. 

 Now that we have a testnet, now that we seeing that this functionality is all working, I think that there can be a closer relationship between the SmartBCH project and some of the people working within the scripting environment to see what we really need to do this in a trustless way. Where I don’t have to trust anyone and it just works. And we don’t have to worry about the decentralized aspect of what we’re doing.

John Moriarty: Thank you for giving us that overview. So I guess its worth pointing out, and asking for anyone to correct me if this is the case. So Smart Bitcoin Cash obviously has these capabilities, the same as Ethereum, but because we also need to “lock up” the Bitcoin Cash so that it doesn’t move until the other chain allows it to move again. For that to happen Bitcoin Cash itself may need new features or maybe we just need to figure something out given our current smart contract capabilities. But that is the problem you’re talking about there?

Josh Eliithorpe: That is exactly the problem, is that we may be able to do it with existing script. It may be possible. I’m not exactly the scripting wizard, I think Rosco and some of these other people on the panel have a better understanding of where we’re at for functionality like that.

 But it's something that we have discussed and with, I think that solutions are something that can happen, even if they’re not 100% possible today. But we’ll know soon as people start looking into this more closely. 

Mark Lamb: And I’ll just give the tokenimics or pumpamentals reason for why this is important. SmartBCH is going to have a lot of the ecosystem built out that has staking opportunities for people with BCH to come and put their BCH to work in lending protocols and decentralized trading protocols and they’ll be able to start earning yield on their BCH. When they’re earning that yield, it’ll be better if they don’t have to trust a centralized authority.

 And the second reason is SmartBCH, half of the fees will go to the node operators, the miners. And half of the fees will actually go to burning BCH. So it’s important that those burns get reflected on the mainchain as well. Because at scale, this could result in, I mean, this could even result in BCH becoming a deflationary currency. So right now BCH has still a very low inflation rate, it's known, it's only ever going to be 21 million. But this could result in lots of BCH being destroyed every year from gas fees. So it’s important that those burns be bi-directional and happen on both chains.

Kui Wang: Yes, the burning process is very important. We must ensure the cross chain gateway keepers must burn the same amount on the Mainnet to reflect the gas fee burning on the SmartBCH.

Josh Ellithorpe: Can you go into, a little bit, more why you think the burn is necessary? I know there are some reasons because I know that there are some people on kinda both sides of the argument of whether or not a burn is a good idea. I’m just curious as to your thoughts about it.

Kui Wang: Burning is a very common thing in the blockchain. And you know that not a lot of platform costs. Such as BNB and HNT, they always burn some platform tokens when they get some income. Since BCH’s chain bridge can benefit all the BCH holders, so I think what it earned should pay back to all the BCH holders. And burning is such a tool which can benefit every BCH holder. So it is simple and it can work on many smart chains.

 So we can borrow this idea, burning is not a new idea. It has worked well on many platform coins and will work fine on Ethereum. So I think borrowing it is necessary for Smart BCH.

Josh Ellithorpe: Hm, thank you.

Rosco Kalis: So one thing you mentioned as well was that there was a cost of proof of work voting added to the coinbase transaction op returns, right?

Kui Wang: Yeah.

Rosco Kalis: Yeah. So you’ve mentioned that it’s a small cost, because the required OP return is under 100 bytes. So when I heard that I thought, well, it does use up some of the available op return space. So let’s say there are other protocols that also require coinbase transactions to also use some op return statements, then that likely wouldn’t be possible because they’re already used up by SmartBCH. Is there something, like, do you have any ideas about that?

Kui Wang: Sorry, my network was not working, can you repeat your last sentence?

Rosco Kalis: Yeah. So the idea is that if SmartBCH is using op return statements in the coinbase transaction, then no other protocol can also use op return statements in the coinbase transaction for their protocol. So you’re basically using that up.

Kui Wang: No, no, this is not a problem because there will be multiple outputs to the earning transaction including the coinbase transaction. And each transaction we can have an op return opcode, right? Because after this fork we will allow multiple outputs on op return. So I do not think that it will be a problem.

Rosco Kalis: Nice.

Josh Ellithorpe: So it does take some of the data carrier size, so we’re allowing for multiple OP returns but at 100 bytes, that leaves like 120 bytes or so left for other protocols. Which is enough for one that uses the same amount of space as SmartBCH, today. I have seen a lot of conversations with devs, we wanted to be careful for the upgrade and just open up the ability to have multiple opreturns but not change the data carrier size. But there have already been conversations about the data carrier size. 

 So I agree with the concern. I’m more of the boat where I don’t want massive data carrier size, like OP returns, I’m not thinking of megabytes. But I think a kilobyte sized opreturn has a lot of advantages.

 And I think that there’s a conversation to be had as more protocols are using op return, as to what we want to do. We can even increase op return data carrier size only for coinbase transactions, if that’s something that would need to happen. So there’s some flexibility for how that can roll out. But it’s a great point, cause I didn’t even think about that limitation until you brought it up.

Rosco Kalis: And I think the point that Kui just brought up, the fact that it doesn’t have to be the OP return for the first transaction inside the coinbase...

Kui Wang: No, no, not for the first one. Any output is OK.

Rosco Kalis: And so what I am wondering then is… so the coinbase transaction is one single transaction. So if you’re saying that it can be a different transaction within the same block, how is that enforced? Cause, how do you know that one of the...do you have to have another transaction to the same address as the miner’s output? Or how do you see that?

Kui Wang: I just *interference* implementation of the staking logic, it just scans every BCH block and finds out the coinbase transactions. It only scans the coinbase transaction, and say, if this transaction bought for a validator, it does not take other transactions into account.

Rosco Kalis: Alright, I thought you said earlier that it would. So then the point stands. And I think what Josh mentioned is very accurate, that there’s a lot of work being done already to support multiple op returns, or to increase the data carrier size, so that should mitigate the concern.

Josh Ellithorpe: Yeah, cause right now SLP requires op return index zero, and SLP some of those transactions take up the majority of the op return space. And so in order for us to even support additional protocols other than SLP and be able to integrate SLP more in the scripting stack the data carrier size would need to be adjusted for that. Now I don’t know if that’s what the community wants but if they did they would need to adjust the data carrier size.

John Moriarty: Very good. Well then, that might be a good point to move on unless someone else has something else to add there. 

 Alright so let’s then talk a little bit about who the stakeholders are in the activation of SmartBCH. And so here comes a bit of a question of, “who is affected by this?” and this might be more of an opportunity to point out who is not affected by this than really who, or at least an equally good opportunity to point out who is not affected by it as it is an opportunity to point out who is affected by it.

 So Kui could you tell us who is it that has to think about SmartBCH once it comes out? Who are the people who are going to have to update, or need to update or need to learn something new or change their software? Who will need to do something when SmartBCH is working?

Kui Wang: OK, so I think the most affected party is the mining pools. Because they have the burden to elect the proper nodes for SmartBCH and they have the duty and they have more opportunity to earn the gas fee on SmartBCH. So I think that the mining pools must figure out who’s validators they want to support. Or if they want to run a validator themselves. And they must change their software a little bit to include the specific electing output to their coinbase transaction.

 And I think the BCH holder may be affected by SmartBCH because they have another network to put coins on. You know that they have lend, aave, other application clones will be ported to BCH. And you can put your coins in a smart contract and earn some interest from it. That is very different from when you must just hold your coins on Mainnet. And with SmartBCH you can put your coins in a smart contract and something from it. So if you are not interested in such an application, I think a lot of people are afraid of smart contracts, I know a lot of my friends are afraid because smart contracts may be buggy. And even the contract from some expert, they still have some problems. They say your assets may be stolen by some scientist on the chain. 

 So, a lot of people are afraid of smart contracts. I know. For those people that don’t understand them, because I have a lot of friends who are afraid of smart contracts. I think that those people can perfectly keep their coins on the Mainnet and wait for them to mature, and for time proven solutions on the SmartBCH to emerge. They can choose a different way to improve their assets. I think it will be a long time before the applications get to mature and are proven on SmartBCH.

 So in the near future I think maybe only the mining pools are affected by SmartBCH.

John Moriarty: Mm-hmm. Very good, would anyone else like to comment on that?

Cindy Wang: Actually, I have a question for Mark.

Mark Lamb: Yup?

Cindy Wang: So, lady first? OK. 

 Because I see that Roger Ver mentioned many times about that new kind of stablecoin from Coinflex that can kind of yield interest while it also has stable USD returned to you. I wonder Mark, are you considering to transmit that kind of stablecoin onto SmartBCH?

Mark Lamb: Yeah, so, speaking selfishly for a bit, one of the reasons why Coinflex is because USDC really because it got its lead over the other coins by being early into the Ethereum DeFi ecosystem. And Flex USD has been a really cool stablecoin because people are earning interest on it.

 So basically for anyone who doesn’t know FlexUSD is a stablecoin, it’s always worth one dollar. But it also has a rebase function every 8 hours where it pays out interest. And so one of the reasons why we as a company are really motivated to help SmartBCH is because we want FlexUSD to the main stablecoin or dominant stablecoin on SmartBCH. And then everyone who’s using for DeFi will have a higher rate of return because on top of whatever they’re doing in SmartBCH’s DeFi land, they’ll also be making returns from Flex USD.

 So we think it’s great for DeFi users of SmartBCH, and its also great for us because we get to grow the supply of our stablecoin. That’s one of the reasons why CoinFLEX is really motivated. FlexUSD is going to be on SmartBCH, day one. And it’ll be very easy to move it between ETH and SmartBCH and SLP on the BCH Mainnet. So we’ll make that really simple, really really easy to do on limited size and very low fees. Yeah, we want projects to be using FlexUSD as a stablecoin. Purely for the motivation of, if they’re using it as a stablecoin their users will make more money. 

 Thanks for your question.

Rosco Kalis: So Kui one thing you mentioned about the miners being most affected by the change, earlier. So, to hop on to this, is there some sort of minimum or maximum set of validators that has to be chosen?

Kui Wang: Oh, no.

Rosco Kalis: What happens if there’s not enough miners voting for validators?

Kui Wang: OK, the minimum validator and the maximum validator count is the critical parameter and we definitely will discuss with the community in the next month. And I know the mining pool people so personally have discussed with them about SmartBCH, and they all promise to be involved in the validatory election. So I don't think we are in such a scenario where no one wants to elect the SmartBCH validator.

 And you know that the major BCH mining pools in China, they are not so involved in the BCH development in other issues. They do not know a lot of people in the ecosystem. So I would like to be a bridge to introduce anyone who wants to contribute to the SmartBCH and if you want to know how to be a validator but you have no channel to discuss it with the mining pools, I can be the bridge to introduce you to the mining pools and make sure the mining pools will vote for you.

Josh Ellithorpe: You can consider me in on that. I wanna run a validator. I definitely want to run a validator.

Kui Wang: Yeah, yeah! Of course! I definitely want the validators to come from all around the world. But actually all the mining pools that are in China do not know a lot of people all around the world. So I would like to introduce the people to them, and make sure that they vote for the critical parties of the BCH ecosystem.

Josh Ellithorpe: Well I know a lot of people here would love to run validators, so I don’t think you’re going to have a problem. It's how we get those miners to vote for our validators is going to be the hard part of that equation. So any introductions you have would be appreciated.

Kui Wang: You can contact me directly. 

Mark Lamb: Kui, do you think mining pools will run farming services for some of the DeFi apps in the SmartBCH ecosystem? Because I think BTC, BCH miners have a natural incentive for this ecosystem to succeed. Even if they don’t hold any BCH, they have an incentive for it to succeed because of the increased fees on the gas they have a right to claim, technically. So do you think some of these mining pools will run farming as a service project? Or miners to take their Bitcoin or their BCH or USDT or something and farm it into the ecosystem?

Kui Wang: Actually, many miners, or many mining pools, actually they have different businesses. Did you know ViaBTC? The ViaBTC group also run an exchange and they have different kinds of businesses and the poolin mining pool they have other businesses and they run farms on Ethereum. So maybe the question is that the people who are running the mining pool will also run the business of DeFi farming. I think the answer is yes. Because both of the businesses can make money, then why not?

 But the mining pool itself, I believe, maybe not. For different businesses they will use a different brand and maybe different websites. But the same people will run both businesses.

John Moriarty: Well from there, I think for time’s sake and because that’s a pretty good place, let’s take a couple of questions we’ve gotten from YouTube. Now, many of them have been addressed, but I’m going to scan through them and find any that haven’t been touched on. A good one to start with, I think, is a question,

 “Do you think that SmartBCH helps Bitcoin Cash reach its goal of being peer to peer electronic cash for the world? And if so how does it help the main chain reach that goal with it’s token?”

Kui Wang: Currently when we talk about a token for the world, it’s no longer the old style money, ok? Nowadays I really want to think that the blockchain is a very smart money, or programmable money. Supportable, programmable money. So if BCH can not be a programmable money, I don’t think it can serve all the different demands from the world. So I do think this is a very important part which SmartBCH can provide to the BCH ecosystem. It provides a reach for programmability. Such that we can do a lot of things with BCH.

John Moriarty: Thanks very much, and would anyone else like to comment on that?

Josh Ellithorpe: I think that there’s an inverse that can happen with smart contract developers that are used to working within Ethereum, playing around with tools like SmartBCH, and realizing some of the benefits of the SmartBCH platform. But more importantly; then being able to go and increase the overall liquidity of BCH, as there are more people that are using it day in and day out. And they may want to see what BCH is about, more likely to test BCH if they are playing around with SmartBCH and have found cool applications. And then someone tells them, oh well you can also use this is cash! Here, hit these buttons on your wallet, it works like cash! And then they go, wait, but my Ethereum can’t do cash mode. There’s no cash mode for Ethereum. There’s no, like, instant transaction mode for me.. And that may be a way to get more people involved.

 But more importantly, we want to have worldwide money that allows for a new financial institution that anyone can participate in. And the truth is that the ETH fees are too high for everyone to participate in right now. So being able to be on a large block network, where people can get the same types of services, and loans and advance EVM based smart contract features, for pennies instead of dollars. Opens up this functionality to the world in a way that really hasn’t happened yet.

 And we’re in this bubble where people are willing to pay like 10 dollars just to, like, authorize something and not even move money yet! Much less move the tokens or unstake their tokens! I've seen fees upwards of $180 just like, “Oh I wanna unstake some tokens,” and it’s like, wow! This is just not usable by the world!

 And so SmartBCH opens up the smart contracts to people that have not been able to use them before. And it opens up a door to a fast transaction currency that they may not have been exposed to before. So I see it just as a win, to get that additional liquidity, and the additional eyeballs on these project.

John Moriarty: Great, I think maybe just one more question, then. Which, there might be more to elaborate on…

Cindy Wang: Oh! Josh, actually, I have a… *interference*

John Moriarty: OK so if she pops back in we can definitely give her a shot but I’ll just keep going for now. I think not many people are aware of really where SmartBCH is, as far as the state of the project. Now some people have heard that the testnet recently launched. Could you tell us with whatever ballpark you could give us, when is Mainnet planned to be launched? Are there chances of delays? And also is there anything already being built using the testnet, that’s worth mentioning? So if you want to just start with just plans for Mainnet launch, and schedule, that would be great.

Kui Wang: OK, technically we have all the code finished for the Mainnet. But we still need to test it. What I’m not sure about is the mining pools and the validators in action, and the cross chain gateway, how to select the parties to join the cross chain gateway. These things are not totally technical, and we must communicate with people. And it may take longer than we expected. This is not totally controlled by technical things. But I will try my best to bring the Mainnet to you in this month, in May.

Josh Ellithorpe: Quick question about the testnet? So I noticed that the testnet launched, but I didn’t see documentation on how to join the testnet. I saw a single node, I saw a testnet exists, but I didn’t see a doc on joining the tesnet.

Kui Wang: OK, sorry sorry, I must get some documents about joining the testnet. Yes you can compare binary and configure some parameters and use this binary to join testnet. This can be done. Yeah, we were in a hurry so we didn’t finish the document yet, maybe tonight.

Josh Ellithorpe: No worries! I just want to provide the docker and kubernetes stuff so that people can spin up testnet nodes with one command. And that way they can join the testnet and have everything automated, and get it so that it’s easier for us to be bringing up the test infrastructure. So just let me know when the docs are up, I know it’s super early. I mean, zero dot one or two.

John Moriarty: Another thing to add to that question was, “Do you know or are there any proofs of concept being run on testnet already or is it too early for anything like that?”

Mark Lamb: We’ve got an instance of a dex running and FlexUSD and another token running as well. I think our dex is like trading Flex against Flex USD. I don’t think we’ve made that public though so I’ll see what we can do to try to get that public in the next day or two, but I don’t think it’s public right now.

Rosco Kalis: Is that like a Uniswap fork dex, or?

Mark Lamb: Yeah, exactly, just super simple.

Cindy Wang: So I wanted to ask Josh a question. Because you work at one of the world’s largest crypto exchanges, so I wonder, you must know a lot of blockchain projects, I’m kind of curious, are you already talking with some of them and convincing them to build on SmartBCH?

Josh Ellithorpe: No, at Coinbase we evaluate everything. This is really early, we usually evaluate stuff when it’s at Mainnet. But it's a different department. So like I can bring up, like here are all these awesome currencies, here are all these people you should talk to about these currencies. But then there is this entire process that is unbeknownst to me on how they get to figure out what gets added to these exchanges. 

 But what I can say is that BCH is on a lot of exchanges, it’s well traded. If a smart contract platform on BCH gains a lot of traction, then there’s going to be a lot of eyeballs on that from the exchange community to make sure that they can support the popular assets on those EVM style blockchains. And since the tooling is so similar, at least from the API perspective, that also makes some of those integrations a little bit easier for the larger exchanges as well.

 But I can’t speak to any specifics as I don’t control anything that gets added there, I just build stuff.

John Moriarty: Very good, thank you. Well I think that is a good place for us to wrap up. So thank you all very much for participating in this discussion. Thanks everyone who tuned in for watching, and everyone on YouTube. Be sure to keep up with us there, subscribe to our YouTube channel, follow us on Twitter. If you have a topic that you think should be discussed, the place to start is BitcoinCashResearch.org, thanks to them for the work that they do running that platform. And finally thanks to all the folks behind the scenes who made this meeting possible. You don’t see their faces but they’ve done a whole lot of work and they’re much appreciated. So thanks again everybody for joining us.

*Thank you’s all around*