@blockparty-sh

@blockparty-sh 7 May 2021

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 https://youtu.be/8vUVM2WFgXA?t=44 https://odysee.com/@bitcoin-cash.network:0/Smart-Bitcoin-Cash---An-EVM-compatible-sidechain-for-Bitcoin-Cash-8vUVM2WFgXA:a 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*

@blockparty-sh 11 April 2021

BCH Network Discussion on Group Tokenization This latest discussion was recorded on April 5st with attendees: **Andrew Stone** (Bitcoin Unlimited) **Calin Culianu** (Bitcoin Cash Node) **Im_uname** (General Protocols) **John Moriarty** (Host) Watch the Network Discussion Here **John Moriarty:** Hello and Welcome to the April 5th 2021 Bitcoin Cash Network Discussions, these meetings serve as a public forum for discussing initiatives that have an impact on the Bitcoin Cash Network. This is not however a place for official decisions are made, of course, for the whole ecosystem, nor do we officially represent Bitcoin Cash. Bitcoin Cash is a decentralized network so there is no such thing as an official decision outside of the blockchain itself. Instead, our goal is to establish a high bar for proposals while also providing a platform for public moderated discussion. Today's topic is the Group tokenization proposal presented by Andrew Stone, lead developer at Bitcoin Unlimited. We're also joined by Bitcoin Cash Node contributor and BCH services operator Imaginary Username. As well as Calin Culianu, maintainer and developer for Bitcoin Cash Node, Electron Cash, Fulcrum, and many other things. So the discussion will be conducted in several sections, and for each section, the presenter, Andrew in this case, will give an overview of that section of the proposal, and then our guests will have the opportunity to add their own comments and ask questions. So the five sections will be: 1. The proposal's problem statement and/or use case 2. The properties of a good solution and/or implementation 3. The Proposal itself, and how well it fits those requirements 4. The cost of the proposal to the BCH ecosystem, and 5. We'll discuss the relevant stakeholders and any public support that they've already shown Andrew, whenever you're ready, please go right ahead. **Andrew Stone:** Sure. So I'm going to try to share my screen, here. OK, so as previously said this is about tokenization of Bitcoin Cash, let's just move right to the first slide. Ok, so quick overview is Group tokenization brings first class miner validated tokens to Bitcoin Cash. Why would you want to do that? Well, you know, tokens have proven, (to have) significant demand. They seem to be one of the main drivers of Etherium price appreciation, frankly, and also a lot of other alt coins are moving into tokens. It seems like a reasonable thing to imagine that the world will start working tokens to represent real assets in different ways. And also more abstract representations for tokens like the whole NFT art craze that is happening right now. When might this happen? Well, in this decentralized network there is no guarantees, but, I'm personally hoping for November 2021, with a fallback date of May 2022. How do we plan to do this? Well what we want to do is create a very smooth upgrade from SLP 1.0 tokens to SLP 2.0 and certain aspects of the Group tokenization architecture that makes that easier. So I think this is sort of the first slide for us to discuss. Problem Statement: First of all and perhaps the most important it fixes issues with SLP tokens. I was actually asked by people working on SLP to reinvigorate Group tokenization which was proposed many years ago to fix issues that are affecting SLP tokens today. So I predicted a lot of these issues so I may perhaps use a little terminology that is a little different, but the first important one is what I call Silent forks. And that is: cases where two clients deviate in their interpretation of SLP's state. And so that is effectively a fork in the SLP Blockchain, but since there's not a proof of work consensus mechanism that fork is not detected very easily. So then that's why I call it a silent fork. Another issue with SLP is you can have accidental token burns when, or, token loss effectively, when a wallet that doesn't understand SLP spends the underlying Bitcoin Cash UTXO as Bitcoin Cash. And then also, SLP tokens don't admit to SPV validation. So you either need to trust a full node that provides that SLP data, or the validation speed can be very slow because you need to search though the whole history of that SLP token to validate that it was properly transmitted between every single owner since it's genesis. What else? Why else have tokens? To increase BCH blockchain/wallet adoption. I think this is really important. If we can put more wallets on phones then we're going to be putting Bitcoin Cash in front of more eyeballs every single day. And so if tickets or hedging or hypothecated US dollars or other securities are presented to people through the Bitcoin Cash Blockchain then they will be exposed to Bitcoin Cash. And then the third advantage again, the problem is to create more adoption, broadening Bitcoin Cash use. I think Group tokenization does that in three ways, one is: to use BCA tokens on Bitcoin Cash you would need to hold some Bitcoin Cash for a variety of reasons and actual use of Bitcoin Cash results in high quality holding. And Bitcoin Cash will be kind of like the oil that greases this whole system and also it will be the currency of last resort, you know it will be the currency that everybody accepts. Because it's the fundamental native currency on the Bitcoin Cash network. So it would be your most common counterparty in-between token trades and so forth. Secondly, transaction fees and dust limit, so you know every token turns out, of course, has transactions on the blockchain that pays transaction fees in Bitcoin Cash. And also for every token, a little tiny bit of Bitcoin Cash is also associated with each token. And that does consume and use Bitcoin Cash. So, finally, I talked about this a little bit in the first point, Bitcoin Cash becomes the most efficient medium of exchange within the token system. So I think in summary if we create better cash on Bitcoin Cash it will create a better store of value. I think actually that quote should have been perhaps our, Bitcoin Cash's, talking point, our motto from the start. We've been so focused on cash uses, we didn't really, we sort of forgot that Bitcoin Cash is just as good of a store of value as Bitcoin, but it could be even better because it's also cash. And so perhaps we should bring that idea to the public's mind through different technologies, tokenization being one of them. **John Moriarty:** So I think a good place to start would first be questions that either of you have directly for Andrew about either his intent, or what he means. Calin, is there anything that you'd like to start with, along those lines? **Calin Culianu**: I think it's pretty clear, I understand what he's saying, I don't have any questions right now, no. **John Moriarty:** Imaginary? **Im_uname:** So I want to address the very first point, which is that silent forks, AKA different interpretations of token states have indeed happened on - **John Moriarty**: Okay, I actually apologize Imaginary, just so we can stick strictly to the format, it sounds like this isn't going to be, like, is this going to be directly like "Hey what did you mean by that?" or is this just moving on to comments and suggestions, just comments territory, is that right? **Im_uname:** Oh, OK, I'm making a comment. **John Moriarty:** OK, yeah and that's fine, I just figured I'd make sure. So we'll go ahead and move on then to that and then we'll get back to Calin. So please go ahead with any comments and we'll go back and forth. **Im_uname:** OK, sure. So I just want to address the silent fork point which I have personally witnessed was a thing that happened on the SLP ecosystem. Different clients have interpreted states differently which led to a "fork", a disagreement which was a problem. So I want to note that in a consensus-based token system, because it's consensus, interpretations affect whether a node views a chain as valid, and that is independent of proof of work. So no proof of work does not resolve this, in fact, if different clients have different interpretations towards token state in a consensus based system, it will lead to a blockchain fork. So a problem that was previously a token system problem is now a problem for the entire blockchain. So I just wanted to bring that up in the correction. **John Moriarty:** Sure. Andrew, do you have a response to that? **Andrew Stone:** Yes. So he's sort of exactly agreeing with me. I call it a "silent fork" right? So in fact, exactly what he says is what will happen, you will have a very obvious blockchain fork. I argue that that's actually better, because it can be.. we've actually had them in Bitcoin before, right? They are discovered rapidly and they are handled. Versus a fork that no one notices except for the person exploiting it, stealing potentially millions of dollars for months, until, all of a sudden, there's no going back, because the blockchain has advanced for months. **Im_uname:** That is an interesting interpretation, I must say. **Andrew Stone:** Well, you can ask yourself, you know, "Why didn't Satoshi do it that way?" Well, one thing about Group tokenization is that it is following the Satoshi architecture, for tokens. So for any question like this you can say to yourself, "Well, why did Satoshi not have a problem in the blockchain create a hard fork? Why didn't he just allow..." and this is actually what the Bitcoin whitepaper begins with, he says you know "Let's propose a timestamp server, right?" So all the timestamp server does is it orders messages, right? But the blockchain is much more than just a timestamp server of messages. It enforces certain consensus on like quantity of Bitcoin Cash. So you could ask yourself, you know, "Why didn't Satoshi do it that way?" **Im_uname:** That does not make any sense. Bitcoin Cash is explicitly a minority fork that disagrees with majority proof of work on consensus rules. **John Moriarty:** If I could interject, Andrew would you say it's accurate that what you're arguing is that it's not that it prevents silent forks but instead that, well ok, you could say it prevents silent forks but I guess the point you're making is that it makes it so that they're not silent. **Andrew Stone:** Exactly. **John Moriarty:** Instead the point you're making is that they're visible as opposed to invisible? **Andrew Stone:** Yes. **John Moriarty**: And if that's the case, then Imaginary, does that change anything? Do you understand what he's getting at there? *silence* Have we lost you, Imaginary? **Im_uname:** Sorry I'm here I thought you were addressing Andrew. **John Moriarty:** Okay, so I sort of did but then so it seems like you're saying yes. So it seems like the main point was that it makes it so that forks like this are, you know, it's not that it doesn't prevent them from happening, but it makes it so that anything happens obviously and publicly. I just wanted to make sure that that was it. **Im_uname**: Yes, and it massively impacts the confidence of the entire ecosystem, including BCH itself. Instead of having a problem that is isolated to one token system. **John Moriarty:** Okay. So go ahead to Calin. **Calin Culianu:** Yeah I mean it sounds like the question before us is do we want to make tokens a first-class citizen, as important as UTXOs are? Right because we'd have to accept the risk of fork's in the blockchain but the advantage is that the complexity of tokens would be concentrated in just the node implementations, right? Which would tend to be of higher quality as implementations. You have smarter engineers working there and you have like a finite number of nodes, right? How many implementations are there, five? There are like two major ones and there's smaller ones. You sort of have less risk there, right? Whereas when you don't have the tokens as first-class citizens, when you have, eh, everybody has to sort of implement all these crazy consensus rules to do tokens, you're just gonna, I think it's more likely to get what Andrew was saying. It's more likely to get silent burns and silent forks. I mean the question really is do we wanna make tokens first class? And if we do we probably should put proof of work behind it. We should have the nodes doing this kind of logic. Not, like, Bitcoin.com, javascript, whatever, I don't know. That's just how I see it as just, do what we want them to really be first-class? And then if they are first-class, what are the impacts of that, in terms of performance? Or other things? I don't know that the way I see it. **Im_uname:** I may not agree that that is a key issue, but that key issue can be phrased in a way that sounds very different. If one is in favor of such a proposal, one would say that the problem is whether tokens should be first class. If one is not in favor of this proposal one would say that the question is whether the benefits to tokens are worth the strict increase in risk to BCH itself. Because they are now brought under similar risk paradigms. **Calin Culianu:** Right, so what is the risk, i guess? I added complexity, right? More complex rules to implement a node to do consensus, is that part of the risk or what are some of the risks that you see? **Im_uname:** Oh well I'm strictly speaking of Andrew's slight just now. And that is a risk that is present in - that has been seen in SLP. Naturally it's also a risk in a consensus system. It will be explicit, if it happens there will be a huge confidence hit, there is no way around. **John Moriarty:** So, Imaginary, it sounds like what you just said is that the problem he described is still possible with miner-validated, first-class tokens, but it seems like what Andrew's saying is that, at least the way he's phrasing it, a silent fork would never happen because it would be a real fork. Which, he's arguing, anyway, would be a benefit. Do you think that's accurate, Andrew? And if so would you like to add? **Andrew Stone:** Yes. I would like to add one more thing to the context of this discussion, which is, I personally believe that we're not talking about, do we have silent tokens, like popular silent tokens, you know like non-SPV style, non-miner validated tokens. Or, you know, first class tokens. And the reason why is because tokenization proposals are entering other blockchains and they will be first-class citizens. So if you are an entity and you're wondering where you should place your token, you know if we don't move to a tokenization system that's miner-validating in first class, I believe that people will choose other blockchains, right? And now they may choose Bitcoin Cash, because they've chosen Bitcoin Cash, and then put tokens on, right, but if we want tokens to be a driver of adoption and excitement around Bitcoin Cash then we need them to be competitive across all sorts of blockchains. And so if we are not competitive then they won't drive adoption of Bitcoin Cash. **John Moriarty:** Andrew, could you maybe speak a little bit to the very basics of the cost benefit? Maybe we'll get to more of this later, but there is, of course, with any addition of complexity, going to be risk. And it seems like, so okay, you know however you phrase the question, the question is; Should they be first-class citizens or, more, should we take this potentially enormous risk? But as far as the risks go and the rewards, could you maye tell us a little bit about why you think it's like, definitely worth it, or mostly worth it? **Andrew Stone:** Yeah, so Group tokenization, and I'll describe this in a later slide, uses an incredibly simple algorithm and it is in consensus, right? But it is something that a high schooler could write. We were effectively just looping and adding and then doing a few if statements. So this is not, you know, complex cryptography, nothing like this. So I think additionally the constraints that have been added are all additional. So, like, existing constraints were not modified, right? So for example if you literally don't touch the code, that enforces quantity of BCH, right? Then you can arguably, looking at a particular code, say you know there's a proof of correctness where I added this additional constraint and I didn't modify an existing constraint, so how can my adding an additional constraint break an existing constraint? And the answer is, you know, you can look through the code and sort of prove the correctness and show that that's not possible. So I think that the code changes here are very small compared to the value that is achieved. And there's more of that in other slides so maybe we should just pause there. **John Moriarty:** Sure, that sounds good. And we'll give Imaginary and Calin one last chance for any closing statements on this section and of course if you want to comment a little longer on the same subject please go ahead. **Im_uname:** I would just, I mean, there are other things but I would just like to point out that adding constraints on top of additional consensus constraint is usually otherwise known as a soft fork. And it is usually pretty difficult to argue that a soft fork cannot be harmful. That is generally not how it works. **Andrew Stone:** Sorry, can you repeat that last statement? **Im_uname:** It is pretty difficult to argue that because it's a soft fork, it is not harmful. That is not a thing. **Andrew Stone:** I didn't say it was *not* harmful. I said that it cannot break an existing constraint. But there's no doubt that a bad implementation could be harmful in some other way. But the way that's harmful is constrained. **John Moriarty:** Okay, well, given that, let's move on, if you'll excuse me of course. You know hopefully we can continue things online and in later discussions. But let's move on to the next section which is the properties of a good solution. So Andrew is gonna walk us through what he thinks the properties are and of course Calin and Imaginary will have the chance to respond. Andrew, please go ahead, whenever you're ready. **Andrew Stone:** Okay. Solution properties; It needs to implement tokens, non-fungible tokens, fenced Bitcoin Cash, and script covenants. It should contain space for expansion of other interesting features and ideas. Be first-class, or native. We've been already talking about these terms, what that kind of means is it provides the same functionality for tokens as for the native cryptocurrency, and then sort of a very fundamental way. And then being so fundamental you can sort of, so this is the last point, BCH scripting. Like, because it's so fundamental it won't interfere with new features that get added. If they will compliment Bitcoin Cash they'll compliment Group tokens as well. It's very efficient. Allows at the client level miner-validated SPV proofs, as we said, eliminating silent forks. And it uses minimal blockchain script space. It does use some blockchain space, of course. But you're not executing a script to enforce token properties so the script space is very small. It's easy to use, the programmers don't have to write these complex scripts. and also as an idea that maybe a lot of people haven't really considered, but if you're on Ethereum and you invest in a ERC-20 token, you know that is actually an abstract interface. And the developer goes in and implements what that is under the covers. And sure there's a recommended implementation, but you implement anything you want. So, technically, every time you like grab an Ethereum ERC-20 token, you really ought to do an analysis of that particular token's implementation to make sure that it doesn't have security flaws. But you know with a single implementation that drives all tokens outside of the script layer. That problem goes away. I've mentioned briefly the consensus changes should be isolated from other changes and also, you know, is real nice to have, is a clean upgrade from SLPv1 tokens, so that we can minimize the work needed to move from SLPv1 to SLPv2 tokens. That's it. **John Moriarty:** So Calin or Imaginary, first let's start again, does either of you have any questions just as far as clarifying what Andrew meant or what was intended by that slide? Just so we can get that out of the way first. **Calin Culianu:** I have no questions, I mean it seems pretty clear, I mean I have some background in it. But yeah it seems no questions from me. **Im_uname:** As far a meaning goes, I don't think I have any questions. **John Moriarty:** Okay so then we'll move on to any general comments or additions, so Calin do you wanna start there if you have anything to add? **Calin Culianu**: Uh, no I mean, I agree with that list. I just want to comment that yeah it's nice to not have to write a complicated script to implement a token like Andrew was saying, where if you have it as the node's rules, the node's logic in C++, it's a very simple implementation to do tokens which is nice. I mean, SLP has that now, but yeah, I agree with that. I just wanted to comment that I think that's good, that's a good strategy. I think that could be attractive to people trying to decide what coin to use for tokens, if it's easier to implement. I mean, if it's another... Ethereum is really hard to do, so yeah, that sounds like a benefit. But that would be the case with SLP too, aside from SLP's problems. **John Moriarty**: Sure, Imaginary? **Im_uname**: Aside from SLP, which itself, you know, literally has simple in it's name, I also want to address the supposed difficulty that is created by script-based tokens like ERC-20. The reality is that once you have a standard base around a common template for creating a specific type of commonly used token, and people have to look at it quite a few times, and generally accept that, okay, this is simple enough and has passed enough eyes. The marginal cost, the marginal complexity for reusing this template over and over again is really minimal. I mean, at the height of the ICO craze I remember there were services on OpenBazaar, you can pay people $100, you literally don't need to know anything about cryptocurrency or tokens and people would just press buttons to make your tokens for you. It's that simple, nobody cares about what the underlying script looks like, it's all standard. Calin Culianu: That's true, it's a template, yeah, usually. Yeah that's true. **Im_uname**: So you know whether the underlying script is more complex or more simple, it has an impact on fees. It has an impact on size. But complexity-wise, once you get to the margins I don't think it matters that much. **John Moriarty**: Andrew, do you have a response? **Andrew Stone**: Well, people outsmart themselves, they say, "Oh, I'm just going to use this template with just one or two changes", right? Or, they deliberately introduce, you know, changes in the hope that people won't notice, right? You just don't know, as a purchaser, whether the template was adhered to unless you examine the code. You know, I teach a course on Blockchain and we go through Ethereum, I've seen so many bad tokens. i hope it's something we can do to differentiate Bitcoin Cash from Ethereum. We need to do something, and I certainly have seen bad token implementations, maybe it's because, you know, I'm working with students. **Im_uname**: Well, a wallet can choose to verify a token template just as easily or hard, or as difficult as verifying a multi-template which is, you know, P2SH script. People can of course do weird things theoretically in a P2SH that is supposedly multisig, if they want it to. But that has not stopped anyone from multisig, ever. **Calin Culianu**: Yeah, I mean most wallets just give up if they don't understand the P2SH, if it's not a standard template. That's an advantage, right? They're just like, "I don't understand this." That's the advantage. **Im_uname**: Yeah. **John Moriarty**: So is there, and this is open for any of you, is there a fundamental difference between the fact that in the case for Bitcoin Cash and the thing we just described, we're describing a script associated with an address to which one is receiving, as opposed to a program that someone else has made for you. Does that make a difference in how much trust is really required or whether it's marginal or not? **Calin Culianu**: Um, I mean just naively it seems like it's just easier to verify, you just see the OP header and then the rest of it is just a normal address. I don't know, does that answer the question, or I don't know, who are you directing the question to? **John Moriarty**: Yeah that was for anybody, it could have been. **Calin Culianu**: It's just a lot easier just to even look at, like you just see a couple of bytes at the beginning, and then the rest of it is just a standard address. It's just really that simple. **Im_uname**: Fundamentally all transactions, no exceptions, are paying two scripts. Even P2PKH, or you know, all the very simple ones we talk about. They just happen to have really short scripts. And that's it. **Calin Culianu**: Yeah, that's an important point to clarify. Yeah, Bitcoin uses scripts natively but they're all very short or simple. **John Moriarty**: It looked like the point, and correct me if i'm wrong, that was being made, Imaginary, was that, if I had to just summarize very quickly. It seemed like Andrew was arguing that there is a risk in using, maybe small, but there is a risk in using tokens built in Ethereum because their smart contracts can be written in a way that, unless you verify, might be a problem for you. Now, from there you brought up script templates, and actually maybe that's worth doing. Maybe this is a good one for Calin as well, can you explain exactly what you mean by script template and I realize that we don't want to get too technical but it seems important for the discussion. So does that mean that an Ethereum wallet can make sure that a token is following a very specific smart contract template. **Calin Culianu**: I'm not actually as familiar with Ethereum as Andrew is, but I assume.. **John Moriarty**: OK. Well if you don't mind we can ask, let's ask, Andrew; Is that the case? And maybe this is just a fundamental misunderstanding on my part, in which case we shouldn't waste time on it. But if I'm not following I figure some people might not. So the point you were making before is that for each Ethereum token, it has its own rules about how it can be sent around, is that correct? **Andrew Stone**: Right, so you would have to look at the program underneath the token and analyze it. And you can do that, it's on the blockchain, right? But with Group tokenization, since the enforcement of the token rules is not in the script, right? All you have to do is look for the OP GROUP instruction at the beginning and you know it's gonna enforce this token, just like it enforces all the other tokens on the Bitcoin Cash blockchain. **John Moriarty**: And so there's a consistency there that you can rely on? **Andrew Stone**: Yeah. **John Moriarty**: Ok, so Imaginary, maybe you could then just reiterate your point, your argument that it was a marginal or not important risk? **Im_uname**: So it is true that, obviously that if you have a shorter script it's easier to verify, that is generally true. But keep in mind that on Ethereum the reason that you often get all these risks that is associated with different contracts and tokens that are often involved in different contracts is because of the huge variety that is present on there. If you use something standard you know there is no good reason that it cannot be as easy to verify using a common standard, as a group or any other implementation. So if on Bitcoin Cash, if we toss a few more things into script, and say that, okay, now we have a huge variety of ways to encumber tokens with different conditions, different scripts, different mechanisms, then those will also be difficult to verify. Perhaps because of the optical limit they will be a little less so. **John Moriarty**: Oh, and maybe this is a clarification, by, verify... Imaginary, are you talking about miners verifying, and Andrew are you talking about users verifying? **Im_uname**: I'm saying in the context that Andrew has presented, which is that the users verifying - **John Moriarty**: OK, sorry about that **Im_uname**: the script that there are no shenanigans or rugpulls that are present. **Andrew Stone**: So, I kind of disagree with that, um, it's the same argument that I had with the hard vs the silent fork, which is that the Group tokenization is adding a rule, right? So now in this script context, if you use OP GROUP and you have removed all the mint authority, so there's no more sort of mintability. Then you can write any script you want, but you can't actually mint any more tokens, it's not possible. So the system, you don't have to, if what you're worried about is, you know, that token may become inflationary, you don't even have to look at the script. Because, well, there's no more ability to mint this token in this system by looking at UTXOs. I don't care what's in the script because I know that the conservation of token quantity is enforced by OP GROUP. Don't need to look at all of the additional rules and interesting fun things that this token actually implements. **Im_uname**: That is a very specific vulnerability that is addressed using a very specific solution. But generally speaking, for a given user, whenever you get tokens that happen to be spendable where they don't expect it to be spendable, any such incident has to be just as harmful as rogue minting, as you described. **Andrew Stone**: I think we're just going to have to agree to disagree on this, right? I think that preserving some fundamental properties of a token in a very simple way provides a lot of value. But you're not wrong that if you're worried about someone, Imaginary Username is not wrong, if you're worried about someone somehow being able to spend a token that you're holding and there's a complex script you would have to examine that script to make sure that there is no ability for someone else to spend the token that you think you own, right? But you wouldn't have to examine the script to validate that the token's properties, conservation and so forth are maintained. **John Moriarty**: Well, that seems like a good place then to move on. Now we've covered these properties of a good solution and the next section will then be the details of the current proposal, so, Group tokenization. Specifically in the context of those priorities. So Andrew, whenever you're ready, if you could walk us through how exactly you think Group proposal fits those. **Andrew Stone**: OK, so basically this is at a very high level, I think many people are already aware. But effectively what Group tokenization does is it annotates the outputs with a little bit of data, right? A Group identifier, a quantity of tokens, and then an OPcode called GROUP. Ok? So here is a pay to public key hash example, so normally, pay to publicly hash looks like DUP HASH160, your address, EQUALVERIFY CHECKSIG, OK? So in order to create that exact pay to public key hash, but for tokens, you would do a Group identifier, the quantity of tokens, the OP GROUP, then you do that exact pay to public key hash. So all you're actually doing is annotating the beginning of a script. And you shouldn't think of this as an OPcode that actually executes. Inside the interpreter, all this OPcode does is pop it's quantity and GROUP ID. Right? We had to put it in the script because due to the structure of the Bitcoin transaction there's no other place to put anything. And that may be an issue that will be addressed years in the future where we create a whole new transaction format. And when we do that, maybe we can clean this up, right? But I don't think personally conflating cleanup with this new feature makes a lot of sense. So this is the sort of most efficient path to get this functionality. **Im_uname**: Andrew, if I may interrupt you just to clarify, so when you say annotating, that's a labeling? Is that accurate? Is there another word that you could use? **Andrew Stone**: Yes, it's effectively a label. Yes. And that label is not used within the script interpreter. But, within the transaction level consensus, when transactions are analyzed for correctness, it is used, and what happens is, basically, at the transaction level you have a loop that says go through all the outputs and sum up all of the quantities per Group, and go through all the inputs, and sum up the quantities that came in. And guess what? Let's make sure that they're equal, right? And this is why I'm saying that this algorithm is something that a highschooler could implement. And now there's a little bit of complexity with that minting and melting which I don't wanna go into on this slide. But basically, the same sort of idea is when you create a Group you create certain authority outputs that allow you to mint and melt and you need to spend those in order to do a mint or melt, basically to do a mint or melt, you know that loop in that compare that we were doing? Well if you have the mint authority, don't bother to do it. Right? Or you can allow there to be more outputs than there are inputs. And if you have the melt authority you can allow there to be more inputs than there are outputs, right? So there's this one qualification that adds a little bit of complexity but it's still fundamentally just iterating through the inputs and the outputs and seeing if they balance qualified by "oh, I found a special authority, so I can ignore this restriction." That's it, that's the proposal. And there's no, um I'll talk a little bit later on the effects of this in the next slide, so let me just stop there. **John Moriarty**: Maybe before you leave this slide, I would like to point out, we would sort of go through this and directly reference the properties in the previous slide and how Group lives up to them so if you'd be willing to, maybe you could just do that now. **Andrew Stone**: OK. So it's a little bit, um, the thing is that you know you're going from, the proposal details, you're going from zero feet above, up to ten thousand feet, right? So sometimes it's hard to understand how the properties emerged from this, right? But at the transaction level this is enforcing the inputs equals outputs, right. And so what that basically means is that you cannot, um. Oh and you know you're annotating things with a GROUP ID, you can consider that a token ID, right? So a token might be a single entity of something, and the group is like, if you mint a thousand tokens, that's kind of like your Group. So that's the terminology. So it certainly implements tokens, you can see by the annotation. NFTs would be a tokenID of 1. And then also there's an additional little feature here, which is that GROUP IDs would be, um, you can implement something called a subgroup, which is you can just add a few bytes onto the end of your GROUP ID to create a larger ID. And that's interesting because not only does it produce Non-Fungible Tokens, but you can specify what the custom bytes are for your NFT, right? You know, but not too many, but you could have like for example a hash as part of your NFT GROUP ID and that hash could refer to a document, right? Or if you were issuing NFTs as seats, right? Then your GROUP ID is like the show and you could have a few bytes at the end of the token that would specify the exact seat that the person is sending in. Stuff like that. So this whole system will also enforce the same rules for Bitcoin Cash that is in the same UTXO, if you set a particular bit in the Group, saying 'that's what I want.' And so that's what I call fenced Bitcoin Cash, right? And the use of fenced Bitcoin Cash is a little bit esoteric, but it's basically, you can throw a bunch of Bitcoin Cash into a Group, and so you can have rules about how it can be spent. So it can back some other token or something like that. Script covenants; I didn't actually mention that in the details. There's one more kind of rule, which is if you have a bit set in your Group ID that says I want covenants, then what happens is that the system also checks that the outputs script also matches the first input script that's grouped. OK, so again it's just a simple check. So what a covenant is, is it's a script that sort of passes from inputs to outputs, and then recursively. And so that's enforced by a simple check. So first class native, so as I said all of this is implemented at the transaction level consensus, so that's what makes it like, first-class and native. And, you know, there's this exact same code that actually checks the quantities of Bitcoin Cash. So this is literally kind of like analogous to the code that already exists in Bitcoin Cash. So because the miner is enforcing the quantity, and it's not like in an OP return where the miner ignores the field, right? If this quantity doesn't match, or if GROUP ID quantities don't match, then the transaction is rejected. So that means that if this transaction is committed to a block, then the miners agree, and that block has sufficient proof of work, right? Then, you know, it's overwhelmingly likely that that transaction is valid. So you can provide an SPV proof of transaction, just like you do with Bitcoin today. So, uses minimal blockchain and script space. So, basically the GROUP ID is the hash of some data. It's a hash. So 32 bytes there, and then the quantity can be to 8 bytes and then a single operand, a single byte called Group, right? So you're implementing this with about 40 bytes per output. And that's pretty small if you think about implementing this as a script. Cause you'd have to have a lot of logic, but that is going ot be discussed in the trade-off. We are using more space. But I think it's as efficient as you can possibly get. Easy to use. Again I just taught you guys how to create a Group transaction, right here, boom, done. So for wallets and things to handle this is very easy, and it sort of adheres with existing conventions of these simple scripts that wallets deal with. You as a wallet don't need to worry about validating it you just need to ask for the SPV proof of it's inclusion in the blockchain. Isolated consensus changes. So in the details you didn't see anything about how I was monkeying with anything else. All I did was add a restriction, which is this looping operation. So no existing consensus rules were changed. And finally the clean upgrade from SLPv1. So a little bit of the history of SLPv1 is, you know, Group was proposed. And then SLP whitepaper actually mentions Group as a good miner-validated solution. So it actually is using the blockchain in a similar way, the only difference is that the rules and annotations in SLPv1 are located in this OPreturn area which is not miner-validated. And Group tokenization pushes them into the outputs and the miner validates them. so basically compared to other approaches, it's a much more natural upgrade cause it's just the same data located in a different place, and miner validated in one place and not the other. So, that's why the details meet the properties. **John Moriarty**: Thanks very much, and so I realize that of course having already gone over the properties themselves, then maybe there won't be a whole lot to say about Group's specific implementation there but please, go ahead Calin. **Calin Culianu**: Yes I have a question, so obviously semantically this maps on to SLPv1, or SLP 1 maps onto this, onto Group, right? They both tag UTOs, using a different mechanism, right? Would you say that's correct, Andrew? **Andrew Stone**: Yes. **Calin Culianu**: So now, really really naive question, and I think I've said this before. What's so terrible about making SLPv1's OP return, the stupid OP return it does, you can argue it's stupid, whatever, it's functional. It's a place to put data. So they put the data in the open return, they tag the UTXOs. Why not just make that miner-validated? What is so terrible about that? I'm being devil's advocate in asking this, but yes, why is that so terrible? **Andrew Stone**: Um, it's an option, and I guess it comes down to how ugly you want the code to look like, right? So there is sort of some rules that OP return is supposed to follow, like for example, there's some basic rules. Like no UTXO can affect any other UTXO in the system, right? So we're totally breaking that rule. Separate UTXO, right? OK so now what you effectively have to do now in like your UTXO database is you have to somehow annotate a UTXO and say, Oh but really this UTXO depends on data form this other UTXO, right? So that's a huge mess. Or what you could do is take the data from OP return and cram it into the UTXO, and if you've done that, you're basically implementing Group, sort of after the fact. But since we have the opportunity to do it more cleanly, why not just implement it at this point? And secondly, wait can I say one more thing? Another thing is you're kind of screwing SPV proofs, right? Because, well, I guess you could get an SPV proof of the full transaction and then the client needs to apply the OP return stuff to the appropriate UTXO, right? And now let's talk about UTXO commitments, right. How are you gonna do that when, again, you know, you need.. the data is separated in two UTXOs. But the commitment should put the data into one UTXO. So it's creating a bunch of problems that would need to be patched and fixed. I think that it's possible, though, right? And so it's just developer's opinion as to whether you want to bite the bullet and do it more cleanly or whether you want to put in all these sort of patches and fixes. **Calin Culianu**: OK, I'm not actually familiar with the UTXO commitment issue, I should do some more homework on that issue. That might be a killer. But, the other things you said.. you know, from my point of view it's a matter of 'where's the data?' It doesn't really matter if the data is right next to the output script or if it's somewhere else in the transaction, you could always map it in the UTXO DB. Like you said, somewhere else. **Andrew Stone**: But that is inviting more changes, right? **Calin Culianu**: Right, but see that's the other point I want to make. You're changing one thing to not change another. The thing is, right now, if you change, because we'd have to throw out SLPv1 completely, that is a change, right? Everyone that's got, like infrastructure built would just have to throw that away and move over to Group. **Andrew Stone**: Well actually, that's an interesting question. And what we're currently working on is presenting this information up, through the existing SLP databases, right? **Calin Culianu**: I guess you could do that, I think you can do that. **Andrew Stone**: You can totally do that. Now, the only issue is at some point the wallet may say, please give me the raw transaction that underlies this SLP data, right? And at that point we hand them the raw transaction and the data is in a different place, right. So we can hide all of the details from wallets and users, until they ask for the raw transaction. And then at that point they would need a little bit of code to interpret and generate the OP GROUP ruleset versus of the SLPv1 ruleset. I think though, if you're familiar with the SLPv1 ruleset and you look at the OP GROUP, you realize that the OP GROUP ruleset is much simpler. **Calin Culianu**: Yeah it is. It wouldn't be a big change for wallets. It's just, parse the output scripts and not have to parse the OP return. I agree with that. The other thing is, the fact that you're changing the output script, older wallets just won't understand. At all. They won't even know that address belongs to them. Which is an advantage and a disadvantage, depends how you look at it. Either way they won't be able to spend it, which can be a good thing. **Andrew Stone**: well, so yeah, I'm looking at it as an advantage. To say, hey the wallet can not accidentally spend this transaction, right? **Calin Culianu**: Right, which, anyway, Group enforces, right, if there's no burn authority. You can't burn it without doing a proper output script. Just like for instance, Fulcrum is going to break now. But it's fine, it can be easily fixed. Erm, not break but it's going to need to be changed. Whereas if you just preserved OP, the OP return thing, it wouldn't. But that's just a minor detail, it's not a big deal. John Moriarty: It's also worth, er, if I can make a quick point here, and then Imaginary, please go ahead. So, just to be clear I think melting the token is something that the, not having melt authority prevents, or burn. But you could still "burn" the token by sending it to an address that cannot be spent from, is that correct? **Andrew Stone**: Yup. **John Moriarty**: Okay, so just a small detail. Imaginary, please go ahead. **Im_uname**: So I would have to say, first I need to ask. On the first page, on the details page. Is that really all you have to present, in terms of details? I need to give benefit of the doubt, by asking. **Andrew Stone**: Well, yeah. I mean, other than the authority stuff. Which follows the same loop and check code. You know, it's.. I invite you to look at it. **Im_uname**: I did, I did. I will have to say that it is a very incomplete and potentially very misleading claim to say that it is simple and straightforward, because there are several aspects of it that are crammed into two lines at Details and Solution Properties; namely authorities, the fenced BCH, the covenants, and the fact that the authorities can change confidence on the fly. And not to mention that we are also introducing a new number system that is not even mentioned there. Each of these changes warrant its own evaluation. It is a massive complex change and I'm very skeptical of the claim that it is simple, or elegant, or anything of that sort. **Andrew Stone**: Well, um, I guess I would have to disagree. Did you say that it introduces a new number system? **Im_uname**: There is a raising of the integer limit. Unless I misread it and it is actually part of something else? **Andrew Stone**: There is a *raising* of the integer? **John Moriarty**: I think he's saying that, you know, bignum, and that sort of thing, which you have I think talked about, while talking about Group. And this is maybe something worth pointing out. Andrew, could you tell us, uh we are actually running out of time because we'd like to get to questions. **Andrew Stone**: I need to clear something up, it's really important. **John Moriarty**: But yeah, please go ahead and clarify if you'd like to. **Andrew Stone**: Yeah. OK, so OP GROUP is currently implemented on experimental blockchain that I call Nextchain, ok? It has bignums, it has all kinds of awesome stuff. None of which I'm proposing to go into Bitcoin Cash right now. No bignums are going in. No, like, OP EXEC OP CODES. There's so much stuff in nextchain, that I'm not proposing to go in. So Imaginary Username, you might have gotten a little bit of a misunderstanding. What I would suggest that you do is go read the actual, if you haven't already, the Bitcoin, uh, the specification that I wrote. **Im_uname**: I did. **Andrew Stone**: Oh, you did? So you know, there is no use of the bignum stuff in nextchain and then there's no use of OP EXEC or any of that stuff proposed. **John Moriarty**: And so it's probably worth clarifying, so the original proposal listed many things. There was, you know, several pages of things that *could* be added, once Group was also added. And it was maybe not super easy to tell that it was not necessarily part of the proposal. In fact it was even talking about the potential for a new transaction format even though it also said there wasn't. **Andrew Stone**: Yes, and also, for example, it was the first proposal for transaction introspection. Which is a whole separate effort that developers are working on, right? So the original Group document was a 40 page document that basically looked deep into the future and proposed how we could get from where to like a full smart contract-capable blockchain. What is being proposed now is a much smaller subset of that. **Im_uname**: At least the authority part and the covenant part are part of the proposal, am I correct? **Andrew Stone**: The authority part... what was the other..? **John Moriarty**: What was the second one, Imaginary? **Im_uname**: The authority and covenants. And their interactions. **John and Andrew**: Oh, covenants. **John Moriarty**: Now did covenants require introspection or is that just looking at the first script? Like the thing where it just looks at the script of the first Group transaction? **Andrew Stone**: All covenants does is say, hey do the output scripts match the first Grouped input script. You can imagine a simple loop that does that. It's implemented in, like, 8 lines of code. **John Moriarty**: Oh, OK. And so, Imaginary, feels free to then comment on, like even if, so Andrew is saying it seems to be pretty simple, but it seems you're at the very least skeptical. **Im_uname**: I'm saying that each of them require their own consideration and evaluation. I mean, you can say that this is eight lines, seven lines, I mean raising the block size limit to one gigabyte requires very little change in code as well. But there is a lot more consideration that goes into it. And when they are put together in one massive proposal, I'm not sure presenting it as a very straightforward and very simple proposal is the right way to go. **John Moriarty**: Calin, yeah, go ahead. **Calin Culianu**: So there is a concern among the developers that maybe there is a lot of complexity that im_uname is echoing here. What one potential thing that could be done is have this phased, eh, the initial implementation just do basically SLPv1 semantics, you know? And then add on another phase later to add on the covenant stuff or the fencing. Fencing seems useful and cool because then you could actually back tokens with real money. But would that be a path forward, would that be something that makes people happy? It's a question I have. Like maybe just do SLPv1 semantics initially, just, you know, mint, burn, spend. And then add on the complexity later after it's considered and after people are comfortable. Just a suggestion, really. What do you guys feel about that? **Im_uname**: And then there is, I mean, it's not my place to propose, but there is also the elephant in the room, which is, how much value does it actually add? Does this entire scheme of complexity actually add on top of what we already have? And are going to have, soon? Which is, on one side we've got SLP, which is non-consensus and easy to modify. And on the other we have smart BCH which adheres to an existing standard and can easily benefit from all the existing token and smart contract apparatus that are established somewhere else. Between those two I'm not sure how much value that has. **John Moriarty**: OK, well maybe this would be a good point to then leave that there. And again, if we can, I don't want to rush anybody but I'm going to because we don't have a ton of time. So Andrew, if you could talk briefly about your trade-offs, we'll talk briefly about that. And stakeholders, and then we'll try to get to a couple of Youtube questions. **Andrew Stone**: Okay, trade-offs. Full nodes must implement a consensus change. But the change uses exactly the information already required to validate transactions. So there's no sort of new information needed. No reaching out and accessing random transactions in the UTXO set, and so forth. Can be isolated into a single function. Does not change any existing constraint, we talked about that. No database UTXO or block, are needed. SLP indexers should present Group tokens as SLPv2. We talked about this, that they could be done invisibly to clients. But one trade off is until they indexer or the wallet asks for the transaction itself or it gois to generate a transaction, then it need to understand something about Group. One sort of detail is script-hash indexers like electrum should ignore the Group prefix. So that when it does the matching, because obviously the Group prefix within the amount field can change a lot. It's just that the electrum script-hash indexer is not meant to cover that so it should just ignore it when it's generating script-hashes.So un-upgraded wallets will work fine but as we said earlier they won't recognise and cannot spend Grouped outputs. So that can be a bit of a negative in the sense that it won't look like you're getting paid if your wallet doesn't understand Grouped outputs. But if, you know, the wallet is imported, you know, the 12 word secret key or whatever, into a group aware client, then all of a sudden the tokens become available. The metadata will mirror SLPv1. So that will be kinda easy. And the big tradeoff, which no one's mentioned, but people have mentioned previously, is, yeah you know to have tokens on the blockchain means there will be more blockchain use. And perhaps that use isn't as high quality as it is as if it was in just raw BCH, in the sense of adding value to Bitcoin Cash, right? I believe that we can control that problem by changing the transaction fee, or token transactions if needed versus BCH transactions. But we are also 'the scalability blockchain' so in a sense we do have to put our money where our mouth is there and actually ... **John Moriarty**: OK, so if I could just give Calin and then Imaginary a chance to speak briefly and then Andrew, sorry, If you could just keep track of what they both say and then I'll give you one chance to respond before we move on. And I realize we might not get to all of this and therefore, and of course we can never really expect certain things to be completely resolved here so, as much as you can get would be great. So, Calin, if you wanna get us started. **Calin Culianu**: Yeah I agree with everything on that list it seems reasonable the only question I have is it seems like there would be some database changes because you're adding another sort of UTXO space, you're adding a token reality, right? So there would be some....No? **Andrew Stone**: *shakes head no* There's no, unless you wanna ask a question like, give me all the outputs associated with this token, you don't need to index by tokenID, right, by Group ID. So for typical token operations, you can just use the normal BCH UTXO space. But if you want to.. **Calin Culianu**: OK, so you just go back to the previous output, look at the script, get the amount. Alright, ok, that's true, I guess that's true. **Im_uname**: I suppose that depends on your interpretation, because obviously you're recording additional data and fields in UTXOs, so whether that is a chain, whether or not indexing anything additional in UTXO or is no change in UTXO. I suppose that is very up for interpretation. **Andrew Stone**: Every time someone creates a new transaction type it's a change to the UTXO set. Like if I create a new script, I've changed the UTXO set. https://www.youtube.com/watch?v=f9wTZzNk1ro **John Moriarty**: OK I think that will probably be a good place to leave that so we can at least get to the stakeholders section. So, Andrew if you would just go ahead please. **Andrew Stone**: OK, so I got two quotes, from James Cramer and Burak. James said, "The Group tokens upgrade would provide BCH with a token protocol that is scalable in a trustless way using SPV wallets, SLPv1 cannot be validated using SPV alone, it requires users to validate the token locally, and this significantly limits the future usability of SLPv1 without relying on some trusted validation counterparty. Group tokens would eliminate this counterparty risk, and also provide the ability to build feature rich decentralized applications on BCH." Then Burak, of SwapCash, said, "GROUP tokens are by far the most streamlined proposal to achieving token-supported covenants which could definitely help Bitcoin Cash unlocking its potential to mass adoption. Group tokens are not only needed for gaining user adoption, but also developer adoption. Builders need more scripting capabilities to building meaningful dapps of which Group proposal could definitely contribute to." **John Moriarty**: Very good, thanks. And then, could you also maybe briefly, and I realize that this might be a big question, so however, these are people who have given you support vocally. Could you describe who in general you think the stakeholders are, whether they've spoken up about Group or not. Like who are the people that are affected by this and will, well, you know, I guess.. Who will be affected by this? Directly or indirectly. **Andrew Stone**: Um, people who were using SLP tokens came to me because they were having serious issues with accidental burns and silent forks. And that's what sort of has brought Group tokenization into focus again. And so anyone who's doing that, right? Anyone who wants to add additional and interesting features to Bitcoin Cash, I think, could really use Group Tokenization. **John Moriarty**: OK. **Andrew Stone**: As I said, and people don't really seem to understand this analogy, but I see blockchains are a language for communication of ideas about holding value. Currently we have one noun in that language, which is BCH, right? It's very difficult to build a sort of interesting conversation with one noun. So anyone who wants to create a service to sell tickets, to sell coupons, to hypothecate any security, right? It's a huge, huge field, so I think there potentially could be a lot of stakeholders and we don't necessarily see them because they're on other blockchains right now. **John Moriarty**: Sure. And then, Calin, Imaginary, would you like to either comment on stakeholders that you think he's missed or potential people that would be, you know, affected by this indirectly. **Calin Culianu**: Stakeholders that we've missed? I guess like the big, like Bitcoin.com, from what I understand I think they're positive on Group, I actually shouldn't speak for them, but I don't know what other stakeholders to think of, I mean there's developers but they're not really stakeholders. **John Moriarty**: Well, and I would say they are, at least to some degree. So maybe we're even thinking groups of people, as opposed to, specifically, say Bitcoin.com. You can say, OK, people providing X services, Y services, Z services people, that sort of thing. **Calin Culianu**: Yeah, miners. But I think miners are pretty agnostic, i mean i think they would be happy with anything that increases adoption. So if Group lives up as promised, I mean the proposal says, oh yeah we're gonna, maybe hopefully increase adoption. You know, miners would be happy with that. I would imagine, I can't speak for them. From my perspective I think SLP doesn't scale so anything that can be validated by SPV without having to do a whole dag walk going back to the whole history chain of custody. From my perspective I'm happy with that as a developer. So that's all I can say. Whether it's Group, whether it's something else, it would just be nice to have to not have to deal with validating a whole chain of custody to the beginning of time. **John Moriarty**: Sure, thank you. Imaginary, you wanna go ahead? **Im_uname**: So to me because the interpretation differs, but to me, this is a massive change that can significantly impact how the BCH blockchain works in the future, so the potential stakeholder group is basically all of the major pools and businesses that are currently on BCH. And one thing that is perhaps also an interpretation difference is I don't think the BCH is a system on which BCH is just a noun. The BCH blockchain is a tool that serves several desirable properties to BCH currency. Which is at the dead center. So, you know, all the other potential people who are establishing tokens should be viewed in the context of how they benefit or bring cost or risk to existing BCH stakeholders. And that space. **John Moriarty**: Could you give us an example or two of the type of risk that would bring specifically to, say, businesses or something like that? Like what are the, are there any concrete risks you can describe or even types of risks that come from changes of this sort? **Im_uname**: I mean, we discussed at the very beginning there is a risk of complexity bringing upon undesirable forks or denial of services. Those risks that previously affected the token system and sometimes not even the token system, only one particular token, in the case of SLP, risks are isolated. They now affect the entire blockchain, whether you care or not. There is also the risk of additional maintenance. And I can go on, but you get it. **John Moriarty**: Well, if there are any specific ones that are pretty easy to describe, I'd love for you to just sort of list them off, but if that's it then we can move on. **Im_uname**: There is also the other point of disagreement that was brought up before, which is that it doesn't affect existing consensus. Adding consensus rules, adding constraints is definitely affecting consensus. And it's a bit misleading to say that it does not affect consensus, just because it doesn't eliminate any existing rules. John Moriarty: And that may be in a wording issue, I think it said it doesn't affect existing consensus. Is that what it was? **Andrew Stone**: It does not affect *existing* consensus. **John Moriarty**: Or, even, existing consensus rules may have been the specific wording. **Andrew Stone**: Imaginary Username and I disagree about a few things, but I will say that he's gotten to the heart of the matter here, in terms of his previous point. Which is; bringing Group tokenization, or tokens, into the BCH blockchain is a big concept. And it potentially creates a giant market. But it does come with some risks that Imaginary Username did succinctly mention. We are adding new rules. There could be bugs in those rules. So the listeners do need to consider the tradeoff between the size of the market and the potential versus changing anything. And I think I've made kind of a good argument that the changes are conceptually at least much simpler than something like Schnorr signatures, right? But they *are* changes. **Im_uname**: And the one thing I want to bring up again is the elephant in the room, which is that for all the benefits that we talk about for tokenization, smartBCH exists, and needs to be brought into context. What additional benefit do people have on top of that? So when considering cost versus benefit, I think that is something that we cannot get around. **Andrew Stone**: People are getting a bit excited about smartBCH but I would have a bit of a different take. Which i will sort of.. I just don't think it's actually that wise of a business decision. And the reason why is because... Etheruem... like, if Bitcoin Cash didn't scale, then you could imagine, sort of, that Bitcoin Cash was Bitcoin without the first-mover advantage, Bitcoin without all of the press on mainstream media. And that is what, you know, in the last four years, has been killing our price. So what is smartBCH gonna be? Ethereum, but not Ethereum? Ethereum without the first-mover advantage? I believe that Vitalik will solve the scaling problems in Ethereum, so what are you gonna end up with, in smartBCH? Again, you're going to end up with a side chain that people who use Bitcoin Cash might take advantage of. But if you're a new entry, wondering what to put your thing on, you can either choose the real thing, Ethereum, or a derivative. Which one are you gonna choose? **John Moriarty**: Sure. And we'll probably leave it there. I realize we might have a response, but let's keep on going. That was actually one of the questions, so I'm glad we touched on that, of the situation with smart BCH. Mr Korrupto asks, "What would be the case for what is now the document field in SLP? In a first-class citizen solution for tokens, will something like this be supported or even expanded beyond?" **Andrew Stone**: So our intention is to use the exact same document field in Group tokenization as in SLPv1. Actually, ironically, the SLPv1 one came from the original Group tokenization proposal. So we're kind of all in alignment on the documentation aspect of it. **John Moriarty**: OK, from, Zhesto, oh I think I know who that is but I forget his name, "Will OP Group remove, or will the Group Tokenization proposal," which, I'll mention very quickly for our viewers, the original proposal, correct me if I'm wrong, was called OP GROUP, and this is called the Group Tokenization Proposal. Which is the updated tokenization proposal which does include an OP code called OP GROUP. But the proposal itself is not called OP GROUP, is that right? **Andrew Stone**: Yes, because it was expanded to include things like authorities which give you really interesting and important features like key material rotation and stuff like that. So the original OP Group proposal was very much a minimum viable product that was intended to capture the tokenization craze in 2017, and could have been delivered extremely easily and quickly. But when that didn't happen, you know there was time to make a more fleshed out solution that really covered all the bases. **John Moriarty**: And so, they're asking, "Will Group Tokenization remove all complexity needed for SLP, SLP DB, mongoDB, etc. Or will it just replace OP return SLP with one OP Group construction?" I guess maybe even more fundamental question there is: Is SLPv1 supposed to disappear? At this case, once SLPv2 exists via Group? **Andrew Stone**: Yeah I think there would be a compelling argument that it would no longer be needed. However, present, like, just, Electrum exists as a protocol for a reason in Electrum servers, right? They're technically not needed, you can get all the information about BCH by accessing the peer-to-peer protocol, right? But these higher-level databases have advantages, right? So SLPDB doesn't need to be consensus-correct anymore, in terms of the SLP stuff. But in the sense that it is presenting the tokenization data very elegantly and upwards to clients, in that sense this remains valuable. **Calin Culianu**: I could try answering too. One key thing is if you're try to implement a wallet right now with SLP and you want to really validate correctness, because you can't really, you may not be able to trust the data source, like the data source is telling you "I'm getting 5 Spice," or something. You don't know, really, if you have 5 Spice without validating fully. Or, making the decision that you trust the data source. Whereas with the miner validated tokens, you can trust the proof of work. You don't need to trust anything else. So that's one difference, it actually gets simpler. Like a lot of wallets, you'd be able to do mobile wallets that are more secure. You don't have to do all of this downloading and validation themselves. I think you'd probably see more mobile wallets with SLP tokens, with tokens in them. So it would simplify things, to answer that question, it would simplify a lot of things to have this or something like this. **John Moriarty**: OK, Freetrader says, " So there are currently something like 384,000 token contracts listed on Ethereum alone. Clearly the demand for tokens is very large. Some amount of state tracking will need to be done for Group. I did not find much information about the storage impacts of the state, and possible architectural implementations or design suggestions for doing this." Now does this come back to the fact that it's all the UTXO set, still, or, works that way and doesn't require any separate state? **Andrew Stone**: Right, it doesn't require additional state. It will expand the UTXO stat. This is why the dust limit is still enforced. Like if you have a group token as a UTXO you have to put a tiny bit of BCH in it which matches the current dust limit for BCH, right? So if you wanted to spam the blockchain you could do it with BCH as easily as you could do it with tokens, right. And then there is an additional, about, 40 bytes per output. So that's really your hit. But let me also observe though that, tokens tend to follow an exponential use pattern. So there's a few tokens that used tremendously and then most of them that are not used as much, right? So you know it's one over, you know, x squared or something. So why is that useful? Because you wouldn't have to store that, or even transmit it across the network, that 32 byte Group identifier every single time you see it, right? You could just compress it. Right and say, Hey, use like a Huffman encoding, right? And just say, this particular Group ID is the most prevalent in the last thousand blocks, so we're gonna call that a 2bit value, ONE. And then you just create a Huffman encoding tree, right? So then you can actually compress the Group ID hashes significantly. **John Moriarty**: And then a second question from Freetrader, "Also, have performance tests been run with Group? Possibly a simplified or limited phase-one scope on something close to BCH. My understand is the nextchain already diverges into several other points, but perhaps performance tests there could offer some insight. I just haven't seen much published on that, so I'm asking where to look." **Andrew Stone**: Yeah, um, so. We haven't run explicit performance tests, part of the reason why is because the algorythm is quite simple. It is no more complex than the current analysis of transactions, right? So from a big O perspective, it can't be more than a linear amount harder than current transaction anaylsis. But there certainly is work to be done to sort of dot the i's and cross the t's. And if there's interest in Group tokenization for BCH, the first step would be to isolate it and move it to sort of a more formal pull request into BCH, right? And then it would make sense to test that from a performance perspective. **John Moriarty**: Very good. From Jonathon Silverblood, now this again may touch on the storage and UTXOs again, but he asked, "In order to mint/melt they need to track what authority inputs are being used, right? So some data has to be stored somewhere?" **Andrew Stone**: So the authority is, itself, a UTXO. And it's just one with a, well, if the quantity is negative, it's interpreted as an authority quantity field. So if you spend an authority you gain that feature inside your transaction. So again there's no separate database needed to track authorities. And that's how key rotation is also implemented too, by the way. Because, you know, key rotation is the idea that you're a company, and you have a couple people who control control, say, the minting of an important token, and then one of them leaves and you bring in the new VP of whatever, you need to change who owns the authority to mint this token. So if an authority is controlled by a UTXO then you can spend the UTXO to the other individual, giving him the authority. **John Moriarty**: And then Benjamin Scherrey asks, he'd like to ask Imaginary Username if there is any concept of token support that he would support. I assume he means miner-validated but I don't know for sure, he says, "I get the impression that Imaginary's criticism isn't about the implementation challenge of Group, but the entire concept." **Im_uname**: Actually, no. I can certainly imagine that some very, very stripped down, very simple token proposals, for example, a few OP codes that live strictly in input script, is possibly the simplest example that I, you know, I both wouldn't mind and perhaps would just even ignore that they even exist. Because they made very very minimal changes to how BCH currently works, that they would essentially just be another OP code, that if you don't like it, forget that they even exist. So it is not true that I am against any tokens or against any consensus. Any tokens that are validated in consensus rules one way or another. **John Moriarty**: And just to be clear, I think that he did mean, the entire concept of Group as opposed to any others, as opposed to the entire concept of adding tokens. But I'm not sure, he can let you know in private if that's the case. OK, so let's see, one last one, Matthew G, "Andrew you mentioned that you're aiming for November and there has been talk about a move to a 1 year schedule or just even at least, now, taking some time." Andrew would you like to comment on the schedule and if particularly you supported the one year, the move to one year, or just the initial one year of waiting. And then maybe Callan and Imaginary Username could also comment on that if they like. Then we'll finish up. **Andrew Stone**: Right so this is an issue that's broader that Group tokenization, right? We're sitting here looking, and sure there was a Kim.com pop in BCH recently, but you know, let's ignore the last week and we're looking at a several year leakage of value and interest out of Bitcoin Cash, right? And so I actually believe that we need to move more aggresively and faster to create excitement and interest in our coin, and so obviously Bitcoin Unlimited is not the hashpower majority, and so we don't control when these features come in and so forth. But I believe we need to move faster and so that's why I'm hoping for the November time frame. **John Moriarty**: Very good, and then, Calin or Imaginary, would you like to comment on the schedule? **Calin Culianu**: I'm agnostic. It's really about what other maintainers can do. I can do November, I can do May, it's really what the ecosystem wants, so what other maintainers and other developers think they can do. I'm OK with any, like I'm agnostic about it, basically. I'm flexible with that. **John Moriarty**: Imaginary? **Im_uname**: So, I'm the original guy who proposed moving to a one year schedule, so you probably already know where I stand. Um, but the justification for moving to a longer schedule is that, we were on a six month schedule, and it had terrible, terrible, terrible records, such that BCH suffered, not from a lack of excitement over features, but from a lack of confidence all together. And that is not something that can be addressed by any given feature, even, if, you know, it is 'the bee's knees'. Throughout all of crypto is revolutionary, none of those features will address a lack of confidence. And every time any shenanigans, whether technical or political happens that threaten's people's confidence, we are that much further away from peer-to-peer electronic cash for the world, and that is what I'm most concerned about. **John Moriarty**: Very good. Thank you all very much, that's probably a good place to leave it. I'd like to thank everyone for joining us. That concludes today's Bitcoin Cash Network Discussion on the Group Tokenization Proposal. These Network Discussions are hosted on a best-effort basis by volunteers, so thanks to everyone working behind the scenes to make them happen. Thanks also to Bitcoincashresearch.org for providing the online platform where these discussions can first form. If you have a proposal for the Bitcoin Cash Network, Bitcoincashresearch.org is a great place to start. And thank you, for watching. Subscribe to Bitcoin Cash Network Discussions on Youtube, so that you don't miss the next discussion. Leave us a comment letting us know what you think about Group, or what you think about the Bitcoin Cash Network Discussions. Thanks again, for joining me. https://bitcoincashresearch.org https://www.youtube.com/channel/UCmyoHmbSsChInLzZ9S5aAAw?sub_confirmation=1

