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.

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.