 Can you guys hear me? All right, great. So I'm going to indulge in some rabble rousing, which is, I just want to say, I kind of was here at the beginning of this effort to increase the block size. And our first Satoshi's Vision conference was like literally a conference room about twice the size of this stage, right? No, this is the second. And when I look out and see everyone here, it's just awesome. And development is actually now a small part of this movement, whereas before, everything was about the development. So now, in the first conference, I talked like, I don't know, four times in this one. It's like, well, maybe we can stick you in in the middle of all these other talks about awesome stuff. So I just want to thank everyone for being a part of this movement and thinking differently. So today, I want to talk about basically adoption. Everyone seems to feel like that's important. So do I. So on August 1, some people might think that was like victory when we forked. And it was something to celebrate. But I feel like leading up to that, it was on negotiation. And when we forked now, it's war, right? And we gave up a really valuable tool, which was a network effect and being all over CNBC and all this stuff. But we gained a really good tool as well. And that, of course, is the hard fork in our willingness to deploy awesome features to make Bitcoin Cash awesome. So I think we need to essentially deploy that feature, and we are planning to, to increase adoption. We have the capacity to maintain a network effect. And now is the time to do it. Why I think now is the time that we don't have time? And maybe simply because my professional history was working in startups. And so in a startup, yesterday is the time. Everything has to be done three weeks ago. But also, we might be entering into a bit of a bear market in cryptos in general. And it's much easier at the bottom to make that change and create a bit of a higher adoption increase for your coin and leave everyone else's in the dust than it is at the top when everyone's already talking about Bitcoin every single day. So if you imagine that the bear market will last, I don't know, maybe a year or less, then we need these technologies deployed now so that three to six months from now when people start, the general public starts getting excited about crypto. Again, we have this stuff ready in wallets in consensus. And two things we can do is to counter the propaganda type stuff is to do novel development efforts. And of course, if we do development, it might drive SPV wallet installs with these new features. And finally, I want to introduce an idea that might be a little bit controversial. And that is actually if we implement a feature and we do it in a slightly different way, we're not just copying existing blockchains, then that's actually better in many ways than implementing the same feature. Let's say you implement a feature and it's worse in seven metrics, but better in three. You're going to create a niche for your product. And that's essentially exactly what happened with Xthin and Compact Blocks. There's still a huge debate over which one's better. And the reality is that Xthin, just if you look at the aggregate bandwidth, I think it's slightly higher than Compact Blocks. However, some of that bandwidth is sent in the other direction. So in Compact Blocks, it has a higher download bandwidth than Xthin. But what Xthin does is it sends some information in the reverse direction. So basically, depending on the way your network works, one might actually be better than the other. So do things differently so we create niches. So from there, I want to talk about some of the things that I want to do to drive adoption. So the first one is this. So there's obviously OP group, which was discussed a lot yesterday. So I changed this talk now to focus more on data sig verify. And then at the end, I'm just going to show a little bit of OP group stuff. So OP data sig verify, the basic idea is the blockchain and scripting is kind of useless if there isn't a lot of data. I think I haven't reviewed Dr. Wright's paper, but he just released a paper I think showing that the scripting language is Turing complete. But what's the use of a Turing complete program if you have no data to use it on? So what OP data sig verify does is it allows you to import external data into the blockchain. So it basically uses the idea of an oracle or a trusted data source. We can't, every piece of data in the entire world can't be a consensus rule that's verified by every node. So you need the idea of an oracle. And so actually, when you really think about it, the idea of oracle versus consensus exists on a continuum. And I think you can kind of prove that they're the only options. So in the classic way, you prove something is you propose the opposite. So propose there are unknown untrusted nodes. So if one may lie, then another node may lie about that one lying. So therefore, all the nodes must validate and you get what we call a consensus rule. So as soon as you say that a node is not trusted, you're forced into consensus. Those are your two choices. But what's kind of interesting here is if you look on this continuum of trusted versus untrusted information, over on the left side we have oracles. And you could use information from multiple sources to increase your untrusted level. Pull in stock information from two or three oracles instead of just one. Now, emerging consensus I kind of put in the middle. It's kind of interesting because it kind of says, oh, there's some weird stuff that I don't trust going on in the network so I will trust the majority of miners. So that's why it's just a little bit to the right. And then headers first mining is a technique where you very briefly trust a miner before you receive all and validate the blocks so that is much further. And then finally, untrusted and consensus. OK, how much time do I have? Do I, am I up to 10.45 or? Oh, well, great, we're ahead. OK, so updates to verify sounds like just some really abstract thing and I don't think I've convinced you guys how it's going to help adoption. So I want to give you, I want to go straight to the scenario I see. First use case is peer-to-peer betting. So what I envision is you're sitting in the bar with your friends and watching the game and you want to make a bet. And of course, you know that if you lose, I mean, if you win, he's not going to pay because that's what always happens. OK, so what you do is you get him to install the Bitcoin Cash Wallet. All right, and then you can just pop up your phone, you set up a bet and then you tap phones and that bet will access data from the FIFA, you know, you're watching football as they call it around here, then it will automatically access a relatively trusted data source compared to the level of your bet. I would envision that FIFA, the NFL, all these people could just be producing signed data about what's happened. And what's really sort of awesome about separating these two things is that the person who's producing this data is not involved in your bet, right? Has no idea that it's happening. So this is probably, I'm not a lawyer, but I think this is very important from a legal perspective, right? And also he doesn't have custodianship of your money, right? That's also very important, yeah. So now if you move us, so like in the US, in most jurisdictions, so in the US, the ability to gamble is defined by the state. So it's a really confusing, more ass of craziness, right? But generally, person to person betting is legal, but what's not legal is like being a bookie or doing pools, right? So does anyone here, do people here know what fantasy sports are? It's like a US phenomenon. OK, so almost none of you know. So I'm going to preface this by saying, this crazy idea called fantasy sports is a $7 billion industry in the US, OK? And this is the idea, is you can't do pooled betting. You can't do bookies. So what you're going to do is you're going to convert sports betting into a game of skill. This is the trick, OK? So what everyone does is you get a group of people together and you basically pick your favorite, you do like a draft pick. And so you create your own team with your own players. And then every week, how your actual players perform in their games and how many yards they pass. It's football, of course, is what, yeah. American football is what is the most popular. And it's very statistics-based. So you can take all the statistics about how the players performed. And from that, you can actually kind of create a score of how your team would have performed, OK? And so there is, I think, 50 million people who do this in the US. And the entire reason why this game was created was because it's illegal to bet on sports in the US, right? So this is now not betting on sports because it's a game of skill because you're choosing your players, all right? So let's say we use op-datasig verify to, so first of all, you could use op-datasig verify in this fantasy sports to, again, to kind of make side bets or remove the flow of money into the fantasy sports site. You can do it sort of locally. And another thing is you could create a Bitcoin contract that would basically be a pool, which would pay out to multiply people, depending on which sports team won. And that is actually an interesting concept because in that case, who is the bookie, right? Who is the pool? There's nobody, right? So I wonder if that actually may be legal in many jurisdictions. All right, so do people know what binary contracts are? So binary contracts, I only saw one or two nods. If you're in the bar, it's betting. If you have a suit on and you're on Wall Street, it's binary contracts, right? And those are legal in the US, but one of the big problems is that a lot of times, in several cases in history, at least in the US, the company who underwrote the binary contract would suddenly disappear one night and a whole group would ensue. Because they would take the other side of the bet instead of finding matches. So what's great about this, again, is it's a peer-to-peer binary contract. There's no middlemen. Finally, for data-sig verify, there's this weird idea of op-code emulation, which I'll talk about later, and then prediction markets, which I'll talk about. So I'm going to talk about how you actually might make these scripts using this op data-sig verify. So this is going to get a little technical. So let's imagine that the Oracle is producing a data format, which is a, I just did it for a simplicity, eight-byte timestamp, which would be second since the epoch. That would be really dumb for an Oracle to actually use for a sports game, because who cares, down to the second. But just bear with me here. And then the match would be five bytes and the winner is two. So here we have yesterday, we had Argentina versus Brazil. I don't actually know who won, because I just wrote down Brazil. Because that's who I want to win. And so this, now, this might be something that you've never seen before. It's like a macro-assembler for Bitcoin script. I call it Bitscript. And I've been experimenting with it, yeah. So basically, I think it makes it a lot easier to understand what's going on. So macro-assembly is like me showing my age. Do you guys know what a macro-assembler is? OK, so almost nobody. So imagine this, there are no function calls, because there are no function calls in Bitcoin script. So every function that's defined just replaces the contents, just like a macro of the function inside the call. So here we're going to parse the data of the binary contract. And you have some input values. And then whenever I have the at sign data, what I'm defining there is I'm saying, OK, this is actually a parameter that exists on the Bitcoin stack. So you wouldn't actually pass that parameter, but you're sort of implicitly passing it because you're going to rely on it already being on the stack. So the very first thing we're going to do is we're going to split out the timestamp. And so by the way, this is the synergy of the new op codes that are being proposed with op-data-sig-verify. So op-split doesn't exist now, but Mr. Steve Shatters is proposing that we add it. So we're just going to break that. The first item in the stack up by the first eight bytes, and then the rest. And then we're going to verify that the first eight bytes equal the date of the match. And then we're going to split the rest of it into five bytes and two bytes. And that gets put on the stack. And so then we do equal verify that the match is Australia versus, I mean Argentina versus Brazil. And then we check that the winner matches the winner code. So this is a pretty easy way to check that, to kind of basically parse out this data. And now here would be the actual bet. So op-data-sig-verify takes two items on the stack, so the spender is providing these items. And that is the actual data and the signature. And then the vout offers the oracles address. And so now what op-data-sig-verify does is it validates that the signature is valid across that data for the past address. And if so, it pops the signature and the address off the stack, leaving the data. And so then having verified this oracle data, we're then going to run this decider function. And that happens to be this parse data one. So then we're left with who the winner is, true or false, if the winner. So then we just do op-if. And if that's true, then we'll pay the public key hash of address one. Otherwise, we'll pay the public key hash address two. And so then finally, all that comes together into this make-bet function. So that would create a Bitcoin cash bet. Now as I was saying, obviously, you wouldn't type all this. Every time you want to make the bet, some sort of wallet code would do this for you. So here at the very bottom, I show an actual sort of instantiation of this code into a particular bet. All right, so we're going from scripting with exactly two scripts that have ever been used, right? Paid a public key hash and multi-sig. And now we have all kinds of awesome scripts. So I just want to talk about some of the stuff you could do. So there's one big problem with the previous description of the bet contract. And that is like, what if, up in this case, here where I'm verifying the oracle's data, and I do op equal verify. So what if I screwed something up and I'm expecting the wrong data and the oracle is never going to, you know, I put in a match that doesn't even exist, right? So in that case, you would want some sort of escape clause that says, look, if no winner is picked, let's just call the bet a bad bet and get the money back. And so in the first formulation, I didn't do that. But we can just kind of add on to that, which is here's a bet with an escape. So it has everything in the original bet. And then a Boolean that says, do I want to just abort the bet? And so if I want to abort the bet, then, you know, in order to successfully spend that, you're going to do a multi-sig, you know, V out with the two participants in the bet, right? Both have to agree that we're going to abort the bet. And otherwise, you just do the normal bet. So to do betting pools, you would just have a big if statement that says up here. I have it all written out, but I decided it was too much information to show on the screen. But you just want to have other, instead of saying, just do I compare op equal to the winner, right? I want to say, OK, if the winner of the entire World Cup is Brazil, then pay out to this address. Otherwise, to these other people. OK, so all this stuff is entirely implementable with op data, sig verify, and the op codes that are proposed for the May hard fork. So I think I hope I've convinced you that betting is totally awesome and it'll work. So moving on to this other idea called op code emulation. So let's assume that you have this interesting function that you think really ought to be a new op code. But everyone else says, they're basically justified. Prove to me that this op code is going to be worthwhile, right? So what you could do is you could say fine. What I'm going to do is create a little service. And you give it the op codes parameters, and I will give it the output, and I'll sign it. And so yes, to use for now, because the op code is not added to Bitcoin scripting language, you have to trust this oracle to produce the right value. But given that you do trust that, you could basically emulate any stateless op code. Op chain height, give me the current height of the chain is not emulatable because that's data that changes every time. But what's the hash of a particular block, right? So for example, there's an interesting service, Faktum, which kind of creates a huge merkle tree of, it allows people to store information on the blockchain. So it creates a huge merkle tree of all that information. So to give an example of what you might think is what if Faktum now added a feedback loop and use op data to verify to allow anybody to validate, anybody to use any information in a script that has been stored into these Faktum merkle trees, right? And then if that became, so that would sort of also be an emulation of a new op code, which would be op get Faktum data, right? I'm not actually suggesting it's a really long road to think about bringing all of that data into consensus. But at the same time, it's just fascinating to consider how op data sig verify can allow you to sort of encourage people to try and use new op codes without having to create a whole new alt coin to make that happen in a lot of, like in my previous talk last year, I was also talking about how can we add new features to the blockchain without doing it on alt coins. And this is continuing with that idea, right? And that will ultimately increase the adoption of Bitcoin cash rather than creating competitors. All right, so there's always some question about how complex is this? So this is the entire implementation of op data sig verify. So my goal was to basically have the maximum impact for the minimum amount of consensus effort, right? And the reason why this is so simple is because it's using the ECDSA signature validation that has existed in Bitcoin forever, right? And so this code to the pubkey.recover compact, every time you do sign message or verify message in this case, right, you're calling that function. So this is, other than this little bit, the operation of this code is just extremely, it's not new, right, it's not novel. It's extremely stable. So please don't say, it's too much. All right, so let me move on to op group. We talked about that a lot yesterday, so I just want to do a quick summarize. So why do I think it'll be awesome on wallets? So it enables native tokens, and this is important because Bitcoin cash becomes the medium of exchange, right? Whenever you want to, if you have a stock or something, whenever you want to make a trade, you need to use your Bitcoin cash as the cash side of that, right? It's the only solution that is SPV wallet compatible. I don't think people are going to be holding stocks on their phones, right? But I think they're going to be holding coupons and tickets and all these other tokenization things. About three weeks ago, I went down to New York, and they have this app that lets you pay for their subway. And literally, you hold the app up to the guy, and you just show him that you have the ticket on your phone. And if you have multiple tickets, you show him that there's three. I was like, I could create a fake app in a day, right? And then get free rides for the rest of my life. I mean, this is a huge use case, not in New York. It was literally just this, but I promise you, I could figure out what the image was and then add it to my app, right? Just pull it, right? You need one person. Yeah, so having a token on your phone, right? And then you basically, you know, a Suica style touch an entry style, and it just does a cryptographic challenge and signature, you're done, right? It'd be awesome. And I just want to mention the original form of app group had only allowed unlimited minting, but I added a limited feature, and it pegged one token to one Satoshi. I removed that peg, so I just wanted to call that out to try to correct the impression. Yeah, so I think this is like the last slide. So this is our scaling philosophy. It's better for full nodes and mining nodes to be expensive, and people can use SPV wallets, right? And that is what app group allows you to do. So app group is aligned with our scaling philosophy, not unaligned. Oh, and I just don't want you to really look at this closely, but last night, people are asking, how well-baked is app group? So I just ran through here the CLI commands to create a new token. I got a few addresses. I sent Bitcoin cash to the address, and then I minted at the very bottom. I minted 1,000 tokens down there, and then this is the output of it. So this is the actual, yeah, so it's actually the first one. Script pub key, it creates, so that first long line is the group ID, and then there's the quantity of 1,000, which is what we minted. So it's all kind of there, and here's how you do a limited supply. You just call single mint, and it gives you the group identifier and the transaction. And then here's what the single mint vout looks like. So this is pretty well-baked at this point. Oh, and people kind of ask about, can I do this with app group? And one common thing is, can I have scheduled token releases? The answer is yes. So you do a single mint, and then when you pay to certain outputs, you use a checklock time verify to say, okay, this output can't be spent until after a certain time. So that's an easy solution. So are there any questions? Is there time for questions? You have time for... Let's give him a round of applause. Thank you, Andrew. We have time for two really awesome, probing questions. Thanks, so, hi Andrew. On the update us to verify, I see I didn't look too much into it and at the risk of bug shedding, but you do the hashing after you cover the public key and wouldn't it be better to basically just do the minimum thing and update us to verify? Are you saying there's a bug in my code? Is that, are you saying there was a bug in the code I put up there? Can you just go back to that code slide? Maybe we should debug this offline. No, no, no, no, no, no, no, no, no, no, no, no. It's very quick. Okay, okay, okay. So tell me when to stop. The code page for update us to verify. So, next one, I think. Next one? Next one, next. Oh, the C++ code. Yes. Okay, right here. Yeah, so at the bottom you, after you recover the public key, you do the hash, the 160 hash. Can't you just not do that and do it in the script? So the script, oh, you mean, yeah, so call, yeah, so call op hash 160 in the script. Yes. Yeah, I suppose you could, yeah. Great, now we figured that out. Thank you. All right, we're out of time for our next presenter. I'm sorry, Andrew. That's okay. Okay, great. All right, thank you. Give it one more time for Andrew Stone, please. Thank you.