@blockparty-sh 8 February 2021

BCH Network Discussion on May Upgrade This latest discussion was recorded on February 1st with attendees: **Andrea Suisani** (Bitcoin Unlimited) **Cameron Lee** (Online Retailer) **Emergent Reasons** (General Protocols) **Freetrader** (BCHN) **John Moriarty** (Host) **Josh Green** (Software Verde) **Paul Wasensteiner** (Bitcoin Unlimited) **Tom Zander** (Flowee) Watch the Network Discussion Here https://youtu.be/HggepmwdIBI **John Moriarty:** (The purpose) of this meeting is for stakeholders and the BCH ecosystem to coordinate and communicate their plans about this upgrade. Viewers on YouTube are encouraged to ask questions in the livestream chat and we'll do our best to get to them.  So some Bitcoin Cash stakeholders have already announced plans to not implement any consensus changes for this coming upgrade. So, um, Emergent Reasons, could you start us off with a description of basically what that means and what the reasoning is behind it?  **Emergent Reasons:** Yeah sure so I'll be speaking as a general representative of General Protocols, you know as a business operating on the Bitcoin Cash network and from our perspective there was an announcement, right? that you're talking about where a number of the full-node projects, maybe all of them, I'm not sure all of them, but many of them posted their intention to say that, um, basically that they didn't intend to do any consensus changes on the network and that there was no outstanding plans that were in any kind of condition to be upgraded in May, in any case. And, yeah, so General Protocols supports that. And we published an article as well that said although there are some things that we would really like to see improved in the protocol, right? Not huge changes but um pretty reasonable changes and focused changes. Although we would like those and we really need those, you know, it's not ready, so, you know, we wait and we wanna set up that culture and General Protocols supports that, that kind of shift toward a culture where we get ready, we communicate openly, publicly. All of these ideas get aired out and beat up and reformed and refined. And yeah we support that.  So yeah in May, no consensus changes, General Protocols supports that. But, um it did, maybe like you mentioned it does seem like some poeple are confused no consensus changes means nothing happens and I think that it's not the case. And I think that some of the people here are able to speak to that better than me. But there are, I think, some changes that people want to do that aren't related to consensus. And so, it's improvements that don't lead to any kind of split-risk or anything like that. Yeah so I think it's a great place that we're starting from, for me. **John Moriarty:** Sure, so could I ask maybe someone else to elaborate just a little bit on why, so ok, if things aren't ready then obviously we shouldn't put them in, there's obviously some extra risk to any upgrade, especially if it's not been prepared enough. So maybe it would be worth elaborating just a little bit on the history of how that turned out being the case, that maybe this time we should just not do anything, or at least, that it could be that case at all. Anyone feel free to. **Tom Zander:** Yeah I'll join the conversation a little bit. So for me there was an upgrade scheduled and I think it's something that we all agree, we will use it instead to help us take a breather and give our ecosystem some time to work on adoption and work on stability. So when we said that we have a no-changes goal, we now propose it's where most users do not need to upgrade their wallet or software this May and I hope that this helps us get the stable footing again. And from there to work with merchants and others in order to grow adoption. Because adoption is really the focus that I believe personally that our ecosystem should work on now and as Emergent Reasons said it's really important to get new features in but we can work on those at the same time in the background basically and then these people will have more time to get the better quality that we need.  And I think we will also work on how to do upgrades in a better way going forward because we all are very very tired of conflicts that end up being escalated to unmanageable proportions. So if instead we end up having more conversations, we can avoid any of such confrontations ending up being to big to manage. **John Moriarty:** Sure, so before we move on to then non-consensus changes, would anyone else like to either ask a question or share an experience or share a perspecive on the decision on the not doing consensus-level upgrades before we move on?  **Josh Green:** (inaudible) how to raise my hand.. **Emergent Reasons:** Oh, right, we should be raising our hands. **John Moriarty:** Oh, it, well, I'm not even sure, is that, well is that a thing in Zoom? **Josh Green:** All right, maybe I'll just physically raise my hand next time. Um, I think it's just a matter of keeping in mind that like the upgrade in May, a lot of nodes don't have to upgrade like literally you don't have to upgrade your software if you don't want to. The exception would be BCHN because of some legacy carry-over from the previous fork. The important distinction is though, is who has to upgrade and who doesn't have to upgrade. So with a non-concensus upgrade, wallets and users don't have to upgrade their software. If you're running a node, which if you're a business or if you are a used running a node, you should probably check with your node maintainer or implementation to see if you should upgrade or if you have to upgrade. I think that's the only real miscomunication about that non-consensus means. And it's just who has to do what, when. And historically everyone's tried to have the upgrade. But basically if you're a wallet user, nothing's going to be different from your software if you don't want it to. **John Moriarty:** Appreciate you adding that, Josh. So I think we can move right on then to talking a little bit about the non-consensus upgrades, or you know however you want to call them, upgrades, or changes that are going to be happening -maybe- this May. And I'm going to just open that up, maybe Tom, you could start us off talking a little bit about the state of double-spend proofs? **Tom Zander:** Let me just quickly check the chats.. **John Moriarty:** OK, Looks like Freetrader just sent a message, would you like me to do that one first? **Tom Zander:** Yeah. Do that, yeah. **John Moriarty:** Sure. From Freetrader, he says **Freetrader:** I want to confirm what Emergent Reasons said from the point of view of Bitcoin Cash Node. We are commited to to the joint statement of the May upgrade without consensus changes. This does, of course, not mean we are not working on non-concensus changes. We are still working on an important non-concensus change, the increase of allowable unconfirmed transaction chain lengths. **Emergent Reasons:** "It doesn't mean aren't working on non-concensus changes", that, that's a pretty amazing sentence. **John Moriarty:** So if no one would like to respond to that, you go ahead, Tom. Thank you. **Tom Zander:** Yes, on the side of the non-concensus changes, I've been working with BCHN and others on these double spend proofs which have landed in BCHN just last week. We're also working on the follow up of that to actually go on for the next step which is to have the RPC, the interface between the node and other components. The important part here is that all the nodes basically have the same RPC interface so you still have the ability for middleware to just plug-and-play whichever node you want to run. And so BCHN has been working hard to actually implement some really good ideas there, which I'm pretty sure everybody else will just copy. And then the next step is to go up one level, which is the middleware thats gonna be the Rest API, the Fulcrum, and others, are gonna actually use all of this to provide a yes/no answer to everybody that asks, specifically wallets, are gonna be interested in that answer. So we're moving on to double-spend proofs, and that is I think the main issue, the main project that I am also working on. **John Moriarty:** So just to quickly follow up from that, and I do see your hand, Emergent, we'll be right to that. Uh, could you.. uh, excuse me, sorry. I saw Emergent's hand and I lost my question. Let me take one second, let me see if i can remember.. **Emergent Reasons:** It might be the same question! **John Moriarty:** Yeah, it very well could be, if you wanna go ahead, Emergent, I'll take a second. **Emergent Reasons:** Yeah, sure, well actually I didn't have a question, I just wanted to attempt to rephrase that in terms that maybe everybody can understand. So, make sure I get this right, Tom. I think the point with the double-spend proofs is that it will help the steps that are being taken by a bunch of developers and nodes and projects are to get it built up to the level that there's infrastructure so that anybody making an app or a wallet or any kind of high-level thing using Bitcoin Cash, they'll have an easy interface to just be like, hey, a transaction happened, and then they get an automatic notification that there was double-spend, or something like that. And then they can say, Hey something's wrong, you know, be careful with that transaction. And that will further improve the security, so that we can continue to have, effectively, instant transactions, and even better security on those instant transactions. Is that fair, Tom? **Tom Zander:** Yeah, absolutely, that's a very good description, the way that we're going, especially also with the longer chain-lengths that BCHN is working on, is that we will need some more proof of zeroconf being safe. And I think that's where we're going now, and that's making really good progress. **John Moriarty:** Alright, I have a message from Freetrader here, "BCHN would like to thank Tom and the BU Developers for pushing the double-spend proof initiative. We think this will be really useful for merchants in the future. From the interface's angle I'd like to drop this link here for others to review.", so here it is, "This merge request RPC interface is proposed by Calin Culianu." Thank you very much, Freetrader.  I think one thing that would be worth clarifying as quickly as we can (whoever would like to take this) is that this is something that's being worked on and i guess this is a statement, feel free to correct me, and there is not really anything that anybody but the people working on it need to do in the near future. Is that right or is there something that businesses should be thinking about? **Tom Zander:** So what we will end up with if all of this is complete and all of this is working is that point of sale systems and of course wallets that are recieving information will be able to say, hey, first step I see a transaction that pays me and within a couple of seconds, if this transaction is safe, and you will get paid when the block gets mined. And so the only thing really needs to be done, is when this all is done, when all of the technology is written, that people run the wallets to actually use this information. And that's it, so basically the merchants will have a new feature in the wallet, and that's about it. **John Moriarty:** Very good, thank you. So before we move on, I think, Tom, you did already mention the unconfirmed chain limit. Would anyone else like to add on to the discussion on double-spend proofs? **Paul Wasensteiner:** if I can jump in, so just to point out that BU has already implemented this in their node in their client, both unconfirmed transaction chain limit to a much larger number, and the double-spend proofs, obviously thanks in huge part, to the work that Tom has done on that. So these seem to be features that all node teams are working on the get them implemented on the BCH network, so like it's been reiterated multiple times, it's not that the work has stopped. The work is absolutely still going on upgrading Bitcoin Cash. It's just the case that in the May upgrade there's no consensus changes that are happening. But there's still major upgrades that are being worked on by each of the node teams. So yeah, just wanted to point out that BU is totally on board with getting double-spend proofs and long unconfirmed transaction chains added to Bitcoin Cash. **John Moriarty:** Thanks, I appreciate you clarifying that and adding it. Emergent Reasons, please go ahead. **Emergent Reasons:** So the question Tom mentioned, something that's very important, which is that the double-spend work, and you also John, the double spend work is not something that necessarily has to be related to main, there's nothing that people really need to do, it's just that they're going to get a new feature. But it is important to know that the people who are building the Bitcoin Cash network are thinking very carefully about the safety of everything and making sure that zeroconf stays safe even with these much larger, unconfirmed chain limits, and things like that. And another point that I wanted to bring up that I hope the other guys here can discuss maybe not too technically, but a little bit, that although double-spend proofs is something that anyone can start using at any time the unconfirmed chain limit is something that needs to be coordinated , it has a timing limit to it, in my understanding.   And so the May upgrade although rushed, not for these but for consensus, we're doing no consensus, so, right, 6 months is very fast for consensus issues. But having that time point, that May time point is very useful, I think, in terms of having some kind of coordination point for things like the transaction chain limit which need coordination. But maybe that can shift over to the chain-limit discussion, and make sure that I'm saying the right thing here. **John Moriarty:** So if anyone would like to add on, clarify, or maybe just make sure we don't talk too much about, really what it is, but more, what is it that people would need to know about it? And who are those people that need that information. **Paul Wasensteiner:** If I just jump in, so, essentially it would be, like Tom pointed out, it's for, either merchants themselves or for people building the software for merchants. So, if you take a specific example, the Cash Register app that Bitcoin.com works on, you owuld expect to see a notification pop up when a double-spend has occurred. So it's essentially providing that information that the merchant needs at the time.. **John Moriarty:** Right. And I apologize, I actually meant to move on to the unconfirmaed chain limit, and so thats what I intended to move onto there, so that's my apologies. But for the unconfirmed chain limit, if we could move onto that, what would be in that case, the people that need to know what to change and also does anyone else want to speak on whether is May 6th currently the plan? Is that something that has been decided or is still in the works? Does anyone have a specific proposal? **Tom Zander:** So maybe the background here is that we started out with a chain limit inherited from Bitcoin Core because of a feature called "child pays for parent" and that feature, when it was added, we ended up having a scaling problem. And it turns out when you have blocks that basically don't get full, and your fees are not going to shoot out of the roof, you don't really need that feature and we might add it later but basically the decision is that we can remove the feature child pays for parent and therefore have longer chains going. And this is what a lot of teams have decided and are gonna do. We don't really have any coordination about, Hey, this is the time we're going to do it. Because as Emergent said, there is some reason to actually coordinate this. I basically think that this is gonna be done when all nodes feel comfortable that their software implementations are gonna be stable enough. Then it can be done within a couple of weeks, especially since we already know that BCHN node has to be upgraded due to some legacy decisions and so when they have a longer chain it's going to be a lot easier to get this rolled out.  So I think that's the main thing with the longer chain. It's gonna be a bit of development work and then it's gonna just be coordination to roll it out. That's it, not very hard. **John Moriarty:** Ok, so maybe that's something that's worth clarifying is that the coordination hasn't happened yet, and so is it the case that it may or may not be coordinated for this May 6th upgrade? And, well, I guess I'll leave it at that. **Tom Zander:** Yeah, that's basically it. **Emergent Reasons:** I'm guessing that Freetrader probably has a statement here. **John Moriarty:** Yeah sorry about that, I'm just seeing his messages, so this is from Freetrader, "For the unconfirmed chain limits there is, as John mentioned, a coordination opportunity in May. This coordination to raise the limit from it's current value of 50 transactions would need to happen between the full nodes on the network and particularly the miners. On the BCHN side, we need to do some implementation and testing ahead of May to figure out the capacity of our software that we can safely underwrite." Thank you very much for adding that, it's valuable so everyone gets a feel for where we are in the process. He said, "I've said this in some chat channels before, but my feeling is that an increase to 500 is the low end of what we should be aiming for / be capable of." Very cool. **Emergent Reasons:** Nice. **John Moriarty:** And so I guess I'll open it up if anyone would like to add to or respond to what Freetrader said. I realized this has been talking about dev topics but if any business leaders who are or aren't involved in the tech, have any concernes or just would like to bring up just with current stakeholders just feel free. And then, if not that, then are there any other things that people would like to bring up about May 6th? Paul, go ahead. **Paul Wasensteiner:** Yeah so I'd just like to point out why this is an issue, because I've personally experienced it myself at the first London meetup that we started over 3 years ago now. When you when to spend lots of transactions, like we were trying to give away bitcoins actually, Bitcoin Cash. When you try and make lots of transactions you would come up against this limit. And it feels very very stupid when you're trying to show people the power of this new money and your app just goes, 'No, you can't send that money.' You know, you need to remove these barriers so you can send money whenever or however you like. So the issue is we want there to be as few barriers as possible to be able to spend the money you have. No one likes the computer to say No. So this is one of the ways of doing it. **John Moriarty:** Thanks Paul, go ahead, Emergent. **Emergent Reasons:** Yeah, so I just wanted to mention that, yeah, absolutely you want to get rid of that type of friction and barriers that cause problems, and at the same time just try to talk about it at a high level. There's some other networks that just say, "There's no limits, do anything you want!" and in reality that just doesn't work out, right? You break your network. So I think what we're doing with Bitcoin cash is a bit of walking that tightrope of doing all the amazing things we can do and also doing it in a realistic and safe way. I think that's a great thing about Bitcoin Cash, it's one of the best things that we're the most grounded in reality and focused on actually using it. How does this look 10 years in the future when there's mass adoption and there's thousands and thousands of transactions per second, and so forth?  I love that about Bitcoin Cash, that we're both trying to make it useful for apps and developers and users, and also trying to make sure that it's gonna work in the future. It's something that doesn't exist in a lot of places in crypto. **John** **Moriarty**: Thanks very much. Josh, please go ahead. **Josh Green:** Sure. Speaking to the transaction chaining limit, regarding businesses and what businesses need to do currently for the transaction chaining limit (this is some the we encountered in Dublin as well) A lot of businesses and software has to write limits specifically, to know that they are chaining a transaction too deep. Because you kinda don't get a good amount of feedback when you hit that limit, so a lot of times if you don't cover that yourself, you'll submit a transaction and then it just won't get accepted and you won't really know why or even that it happened.   So for businesses that have already implemented that limit, they're actually in a really good position for when this does upgrade. Because what they can do is they can have network upgrade ahead of time and when they're comfortable that it's at a state that it needs to be, they can reduce their own limit.   So what can fundamentally happen, even if we do this in May or we do this sometime after May, once businesses implement this limit, they can kind of go after the network. So it doesn't have to be this coordinated effort, say in May, where all of the nodes upgrade and we reduce this chain limit, and all of the wallets, all of the businesses, we don't all have to do it together, basically. The fundamental level should do it all at the same time for those who don't manually limit themselves. Just because it kind of reduces the security of zeroconf if we're not all on the same page. But then the businesses themselves don't have to immediately upgrade, so that's something they could do at their own leisure, there isn't a stressful upgrade where if they don't do this they're going to get forked off the network or anything like that. It's like, This happened and now if it's important you can provide a better user experience for your users when you're ready.  So I think, overall it's kind of just emphasizing the low pressure and the low cost for businesses, come May. **John Moriarty:** Thank you Josh, much appreciated. So I'm going to open up the floor one more time. If there's any last thoughts.. **Cameron Lee:** Yeah, I'd like to jump in. The people that I work with and talk to the most are people who like build on or use Bitcoin Cash, not really so much the developer side of things. So what I'm hearing is no consensus change but doublespend proofs and changing the chain transactions. But I think what the people I talk to are most curious about and most interested in is... is there going to be a split? I mean, a lot of people are really, like they've lived through the BSV, they just lived through the IFP last year. Last year was really hard for a lot of people, they've just kinda given up interest. And so, what I'm curious about is, it sounds to me like the plan you're talking about is going to not let a split happen in May. Is that true? Am I hearing this right that a split is very unlikely, come May? **Josh Green:** It would be very difficult for a split to happen at this point. One of the node implementations would have to go out of their way and then they would also have to significantly increase their miner share, which for anybody other than BCHN is already very... it's an uphill battle. I think users can definitely feel confident that there is not going to be a split of any kind in May. It would be very very difficult for them to do that at this point. **John Moriarty:** And maybe something that I'll add quickly in between comments here, is that when we talk about consensus changes, we're talking about things that decide whether, like, a block on the blockchain is valid. So, splits only happen when there are differences in consensus rules. and that's something that we probably should have made clear a bit earlier. You can argue that's sort of what it means.   I'm so sorry, Go ahead Emergent. **Emergent Reasons:** I think Josh's answer was great to recognise the reality that, well, anybody CAN split the network but it's going to be like their own node, and that's it, right? Doing it's own thing off on the side somewhere. So that's good to reflect that reality. And then at the same time, yeah there's basically no chance of anything like that happening. There's just nobody interested in that anymore. There's nobody who wants a split. I think it summarizes down to that, there's nobody who's interested in that. We're still learning how to make things happen without a king, so to speak. I think things are fine. We have worked through to figure things out, how to figure out process, how to figure out consensus and discussion, and making sure that everybody's on the same page and that ideas get considered and get a lot of time to be looked and peer-reviewed and so forth. So, yeah, we have a lot to work out, but as far as splits go, no, there's no chance of that. **John Moriarty:** Good deal, and before I get to you Paul I'm just going to read the most recent message from Freetrader, oh wait this is the same message, my apologies. Go ahead Paul **Paul Wasensteiner:** Yeah, It seems to me that the goal is not just to have no splits in May, it's just to have no splits in general. Like for as long as actually possible. Which, hopefully, is many many years. This is kind of part of what these discussions are about, is bringing people to the table and getting as much buy-in from as many people in the ecosystem as possible. So that splits just simply stop occurring. So it's not just about May, it's about all of the foreseeable future of Bitcoin cash. **John Moriarty:** Very good. Well that's probably a good note to leave it on, but I will leave it open one more time for just a couple seconds if there's any last minute questions anyone would like to make before we finish up. **Cameron Lee:** Yeah I'd like to just throw one quick one in just based on what everyone said right now. Is there something that we're working on that's gonna make sure that after May, like Paul was just saying, that it's gonna continue? We're gonna be splitless for a while? Is that something that's a priority? Or is there plans? Like where do I learn what's going on with that? **Emergent Reasons:** I'd like to say something about that. I think that there's going to be more than one answer to that question, but it's nice because there's a lot of people who are motivated to say, Yeah we're really tired of this and it makes no sense, and none of the splits we've had had any good reason for them , so yeah, let's stop doing that. And in order to do that I think there will be multiple answers and we'll just try to figure things out. one thing that I'm working on is trying to get people who have, specifically consensus changes, like you said, the consensus changes in the protocol are the ones that have a risk of causing some kind of split if there's a huge disagreement or whatever. But for anything like that, like I mentioned, by getting things out in the air and well considered, and a lot of feedback. In order to do that I'm trying to push a kind of combination of a format of proposals and process, so the chip proposal, the cash improvement proposal that Rosco Kalis has suggested. So taking that idea and making that kind of the format. If you think something needs to be changed, or that it's a good idea or it might be a good idea, we have a culture of putting ideas out there in a realitively standardized format, and that format includes all kinds of information, like the technical ideas, what's the motivation, what's the business impact, what're the costs to people on the network, the wallets and so forth? What are the benefits to wallets and apps, what are the benefits to holders and so forth? And then in addition to that, getting feedback, like in RCF, and making sure that we publicly record 'Hey this is what these companies think about it, this is what those nodes think about it, this is what - large investors, this is their opinion on it.'   So that format I think will be very useful to have as a kind of standard, like a social standard that we say, 'Oh this new idea has appeared and it's very controversial.' It will just be ignored, right? It came out of nowhere, no one's discussed it, it has no feedback, there's no RFC, miners haven't said what they think about it, businesses haven't said what they think about it. It'd just be like, 'Get outta here, what're you talking about?" So I think that's the kind of culture we need to set up so that we have a permissionless network, there's no reference node, there's no single person calling the shots. But we also have a kind of process in place that helps us take ideas and digest them and publicly comment on them and work on them. And then eventually they get to a point where, it's like the DAA upgrade right? It got to the point where it was just obvious, there was not really any disagreement about it, except for a notable exception, which is one of the cases that came out of nowhere. So there was so much agreement on it and so much alignment, that, it wasn't really even a discussion. It was like, 'OK, well, we're doing this thing.'   So I think we need to get to that point and hopefully the chips will help and maybe other people have other ideas, so we'll see how it goes. **John Moriarty:** Sure, Josh, I'll get to you in just a second I'll go ahead and read Freetrader's real new message, "If there's no consensus change proposed then, yeah someone would need to force a split and there's nothing of that sort on the horizon at this point. And I think the point of getting stakeholders together and discussing like we do here and in various groups is to better understand eachother's needs and to make it less likely that some parties will feel the need to split. We are fortunate that we as Bitcoin Cash survived the split with ABC in November without the same extent of damage to our network as the split with SV. But we absolutely recognise the damaged potential of such splits and that we need to cooperate to perserve the network effect. That's a very significant goal."  Thank you Freetrader. Please, go ahead, Josh. **Josh Green:** Sure, and kind of building on the plans for future splits and mitigations, and basically doing what we can to responsibly avoid splits in the future. I think a lot of that has, - well if we reflect on the previous fork, the ABC situation from November. The only reason that was a threat was because of this momentum with the "reference client", right? And I think we as a culture in BCH now are trying to move away from that "reference client" culture. And I think we've done a really good job with these discussions and also just with the people that we have developing and for like the social aspect of what "reference client" is, but we also have the technical component of what a reference client is.  If all miners are using the same implementation it's kind of hard to truly say we're a diverse network. And we're making a lot of good strides this year for diversifying mining in Bitcoin Cash. In January we released what we're calling the Bit Balancer, which is basically just a tool that sits in front of multiple nodes for miners so that accidental splits can't happen - well - not that they CAN'T happen, that they really shouldn't happen, it decreases the likeliness of an accidental split ever happening. And what that really does though is it gets miners the security to use multiple implementations.   But it also kind of really intangibly reduces the momentum of this concept of a reference client. And I think that even the current status quo client, BCHN, has been very supportive of this goal. Like, in order for the bitbalancer to even happen, we had to have a RPC function merged into BCHN. The original plan for us to do that was to make a pull request. So we were planning on going into their code base and actually offering up this change. They are so proactive that they did it for us! We didn't have to actually write the code to do the merge request, which was amazing. We would have never seen that, like, in historic reference clients. So I think, just again, the culture around our environment is substantially healthier.  And with the progress we are making with the adoption for bit balancer and multinode mining, I think we are really going to see a healthy future where if any changes to the network are to happen, they are coordinated and intentional. So I think the future is really bright, and there's been a lot of effort, both technologically and socially, into getting us there. I think we're going to see a lot of payoffs from that in the coming years **Emergent Reasons:** That is awesome, Josh. **John Moriarty:** Very good, Josh. Andrea, please go ahead. **Andrea Suisani:** First of all, hi everybody. To address directly what Cameron asked for, I would say that there is no technical thing to make it so that we are going to avoid splits forever or even on a small horizon, a year, 2 years, whatever. But I guess that the key point is the cultural layer that we are embracing in BCH. We went through painful growth process that I think helped the community to become a community that could embrace culture that, at the end of the day, lead to a more cohesive resilience when it comes to avoiding a split.  Everything that has been said in the last few minutes point exactly in that direction. And then the BCHN way of merging change without even waiting for contribution. The Verde project about the BitBalancer thing. All the things that have been said are the things that we need to continue to nurture. It has to be something that never stops, it's not a goal, it's a process. We need to continue to nurture this process.  It's like freedom of speech, it's like democracy, it's a neverending process to defend what we achieve in the last few months. It is difficult but we are human and we know that when a community needs to grow all the elements of the community need to contribute to this growing process. And not saying that it's easy, but, you know, the last few months if anything taught us that we could manage to acheive this kind of behaviour that is needed to make it so that the community is cohesive. **John Moriarty:** Very good, thanks. Emergent, go ahead. **Emergent Reasons:** Yeah, um I don't know if we're getting close to wrapping up or not but just in case, I wanted to make sure to get in, on this topic of, you know, like SickPig said, building the culture and process and all of that, and we still have to work it out. And everybody is still working on that in a constructive way. And I hope that everyone watching this will really seriously consider getting more involved.  Right, Businesses who are working on Bitcoin Cash, reach out, start to listen and talk and maybe assign someone from your compnay to stay aware, to actually get directly involved with various channels and try to make sure they are aware. You know, communicate in that direction. And then the Nodes and other infrastructure level projects should do the same, reach out to businesses and ask "Hey we're thinking about this thing, is this what you need?" and so forth and so I think both directions need to go. One way to do that, is we're doing the Bitcoin Cash commerce meetups, for example. So weekly I just run a meetup where anyone can come and talk about business on Bitcoin Cash. It's been pretty fun. I'd love for more people to be more engaged and more aware. I think Josh is also doing something, and there may be others, so before we wrap up I hope anyone else here can talk about any efforts like that.  **John Moriarty:** Sure, Josh go ahead. **Josh Green:** I think, firstly, what John just brought up is a really important part of this meeting. Which is, if you are using Bitcoin Cash for your business, like, at least, we are, we, by being Software Verde like, you can reach out to us and ask us questions. We really want to facilitate the knowldege trransfer that businesses need in order to use Bitcoin Cash in a professional and reliable way.   So in addition to the meetups that John's hosting, (which are awesome, we try to attend) you guys can just literally email us or reach out to us on Telegram. it's just anything@softwareverde.com You can just ask us whatever you need, especially if it's business related, like, "Hey what's coming up in May?" or "How do I do this?" or anything like that. We may not be able to help you directly but if we can't then what we'll do is direct you in the right direction.  So that's an awesome topic and I really wanna emphasize the openess for communication, don't feel like you're on your own, kinda thing.  And then to John's other point, we are hosting a separate, we are hosting like a developer hangout, which is again kind of like a cultural change from what we were experiencing maybe even like a year ago. Really trying to boost morale and coordination and just friendliness of the other development groups. So if you're a Bitcoin Cash developer and you want to get to know the other devs ans have some semblence of a social relationship with them, then you can join our Discord. It's every, well, I host one every two weeks and I think John hosts one on the other week that I'm not hosting one but I'm not exactly positive.  We will post the Discord link and you can join us there, and it's again, very casual, no agenda, "Hey, what were you guys working on?", "Who wants to talk about whatever today?", like, it's anything from technical to "Oh, my dog ate, you know, whatever." You know what I mean? It's very casual, and again it's really just meant to boost the comaraderie between developers so that we don't have animosity. So that just kind helps facilitate upgrades and facilitates new ideas. When the ideas are not shrouded by this kind of animosity towards the actual developer and they can be more focused around the idea itself. So you're welcome to join, again, we'll post the link. **Tom Zander:** And no questions are stupid. That's kind of the background, right? It's not recorded, if you wanna do this and this, you can come in and say, "What do you people think about it?" and maybe we'll have some better solutions. But, we can talk about it, that's the point. **John Moriarty:** Very good, thanks. Josh, did you put your hand back up, I'm not sure if it was up before.. *(Josh shakes head)* **John Moriarty:** No, Ok, sorry. Alright, well, I think that's probably a pretty solid place for us to wrap up. So I'd like to thank everyone in the meeting for taking the time to join us for the discussion. You know, everyone's busy and it's, as people have pointed out already, it's extremely important to be able to, in a public setting, talk about these things both for the benefit of the people discussing but also so that people watching and following along can know whats going on in the Bitcoin Cash ecosystem and can feel secure about what may be an investment for them, or a tool or something valueable to their business. Either way, I think that's something valueable that you all have contributed to.  And of course thanks everyone for watching, you can subscribe to the YouTube channel and we'll see you during the next meeting. Thanks very much.  *Thank yous and Goodbyes*

