 My name is Emma Olinberg, and I'm the CTO of bitcoin.com. And today, I'm going to talk about colored coins and tokens on the Bitcoin Cash blockchain. Originally, I was planning on explaining all the different use cases on what you can do with tokens. But after the debate that was online, regarding the OP group proposal, I decided to instead explain the more basics on how the protocol actually works and then have some examples and use cases. So first of all, what is a colored coin? What is a token? There is no consensus, really, on the definition of colored coin. Originally, the idea was that you would color a UTXO and say this output is green, this output is yellow, and then you would change the fungibility functionalities in transactions. But this idea was not really well received by the Bitcoin Core developers. So people started using and building protocols on top of opertern instead, because people realized that the colored outputs was not going to make it into Bitcoin Core. And the opertern protocols allowed for more experimentation and you can do more things with the protocol. I would say, though, that since the opertern is not a expendable output, it's technically not really a colored coin. The way I see it, a real colored coin is a colored output that you can spend. So the OP group was proposed by Andrew Stone from Bitcoin Unlimited. And the first property of the OP group protocol is the group address. So we have a hash 160 that is the serialization of a paid to public key hash and a paid to public script hash. The hash 160 needs to be the same as the minter that created the token. Since we don't know if the creator of the token was using a paid to public key hash or a paid to public script hash, it makes sense to use a completely different format to serialize the whole group address. Because from an interface point of view, when you build a wallet, you need to present to the user in some way that this is a token and the token has this address. Or the token belongs to this group. And by giving each token group its own address formats, the user can very quickly identify that this is a token. So if we check the example here of the group address, in my example, when I'm using the legacy, in this example I'm using the legacy format because it's shorter, makes it easier when you make a presentation. But since it starts with a T, you know immediately, OK, this is a token group. So any balance I have in this T address means that that is a token. So let's run through the op group pretty quick. All the new op group properties are in blue, and the black text is the normal script. So you start by putting data, which is the group address, which is just a hash 160. Then you put the value, how many tokens there are, and then op group, which is still a no operation op code. It doesn't do anything. But it helps the node to understand that this is a token. And then you have two drops to make sure that the data that was pushed to the stack is ignored and doesn't actually affect the script's evaluation. So this is where it gets a little hairy. Because it's an op code that is not an op code. It doesn't do anything. It's a useless op code. And it did call some contention because some people think that, well, this is not really good practice. Because when this was reviewed as an op code by an op code workgroup, an op code workgroup, their task is to review op codes. But here we have an op code that doesn't do anything that is not really an op code. So if you only look at it as an op code, well, it looks kind of awkward. It's more like 1% op code and 99% consensus layer. So op group, despite having the name op in it, should be really viewed as a consensus change and not really an op code per se. It would add native layer 1 tokens to Bitcoin Cash that is supported by every wallet. But it also has to be supported by every wallet. It is possible to have a limited supply or unlimited supply up to a certain point, depending on how big variables you want to use. And one thing that's important to mention is that the first proposal was one token is paid to one Satoshi. It has been updated since then. So that's no longer the case. So if you only look in the op code domain, the change is very small. It's tiny. The only change that an op code workgroup would review is that no op 7 should be renamed to op group. That is the only change in the op code domain. The rest is consensus. So why do we use a lame duck op code anyway? Well, the Bitcoin transaction lack fields for putting extra attributes in the outputs. You cannot put random data in the output without making it an op return, which is not a spendable output. The only way to put extra data in an output without a hard fork is to put it in the script. And it's not a perfect solution, but it's the smallest change possible. Of course, some argue that there would be better to change the whole transaction format and to be able to put additional data in the transactions. But that would be a whole remodeling of the transactions. And if we do that for the sake of adding tokens, then a lot of people would say, hey, but I have this proposal. Can't we have had my idea today to this change? And then suddenly we would have 100 suggestions on what to do. It would be a very long process. It would take a year for the community to decide on a spec. And maybe it could make it in the May 2019 hard fork, maybe. But also if you change the whole transaction format, you don't really want to add new features. Because if you bump the version and completely redesign the whole transaction format, it's good practice to not add new features. Just have the exact same features and not change anything, which would mean that, well, if we managed to do that for May 2019 hard fork, well, then we couldn't really add tokens until November 2019, so it would take forever to add the functionality that we want. So using a lame.op code is a more pragmatical solution. And it's not dangerous. It doesn't break anything out or anything. It just puts additional data in the transaction. And when you serialize it, when you get the JSON serialized data from a Block Explorer API, it will look the same. Even if we change the transaction format or we add the data in the script, the serialized JSON data that you will get back from Bitcoin D or a Blockchain Explorer API, it will look the same. It wouldn't really be any different. So I think this is probably the best solution for it. So why do we need native tokens anyway? Well, a layer one token would be minor validated, which means that every wallets can trust that the transactions included in the blocks, which means that every wallet can trust the transactions that are included in the blocks, which makes it possible for SPV wallets to trust tokens sent to them. It means that every wallet can add the functionality, which is very important here. It would not be possible with an operating protocol, but it also has a downside. It also means that every wallet must implement it. Every wallet would be required to handle tokens in some way, because if they're sent unsolicited tokens or if they have sent tokens and the wallet tries to spend these outputs in an invalid way, suddenly an upgraded wallet would not be able to broadcast these transactions to the network because the input contains a token and the transaction format is in a way that would make the nodes rejected. Also, the native tokens would probably be the only token protocol that would be accepted by hardware wallets. If we're going to have a token economy on bitcoin cash, and we're going to have companies, or who knows, even central banks printing tokens and putting it on the bitcoin cash blockchain, they're most likely want to do that with hardware wallets, have multiple hardware wallets for multi-sig. And for the upper turn protocols, I'm not that sure that Ledger or Tresor or the other ones would really bother to implement the upper turn protocol. They're way more likely to have full support for a native token. Also, we don't risk having users which would end up with tokens in their wallet that they can't spend. With an upper turn protocol, if tokens are sent to an SPV user, then they can't spend it. The only way they will be able to spend it is that if they take the private key from their SPV node, then put it on a full node, then they can spend the token that was sent to them if it's our return. With native, that's not a problem. A native token would also be more decentralized since all the full nodes on a network would support it and forward them instead of a few patched full nodes. I don't really have any numbers, but I suspect that very few people hold their tatters on their own full nodes or have tatters on their phone because you need a full node to save your tatter, which means that most people that hold tatter at USD tatter, they only keep it in an exchange. That's not very decentralized. And also, since native tokens is using the scripting language to issue and burn tokens, issuing these tokens will always be as safe as the Bitcoin scripting language. If we know that the Bitcoin scripting language is safe, then issuing these tokens is also safe. It cannot be more insecure than the scripting language itself. So let's run through some examples on how a transaction would look. They're also pretty simple. Let's start with the sending transaction because that will be the most common transaction on a network. And some wallets will probably initially only be able to handle sending and maybe not bother implementing the whole minting and melting process. The input value and the output value must be balanced. So in this example, we have one input and one purple output. They're both sending 1,000 tokens. So this would constitute a valid transaction because the input and the output are balanced in value. If you want to send your friend 500 tokens, and then you need to send the other 500 ones back to yourself, since Bitcoin is still the UTXO-based, unlike Ethereum, which doesn't use UTXO in the same way at all, if the token values in inputs and outputs are not balanced, the transaction is not valid. So here's an example of an invalid transaction. This one is invalid because the user is trying to, so it has the input is 1,200 tokens, but the output is only 1,000 tokens. So this would not be valid. So in this case, the miner would not take 200 tokens. The miner will cannot take tokens as fee. So this would just be an invalid transaction, nor will the tokens be burned. So this transaction would just be rejected by the network. This is to make sure that only the issuer can destroy the tokens so users cannot accidentally destroy tokens on their own. One thing to point out, though, is that this transaction would be valid today. This kind of transaction can be mined today on the Bitcoin Cash Network. It will be classified as non-standard, but it would be valid because the protocol, because we haven't activated the soft work for this yet. For minting and creating new tokens, the output group address must have the same hash 1,60 as the input. It can be minted to any address. So for example, I have the hash 1,60 in purple color. And I have the token group in green color, and they pay the public key hash address in orange, if you can see the color. The input is sent from the orange address. And it's being sent to a completely different address. But the token group is the same, is the green one. So the orange address and the green address, if you take out the hash 1,60, they will be the same. It will have equal hash, which means that this is a valid mint transaction. New tokens are created. As for melting or destroying tokens, only the issuer can destroy tokens. So in this case, if you want to destroy the tokens, you need to first send them back to the address that created them. And then from the address that created those tokens, they need to send the tokens into nothing. So in this case, you see that in this transaction, the input and outputs are not balanced token-wise. So if the issuer is sending 2 million tokens, the input is 2 million tokens, but the output does not contain any tokens at all. So 2 million tokens are just destroyed here. And this is an example of how the wallet UTX-O set could look like. So the total balance of this wallet is 1.0401BCH. The wallet has six outputs, and two of them is just normal Bitcoin Cash outputs. And you see that four of them contains tokens. So three of them constitutes around 200 million tokens, belongs to the group TDZ, while over 9,000 tokens are sitting in the address 13Y, belonging to the group address TCW. So it still uses the UTX-O set, just like Bitcoin has always done, but some UTX-Os are colored, which is why it's called colored coins, but it's actually colored outputs that we're talking about. And each output, they still have a Bitcoin Cash balance, but they could also have a token balance. So one output can have two different balances. This is just a start. Like this change is tiny. It's pretty small. It's like 50 lines of code. It's a small change, and it couldn't get included in the hard fork because of time constraints, so it will definitely make it into the next hard fork in November. We will work very hard to make that happen. The biggest challenge is, as usual, is always the user experience and the user interface. Writing the code for the miners and the nodes, that's these apart. Updating the wallets to have great user experience, that will always be the biggest challenge. Also, exchanges will need to handle tokens in some way or the other. Even if they're not trading tokens, the exchange wallets needs to handle the tokens. Because what happens if someone just sends a token through the exchange wallets? Well, even if they can't trade it on the exchange, they need to get it out. So the exchange is they need some time to opt their code and make sure that users can deposit and withdraw tokens. Because you're still sending tokens to a normal Bitcoin address, which it will lead to some headache for exchanges, but it's still not a huge change. We still need some API services and block explorers for advanced users and people that are planning to mint a lot of tokens or ICOs who want to pay out dividends to shareholders. They probably need to rely on more advanced API services that have a full log of every token holder for every block. But that's only needed for the more advanced users. Most people, they just want to hold tokens, they want to spend tokens, and they want to send tokens. I have more slides, but that's probably going to take 15 more minutes. Is that OK? Or five minutes? OK, I can just. I hope everybody got that. Did everybody get that? I was going to mention that exchanges will kind of have a headache when. So if ICOs are going to pay out dividends, then most of the tokens will probably sit in exchange wallets. If Bitcoin.com games, for example, would issue shares for their service and pay out dividend, then most of this dividend will probably go to big exchanges, like CoinX or Binance. And these exchanges, they need to have a good plan on how to handle that to make sure that their users get paid the dividend. I don't think I have time to explain that. There are a lot of other things that we need to consider for the tokens. The BIP-70 protocol should probably be extended to include group addresses. If a fiat token emerges like Tether, then some merchants could possibly want to accept this as payments using the BIP-70 payment protocol. Or if Amazon would issue their gift cards as tokens, they would want to accept these gift cards as payments. So we need to extend the Bitcoin URI standard. So if I'm showing a QR code on Amazon, and I scan it, then my wallet needs to know that, aha, I can only send, then my wallet needs to understand that it can only send Amazon gift cards to this address. So there's a lot of things that we need to, that can come after. The consensus-wise, this is pretty easy. And the community needs to work hard to build out the user experience of user interfaces to make this usable for people. The specification is not completely decided. It can still be improved and changed a little. But it needs to be settled very soon. So all the different wallet developers and exchanges will have months to prepare. So they know exactly what to do before the hard fork and make sure that everything is ready before the hard fork where we activate this. And yes, another important thing is that in this example, I was using hash 160. We don't need to use hash 60. We can use SHA-256 to mitigate the birthday attack problem. This would lead to longer addresses. But since the cache address format is extendable, then that's not a problem. The addresses will just be slightly longer. Yeah. Thank you very much. I have time for just one question. Do we have one question for Emil? Let me get your mic. Hey, thanks for the talk. One question. No, no, you can stand there. Sort out your thing. If we're paying to actual addresses, what happens when the Bitcoin at that address is insufficient below the dust limit or something such that you actually can't. You don't have enough Bitcoins there to pay out. Therefore, you can't actually move your tokens out. How do you handle that? You need to refill your wallets with fresh vanilla Bitcoin cash to be able to spend it. Because the most important thing is that the token value is balanced in the transaction. So you might need to send more Bitcoin cash to your wallets to be able to get them out. Thank you. Let's give it up for Emil. Thank you very much.