@blockparty-sh 7 April 2020

How to import Badger Wallet into Electron Cash SLP First, head on over to https://simpleledger.cash/project/electron-cash-slp-edition/ to download the latest release of Electron Cash SLP Edition. Next, we will create a new wallet: Call this one badger_1, we will be doing this twice. Standard wallet I already have a seed Enter your Badger wallet seed here Use m/44'/245'/0' as the derivation path You can choose to password protect your wallet if you like: Now, your wallet will start syncing. But tokens don't show up automatically! You must enable tokens you wish to see. Go to the Tokens tab and double click on a token, this will bring up a box which allows you to add the token to your wallet. This is so you don't get confused by counterfeit tokens using the same name. Now, restart this process, however use the name badger_2 for the new wallet, keep everything else the same except for the derivation path which is m/44'/145'/0' Now you have imported Badger into Electron Cash SLP Edition! You can continue to use Badger Wallet after doing this, this just allows you to keep using your SLP tokens even if rest.bitcoin.com is offline. If you haven't already, try making your own token, it's the big button on the bottom of the Tokens tab. If you are having problems with this guide please visit https://t.me/electroncashwallet or https://t.me/simpleledger and someone will surely assist you. Make sure you do NOT SHARE YOUR SEED though because otherwise they will have access to your BCH and your tokens.

+7 more

@blockparty-sh 17 February 2020

Fountainhead.cash Infrastructure Funding In December of 2018 Kosinus and I decided to fork 21 Century Motor Company after the developer decided to go to BSV, and create Fountainhead.cash. Our goal was to ensure that apps built for BCH would not be broken due to the abandonment, and that we could continue maintaining the software and providing free open access to development tooling for Bitcoin Cash developers everywhere. From this we've grown from initially just supporting BitDB and Bitsocket to now running a wide range of free developer tooling for the entire community: https://fountainhead.cash/ 3 BitDB instances https://bitdb.fountainhead.cash/ 3 Bitsocket instances https://bitsocket.fountainhead.cash/ 2 SLPDB instances https://slpdb.fountainhead.cash/ 1 SLPsocket instance https://slpsocket.fountainhead.cash/ 1 GS++ instance https://gs.fountainhead.cash/ 1 SLPstream instance https://slpstream.fountainhead.cash/ 1 Fulcrum instance (no webpage) 1 BCHD instance https://bchd.fountainhead.cash/ Token icon repository https://tokens.bch.sx/ These software and services are utilized by many of the applications on BCH today, including read.cash :) and hopefully many more in the future. We currently run 3 different servers and the monthly cost is $300. After seeing a recent video by Roger Ver recommending a Patreon account, we decided to start one. We will continue providing free developer services for the community regardless of the amount of funding we receive, but with more funding we can increase the reliability and likely the performance of our infrastructure and make Bitcoin Cash a a more enjoyable platform to develop on. With more funding we could also expand to be able to provide top notch developer documentation on a wide range of essential Bitcoin Cash tooling, which right now we cannot afford the time to provide. How popular is fountainhead.cash? We serve tens of millions of requests every month. Many applications use the tools from fountainhead.cash because we try even on a shoestring budget to provide a reliable service and are easily approachable for questions online. It saves a lot of time for developers to not have to set up this services themselves, or worry about the maintaining and hosting all of this infrastructure themselves. Bitcoin.com also provides many great developer services, including BitDB and SLPDB and also REST. Bitcoin.com is a great asset to the community, and their development tools they provide are awesome for growing Bitcoin Cash. At same time, it is important to have multiple organizations providing developer tooling for multiple reasons - any outage or issues affect every service, and it is more efficient to have multiple groups working towards a similar shared goal and going about it in different ways with different offerings. In short, the developer services team at Bitcoin.com is great and we love collaborating with them. Since the initial tweet where I announced the Patreon 3 people in the community have already decided to start funding fountainhead.cash: https://read.cash/@Read.Cash/were-migrating-away-from-restbitcoincom-2219a203 https://www.youtube.com/watch?v=rk4Ekyc1xQc https://rest.bitcoin.com/ Imaginary Username Chris Troutner Checksum0 How great of a community is it where a tweet already brings you over 1/3rd of the way to your breakeven goal? One is using Mecenas by Karol Trzeszczkowski, another is using Scheduled Payments Plugin by Calin Culianu and Robert Taylor, and Chris Troutner is our first Patreon supporter! If you like our mission and want to help support this project - the Patreon link is here and there is also a Bitcoin Cash address on the website. We will be updating the website soon with a new design that better shows our services, documentation, and sponsors. Thanks for reading Spanish translation: https://read.cash/@Spanish-translator-community/fountainheadcash-infraestructura-financiacion-by-at-blockparty-sh-2cfd26b5 [sponsors] https://github.com/KarolTrzeszczkowski/Mecenas-recurring-payment-EC-plugin/ https://github.com/cculianu/electron_cash_scheduled_payments_plugin https://www.patreon.com/fountainheadcash https://fountainhead.cash/

@blockparty-sh 1 February 2020

Finding Consensus for Infrastructure Funding Trustlessly In recent days there has been many posts pushing for or against the "Infrastructure Funding Plan for Bitcoin Cash" laid out. While there have been very good points made on both sides, it is evident that this is a very contentious issue. However, this post is not arguing the merits or downsides of such a plan. Instead, it is here to offer a solution to finding consensus for contentious issues in the community, which is currently lacking. There is an easy solution to these issues which has not yet been considered. Therefore, we have decided to challenge the signers of the "Infrastructure Funding Plan for Bitcoin Cash" to a decisive match of Quake Live, consisting of 5 rounds, in 4v4 TDM (Team Deathmatch) mode. https://web.archive.org/web/20200123082358/https://medium.com/@jiangzhuoer/infrastructure-funding-plan-for-bitcoin-cash-131fdcd2412e https://www.quakelive.com/ If you are not familiar, the gameplay of *Quake Live* consists of players attempting to kill more of their opponents than any other player or team in a given match. This is achieved by navigating a 3D environment and shooting other players with a variety of weapons, while collecting health, armor, weapons, ammo and various power-ups. As players get more advanced, they use other tricks and techniques such as rocket and strafe jumping. Being largely similar to *Quake III Arena*, which is renowned for its extensive use in professional electronic sports, *Quake Live* has seen inclusion in many tournaments worldwide. It is the perfect choice to determine if Bitcoin Cash should fundamentally change its economics. We will stream the match March 3rd at 11a.m. UTC time on the popular video game streaming site Twitch. If the Pool Owners win, they can implement the tax. If the community wins, the Pool Owners must give us 6 million dollars. Let's stop debating and give it a try. If the quake model turns out positive, we continue using it for future changes for Bitcoin Cash, otherwise we stop. https://en.wikipedia.org/wiki/Rocket_jumping https://en.wikipedia.org/wiki/Strafe_jumping https://en.wikipedia.org/wiki/Electronic_sports This doesnt mean we cant discuss the Quake match proposal, but we should just try it instead of wasting time.