 Our next presentation in OGGB3 today, we have Rusty Russell presenting Petticoin towards 1.0. Please make him feel welcome. Okay, I'm going to warn you up front, this is going to go very, very fast and the reason is that we've got some little bit of background, then we're going to go on a massive detour that actually turns out to be about 80 or 90% of my talk. There's so much in there that I have to cram a whole heap of stuff in slides called caveats and notes. There are eight of them I think. I will just flash them up on the screen for those watching the video version so they can pause it. For the rest of you, we will keep on moving. Okay, so I hope your brains are ready. I hope you've had your coffee. I hope you're all energized before lunch. When we've had that detour, we'll come back and talk about what this means for the Petticoin project. Okay. Now, OpenOffice also crashed several times previously when I tried to display this presentation. I have my gamut doll ready. Thanks to my wife for that. Okay. So Petticoin is trying to solve a problem and the problem is that Bitcoin money is expensive. There are a lot of machines using up a lot of resources trying to mine coins and at the moment there, that money is paid for by inflation that is set to end at some point or at least a minute show of the time. So the mining cost actually places a lower limit on how cheap transactions could be. If you're a miner and someone offers you even a tiny, tiny amount of money to include their transaction, the marginal cost, if you include that transaction is almost zero, so you're likely to take it even though it's not enough to sustain the network. It would be nice if we had an alternate mechanism. So you could say, I'm not going to accept that, but I will make some money if you use it over here in this other network, which is especially reduced and cut down but can handle tiny, tiny transactions. So that is in a nutshell what Petticoin is trying to do. And this sounds like a fun project to me because it's the horizon of when this will become a problem is a long way off so no one else will be interested. And it's just kind of a toy thing. And it turns out my wife said I'm actually much nicer to live with when I'm working on fun projects. So she told me I should take a six month sabbatical, which I did. I took six months off of which one month was vacation and one day a week was looking after my son Marcus. So basically four work months of hacking on Petticoin and a few other related things. OK. And this is what Petticoin looks like, Petticoin.org. There are functionaries that gateway Bitcoins to and from the Bitcoin network. Now I'm assuming you know what Bitcoin is, otherwise you're in the wrong room. So you send money to the, you send Bitcoins to the gateways, the gateways pop out, Petticoins on the Petticoin network. You play with them there. You send them back to the gateway on the Petticoin network and they come back onto the Bitcoin network. It's limited to small amounts for several reasons, mainly because I don't like real money and also the name Petticoin kind of implies tiny, tiny transactions. The transactions were vastly simplified. They were probably oversimplified, but they were about as simple as you can get and still have a working system. It had a horizon. So after one month you could no longer use your transactions. They got spat back by the gateways onto the Bitcoin network. So it didn't, it didn't store value. This was simply a transfer network. And in relying on this idea of partial knowledge, in the Bitcoin world, to be a contributor, you have to know every block and every transaction. There's every unspent transaction output. The idea was that as long as one honest person knows each part of the network, then you can be fairly assured because they have a way of complaining if they spot something wrong and proving it compactly to everyone else. So you can survive with partial knowledge. You don't need to know everything. It also had this idea of payback. The idea was that in some number of years time, 25% of profits from mining would be channeled back to people who were mining in the bootstrap phase. So this is basically taxing the future to pay for the present, which is a real problem when you're trying to bootstrap something where you can't just generate your own coins because you're using real bitcoins. And while I was implementing this side to side, hey, while we're here, let's do fast block times because, you know, that's kind of cool. And that was tacked on the bottom. Okay, now a little bit about this kind of project. There is a name for Bitcoin-like things that aren't Bitcoin. They are called altcoins. And most of them look a bit like this. They are almost entirely incredibly dubious. And I went through the dot-com boom, but it is hard for me to explain the level of noise that these things create. But I'm going to supply you with one data point so you can get a feel for the orders of magnitude of noise that I'm talking about. There is a forum called bitcointalk.org where most people hang out. And that forum contains an announcement section for altcoins. That is the number of posts on the forum. Oh, it just went up again. This level of noise makes it really, really hard to find people who are genuinely interested in innovative ideas in this space. And if you do find them, it's really hard to get through that level of noise to talk to them. And this turns out to be a significant problem in the larger Bitcoin ecosystem. So I had been developing Pettycoin, hacking away, having a hugely fun time. I'd released Alpha 1 and I'd announced it on altcoins announced because it seemed like the right place to go. Then I'd released Alpha 2 and I hadn't bothered announcing it on altcoins announced. It was all going really, really well when it was six weeks to go, Blockstream released their sidechains paper. And sidechains, the sidechains paper describes how you should do something like Pettycoin. We're using real bitcoins and you're creating an alternative. Damn it, doll. Okay, so my talk is really about what I should have done in my sabbatical and this will involve a slight detour. But I'm going to explain what the sidechains paper is. Now, in order to do that, I'm going to have to explain something about Bitcoin and how it works today. Then I'll talk about how sidechains are supposed to work and some other partial knowledge ideas that came along from similar kind of sources. And after this detour, we'll talk about what this means for Pettycoin. Okay, Bitcoin basics. There are only three things you really have to know. The first one's easy. Who knows what a cryptographic hash function is? Good, then we'll go through this really quick. You take some data, it turns it into a number. Hi, Rusty there, produces that number, 78-digit number. No two things hash to the same value, so we take a lowercase h, we get a completely different 77-digit number that looks like that. And importantly, there's no way to take that number that is the result of the hash and go back and figure out what they hashed, except by brute-forcing it and trying every combination. That is everything you need to know about, okay, here's my first caveat to notes and all the lies that I said. But anyway, that is all you need to know about cryptographic hash functions. Bitcoin blocks, they look like this. They have four four-byte fields and two 32-byte fields. Each of those 32-byte fields is one of those hash values that we talked about. These gather up transactions that go across the network, and that's in the TXs field, hash that you can see there, and they chain together. So that PREV field is the hash of the previous block. So to generate block 1000, you need to know the hash of block 999, which needs to know the hash of block 998, et cetera, et cetera, all the way back to the block zero, the genesis block. So these form a chain, and these are really, really hard to make. They're hard to make because the hash value of this block itself has to be a really small number. The only way you can generate that hash is by trying, trying a whole heap of different variants. Okay, that's everything you need to know about Bitcoin blocks. Transactions, I said that the transactions are crammed into that hash in the header. I'm going to actually go through how we actually do that. So let's say we have these four transactions here. First, we hash all of them to turn them into canonical numbers, and then we take the adjacent pairs of hashes, concatenate them together, and hash that, giving us another hash. We do that for each neighbor, and then we take those two hashes, concatenate them together, and that forms the root of our tree, and the root of our tree is what goes into the header. So it's a tree of hashes. This has a particular name, and it's called a Merkel tree. Sorry, it's called a Merkel tree after Ralph Merkel. So there's a picture of Ralph. Now, the transactions themselves, which go into the blocks, have inputs and outputs. They take money in and they say where it goes. Okay, obviously the value of the inputs has to be greater than or equal to the value of the outputs. You can't spend money you don't have. Importantly, each output can only be spent once. So if you don't want to spend the whole output, you take it as an input, you produce two outputs, one of which goes where you want to, and the rest is a change output that goes somewhere that you control, presumably. Okay, now this is not quite true about the value for the first, the very first transaction in any block has a fake input, and it's the one that actually generates coins. That's how miners get paid. They generate coins. So that's the only exception. So let's take an example. Outputs actually have an amount and a script. So the amount was something like, I'm worth 30 bitcoins, and here I am paying this 30 bitcoins to Alice. So any transaction side by Alice can redeem this, and an import looks like this. It says, here's the transaction I'm trying to spend, identified by its hash value. Here's the output number of that transaction, because it might have several outputs, and a script that basically says, hi I'm Alice and I endorse this transaction. Okay, we're going to actually use a real example here. I went back to block 300,000, which was mined back in April last year, and I just want to side note, to note that this hashes to this value, which is only 48 digits long. Remember the last one was about 78 digits long? So at the top of your head, you could say the chance of generating this randomly is about 1 in 1,000 trillion trillion trillion. So pretty hard to generate. Block 300,000, transaction zero looks like this. I'm going to refer to it as 9399 from now on. It has one output, output zero, and an amount of 25 point a little bit of bitcoins. 25 is the block reward, and the rest is the fees gathered from the other transactions that have been mined in that block. Okay, and it has an output script, and the script looks like this. This is the bitcoin scripting language. I'm going to go through what that script looks like in a sec, but first let's look at where this is spent. It was 588 blocks later, that transaction 1577 spent this. And that was actually quite a big transaction. It had a lot of inputs around 50, and it was input number 37 that redeemed that output of 9399. And it said here's the transaction I'm spending, and it's output number zero, which is the only output of that transaction. And here is the input script that was attached to that. Basically what this is, is pushing a signature and a public key onto the stack. So the way you evaluate this is you evaluate the input script first, that's supposed to set things up, and then you evaluate the output script that's supposed to verify that the input is correct. So there's our stack, and that was our output script. The first thing it does is duplicate the top entry on the stack, and then it hashes it. Then it pushes this literal number on the stack, and then the next thing says, are those two equal? This is a complicated way of saying, is this the right public key? Is this Alice? Who's redeeming this transaction? Okay, and if it's not equal, it will abort and fail. It is equal, so I'll post them off the stack. And the last operation is object sig, that says, make sure this transaction that is trying to consume this output is actually signed using that signature by the private key corresponding to this public key. Indeed that succeeds, so it puts a one on the stack, and the rules for the Bitcoin script if the script finishes executing and there's a non-zero value on the top of the stack, it succeeds. So that way we know it's all good. Okay, there are a few notes on this, especially nomenclature and things like that that if you're reading further, you'll need to know. Okay, now we know everything about Bitcoin. That was easy, wasn't it? Let's talk about side chains. Side chains are alternative chains that use real Bitcoins. And importantly, they can have different rules. This allows you to do experiments and crazy stuff that you wouldn't necessarily want to do with the nicely working Bitcoin network and try things out. Or you might just have different ideas. Now, before we pursue this, I'm sure some of you are thinking, hold on, having another, promoting another system like Bitcoin is a huge environmental waste. I mean, isn't this a more wasted work? You've got another chain, got to be backed by another huge rigs of machines that occasionally burn up to spectacular photos that end up on Flickr. So isn't this a lot more wasted work? If people are going to use more side chains, doesn't this mean more waste? Well, here's my second detail. Actually no, because Bitcoin miners can mine other chains at the same time. Now, how's this done? Well, remember that we hash all our transactions into that block header for Bitcoin. And remember that our transaction zero contains a dummy input zero. Because that's the one that just generates coins. It doesn't matter what the input is. We can put whatever we want in that dummy input zero. So we could put, for example, the hash of our side chain header. And that is just as much a proof of work that you have verified the side chain header as it is of the main Bitcoin header. It's just as good. The fact that it's in there at all and you can prove it's in there is good enough. Okay, now how do we prove it's in there? Well, if we know the side chain header, because I've said this is the side chain that we're mining, you can hash it, obviously. You can check if I give you the transaction that the hash is indeed in that dummy input and you go, yes, that is there. If you know the transaction zero, you can generate its hash. And here's the trick. All I need to give you is the hash of transaction one. Not transaction one, just this hash. And then you can calculate what the node above it would be. And then I need to give you the other hash that's its sibling. And then you can calculate what that transaction's value should be. So even if you've got a million transactions in this tree, 20 hashes can prove any of those transactions are definitely in that tree. Okay, of course, you're probably doing more than one side chain because why wouldn't you? And the question is, how do you fit a whole heap of side chains in your dummy input? You could put four hashes in there. You could put 10 hashes in there. It could get bigger and bigger and bigger. Or you could use a Merkel tree. That's right. So we use a Merkel tree to put chains in there. Now, this turns out that all the things in green are the things you need to prove that that side chain is genuinely in this transaction. Because from that, you can derive everything else and figure out the tree. And because it goes up by log n, it scales really, really nicely. So this is really, really useful. Okay, so side chains, we can merge mine them. That's great. And they can have slight variance on the rule so you can play around. Okay. And here's how they work. The idea in a nutshell, there are special Bitcoin transactions that say, send this output to the side chain. Now, this idea has been around for a while. Special transactions that are no longer valid, so you can't use them as inputs on the Bitcoin chain, but you can interpret those to, say, send them to the side chain. But then there's special side chain transactions which can send Bitcoins back to the Bitcoin network. And that's the new bit. We couldn't get them back previously. And then all you have to do is prove to the Bitcoin network that the return really did happen on the side chain. And if you do, Bitcoin will let you spend those Bitcoins again. So they're locked up until somebody proves that they've been sent back. And if you've got that, you've got a method of sending Bitcoins to and from an ultimate chain. Okay, let's go into that in some detail. Send. We don't know exactly what this will look like because it was proposed in fairly hand-wavy terms but my guess is something like, here's the hash that I'm sending to op side chain proof verify. And that was specified in the paper that that would be the op code. So this is an output. And on the side chain it goes, hey, look, Bitcoin just sent us a new op side chain proof verify. It waits for a little bit to make sure that it really is well established in the Bitcoin network and not likely to be overridden. The same way you'd normally wait, say, six confirmations for a normal Bitcoin transaction, you don't want this to be undone because that would be a little bit disastrous. So you wait for some time, hand wave, and then you use it like any other unspent transaction. Anything, any unspent transaction on your pedicoin on your alt side chain, say pedicoin, you could spend, but now you can also spend the one that came in from the Bitcoin network. Great. Things move around, you do whatever it is that your side chain does. Some say somebody creates a special unspendable output on your side chain that returns funds to the Bitcoin network. There are some caveats. Okay, so this is what it looks like. This is our side chain. There's our return to Bitcoin transaction output in a transaction in block N. The side chain has moved on to N plus three. Okay, now, this is the hard part. We have to prove to Bitcoin that the side chain really does have that return to Bitcoin transaction accepted. Okay, so we have to prove that the transaction is in block N and then we have to prove the block N is in the side chain. If we can do that, then we can convince the Bitcoin network that it really did accept that transaction and that we should get the bitcoins back. Okay, well, how do we prove the transactions, whatever it is, is in that? Of course, we use the Merkle proof using our Merkle tree. So that part we already know how to do. How do we prove the block itself is in the side chain? Well, remember, each block does have the previous block hash. So we could provide every block all the way back to the genesis block at the beginning of the side chain and go, therefore, this block is in there. The problem is that the Bitcoin network, for example, produces around 50,000 blocks a year, so that ends up being quite a big proof fairly quickly. There is a solution, however, called a compact SPV proof. And to understand this, you have to understand that blocks are generated by a random process because there's no other way to figure out how to hash what something will hash to, other than by trying it. So you basically just keep trying things until you get something that's below the target value, then it's a valid block. Well, that actually means, statistically, half the blocks you get will be twice as good as they need to be, and a hundredth of them will be a hundred times as good as they need to be. The hash value will be like a hundredth of what you needed. You don't care how overqualified they are normally. And this is an inevitable statistical consequence of the way blocks are generated. Now, here's the trick. If you say, instead of skipping back one block, if you are n times stronger than you needed to be, or n times luckier than you needed to be, you can skip back n blocks at once. It turns out that that gives you roughly log n blocks steps back to the genesis block. And it is just as hard to produce a chain which has all these lucky blocks as it is to produce the full block set. Because the 100 ones are a hundred times harder to produce. So producing this log n chain is just as hard as producing the whole thing. So it's just as much work. Now, the problem is, we've only got one previous block in the block header. How do we put a whole heap of hashes in the block header? Merkle tree, that's right. There we go. We put all of them in using a Merkle tree. Now, approximately, say you've got one million blocks, you've been running for about 20 years of the order, and there's a huge variance here. Say you have to supply about 60 block headers and 550 Merkle proof hashes in order to get back all the way to the genesis block. There's some ongoing work that I've been doing trying to get that number down, but that's a rough idea. And there are a huge number of caveats involving this. Okay, so here we've proven to Bitcoin that indeed the side chain did accept this transaction returning stuff to Bitcoin. The problem is this can happen. Either this happened originally and we lied and we just made these blocks up. And the real chain was all the way down here and it's way longer. And the longest one always wins because the most work wins. That's how the system works. Or actually we got unlucky and someone mined this out here underneath us and forked away from us. This is a problem because it means the side chain no longer contains the transaction anymore. So what we have to do is we have to wait a while to give someone the opportunity to provide a proof that there is something longer that does not contain the transaction. This is called a reorganizational proof. So someone can provide a reorganizational proof. Okay, and there are some issues with how this would actually be done. Okay, now there are three main problems with ops side chain proof verified and the first one's fairly obvious. Adding a new opcode to the Bitcoin scripting language will fork the network. All right, it forks the protocol. You've got the old ones that don't understand it, the new ones that do, right? Okay, well as long as old clients still see the transaction as valid, that's okay. They'll go, you push something on the stack, you do something, and as long as it still works out to be okay, even though they don't know what it means, at least they won't go off and fork the network on it. For example, the proposal would be to rename one of the new ops. So we'll just go, I don't know what that means but I won't do anything. Oh, look, there's still something on the stack so I accept the transaction. As long as a vast majority of miners are actually understand the whole thing and are checking the full thing, this works. There is a term for this and it's called a soft fork. When I Google for soft fork images, this is what I got, a picture of a soft fork. Now, I think they're slightly optimistic. They suggest this will take six months plus, I think probably a little bit longer, but other than that, this diagram is incredibly useful. It's also extendable soft fork. Very good. Okay, the other criticism of ops sidechain proof verify is this is expensive. You've got to prove that the sidechain included your particular transaction that was coming back. If you do the numbers and you assume it's a merge mine sidechain, it has to include all that information that we had in green on our diagram. It could vary but roughly it's about half a K. Each hash is 32 bytes so you're talking about transaction proof that's tens of kilobytes in size. Bitcoin network generally charges by the kilobyte so that's quite a big expensive transaction. So it's going to cost you a reasonable amount to move bitcoins back. The other issue is that it's going to be slow. You probably need a decent confirmation period so you want to say in order to send, to prove something to Bitcoin network about what happened on the sidechain, the sidechain has to be a lot longer so it's deeply buried. We don't want you to bother us with stuff that isn't definitely in the sidechain yet. And then, so that's probably about a day, you're going to say it's got to be a day old in the sidechain before you can even send it to us and you've got to wait for that to propagate to make sure that nobody out there knows of a longer chain. That's probably another day at least. So the speed of this redemption is of the order of days. The paper however, in one of the appendices, suggests a clever way of getting around this, assuming that you have a liquid market. It's called an atomic swap. So say Alice has a petty coin and Bob has a Bitcoin and they agree to swap them. So Alice puts on the petty coin network, okay, this is the output. And the script says you can redeem it by revealing two things. One, Bob's signature, because that's what I'm trying to pay. And two, a value that hashes to this value here. So Alice has chosen a secret value, hashed it and puts that value here. So Alice has the secret, okay. That goes out on the petty coin network, buried under a few transactions. Bob's pretty sure it's nailed in there. There's one thing that Alice also needs to do in case Bob vanishes at this point and says, otherwise after 48 hours I can have my money back. Thank you very much. Okay, now Bob does the same thing on the Bitcoin network. Bob says, okay, to redeem this one Bitcoin, you have to be Alice. And you also need that magic value, the secret value that Alice knows that hashes to X. Or I can have it back after 24 hours in case Alice goes away. Okay, now what happens here? So Bob's has gone out on the Bitcoin network, Alice has gone out on the petty coin network, they're both well buried. When Alice wants to claim that output, that one Bitcoin that Bob's offering her, she has to spend the output. In order to do that, she has to reveal that value she chose that hashes to X in her transaction. The input script will say, here's the value and here it goes. And then Bob, of course that reveals to the world what that value that hashes to X is. So Bob can now use the same value to redeem Alice's transaction. Yes, question? Yes, so that is the same X. That is the same hash of that secret value. So Bob didn't know what it was when he wrote the transaction, saying you have to hash to X. He just knows what X is, he doesn't know what the thing that hashes to it is. Because hashes can't be reversed. There are a few caveats on this, particularly it needs bit 62 or bit 65 in order to really work well. But those are coming. Okay, now I just want to pause for a moment. Thank you. And I want to point out how many things went into making sidechains possible. First, we had Merkle trees. Well, they've been around for a long time. They were in the original Satoshi design. That's how transactions are encoded in a block. We had merge mining, which I could find references saying that it was due to Satoshi originally. It's been done since at least 2009 by Naincoin. So we've had merge mining for a while. We need a sophisticated scripting language to allow stuff like atomic swaps and to have a scripting language to extend. In fact, we need more sophistication in our scripting language. Particularly nice would be bit 65, which was only formally proposed last year and is likely to be introduced fairly soon. We need soft forks. Now that is a technology. It's something that has been done three times so far in the Bitcoin network. And as I said, there's another few that are probably coming up. But you need a degree of confidence and experience to have done this before to even consider introducing something like side chains. The fact that we've done it three times before and the Bitcoin network hasn't fallen apart gives us a degree of confidence that this could be done. The compact SPV proof idea traces back, perhaps to the post referred there. It's been refined since then. But this statistical feature of the blockchain is another important idea. And then atomic swaps in 2013. This was suggested in a slightly different context. So all this work has been done that culminates in this side chain's idea. So when if you see the Bitcoin, particularly given the level of noise in the Bitcoin, the altcoin community, you don't see any of this progress happening and all of this stuff is happening behind the scenes. And this is just the subset of ideas that were required to make side chains work. That is the end of my detour. Yeah, thank you. Now this side chain's paper had a second side effect. And that is that I finally found the people who were actually thinking about these ideas and ways to enhance Bitcoin and weren't just running scam coins. And there are a whole heap of them there. I'm only going to have time to go through three. Most of them come from Gregor Maxwell's page here. And you can see a more detailed discussion of each one in the Petticoin Revisited Series on the Petticoin blog, breaking them down in detail against Petticoin. But I do want to point out this idea of partial knowledge. So the idea that you only know part of it, but as long as it's between us all, we have coverage of everything, we can prove to each other if we find a problem. One of the problems is, is the miner collecting fair rewards? If you know every transaction in Bitcoin, you just add them all up and go, yes, your output should be 25.049 Bitcoins. But of course, if the miner says, no, no, there was a really, there was a 28 Bitcoin fee in there, no really, how do you prove it? If you don't know all the transactions, how do you know that one of the ones you don't know is actually the huge fee that they're claiming? In Petticoin, we cite this all together. We use a lottery system. You basically pick a random transaction, you show this is what the random transaction is, and you multiply that by the number of transactions, and that is the mining fee. That works statistically, but it gives incredibly high variance. There is a different way of doing it, and that of course is using a Merkel tree. It's a slightly different Merkel tree because as well as hashing the transaction itself, you have the fee. So you have the hash of the transaction and the fee value. And for every parent, of course, you combine, you hash all those, combine them together, and rehash. What are we doing? But you also add up the fees. So in the root node, you've got the sum of all the fees, which is what you want. But you've also got a provable path. You can show that your fee got added all the way up. And as long as someone's checking each of these root nodes, between you, you can prove that there was no cheating going on. So that's a much better way of doing rewards. The other classic problem is that a miner mines a transaction, and in it it says, no, no, no, I'm spending a million Bitcoins that came from this other transaction you haven't heard of. If you have, in Bitcoin that can't happen because you know all the transactions are going, it doesn't exist. If you have partial knowledge, you now have this problem. You don't know that that transaction doesn't exist. And even if you did know everything, you can't prove that to me that it doesn't exist without telling me everything. And that's not partial knowledge. That means everyone has to know everything. In Petticoing, we solve this in that the miners attach input references. So they have a transaction, but they also include, and this is where the inputs were previously in the chain. So it says 28 blocks ago, transaction number 50, that's the input they're using. Because remember the transaction only says the hash of the transaction it's using as an input. So it also has all these references. So this is where I found them. That way, if you're lying and there wasn't really a 1 million Bitcoin output, I can prove that. Because I can go, no, no, here's the proof. 58 blocks ago, here's transaction 38 or whatever it was, and it does not have a 1 million Bitcoin output. And so I can compactly prove to everyone that you're lying. Okay, there is a different way of doing this called unsigned transaction output commitments. Remember, you can only spend a transaction output once, which means Bitcoin basically tracks all the unspent outputs because that's all it needs to know. And if you're spending something that's not in there, you're not valid. So it tracks those as we go through. The idea is to put that whole set of unspent transaction outputs into the Bitcoin header. How do we put a whole lot of information into the header? Merkle tree, that's right. We use another Merkle tree. Okay, so for each input, you attach a proof that that input was in the unspent transaction output tree. And for each output, you attach a different proof showing where it would go, which tells you how to update the transaction tree for the next transaction. So similar to the other example, you put in the transaction, but you also put in a selection of proofs for each input and output. And these should all chain together, right? So if you've got two neighboring transactions, this one, you can look at these proofs, that will tell you how to modify the tree, and the next one must apply that. So if you know this unspent transaction output tree, you know everything you need to know to verify transactions. And you can check any individual because you can check that it proves that it is indeed in that tree using the Merkle proofs. There are some notes on this. It's not quite that simple, but you get the idea. Okay. The second last thing I want to talk about is proving double spends. In Petticoin, what we do is we go rely on somebody going, hold on, you can't spend that because here's the transaction from before, insert proof, that's spent already, so go away. With unspent transaction output commitments, you can't do it because you have to prove that it was in that tree. Okay. That's cool. Now, the other thing I said that I did was fast block times because one of the things that's seen as a problem with Bitcoin is that 10 minutes is quite a long time to wait. It's very conservative. So I went for 10 second blocks, which is about as low as you can push it and probably it's a little bit lower than you can push it. But even with that, because of the way things are generated, you get this exponential decay curve. So 1% of blocks take over 46 seconds, which is the Bitcoin network, about 1% of blocks will take more than 46 minutes to generate. That's a long time to wait to pay for your coffee. I calibrated the 10 second thing by standing at the checkout and counting until I got frustrated. And that was about five seconds. So I said 10 second block time gives you an average of five seconds, right? So there was a proposal that I posted to suggest that you'll take a quarter strength block if you haven't had a block for 20 seconds. And there's a modified heuristic to determine which of the blocks, when you get multiple blocks, you should take to get the one closest to the 20 second mark which turns out to be important. You can find that posted here. And of course, there are a couple of issues with this that you should go into. Particularly don't copy the way test net does it. It's deliberately not secure. Apparently one L chain did. Surprise. Everyone lost their money. Okay. So what does all this mean for petty coin? Well, yes, it means that the world has moved on. It means things have evolved. Basically, in order to be a sidechain, you need to be more Bitcoin like, both because you'll need to understand Bitcoin to see the transactions coming in. And it must understand you so that you can prove that the transactions came back. Which basically means you should just use the Bitcoin reference code, although it's in C++. Rather than re-implementing everything yourself. Because I expect there to be quite a few sidechains, I wouldn't be all that surprised if Blockstream themselves end up releasing something like a sidechain development kit to make this really, really easy. Although they may not. There'll certainly be other sidechains to copy from. The cool thing about this is we now have a name for what I built. I don't have to say explain to everyone, no, no, it's not an altcoin. It's the same way basically in the Bitcoin world, saying no, no, it's not a scam. Take your hand off your wallet. But it's now a sidechain. And now a lot more people know what the hell that means because that word didn't exist when I started. So we might call it my petty chain, for example. And I think the fast chain idea, while interesting, might as well be a completely separate sidechain experiment. Just do that and isolate it rather than piling it on. And that basically is the conclusion of my talk. I do want to thank several people. I want to thank my family for putting up with me ranting about hashing and crypto and everything else for the last six months. I want to thank Robert Collins for a lot of the early brainstorming on the petty coin idea. The Bitcoin wizard, especially Gregory Maxwell, who explained this stuff to me in little words because I couldn't find a good presentation on it. And I definitely want to thank IBM for letting me take six months off to do something I didn't quite know what I was doing. That's OK, I didn't either. I do thank them for giving me a six-month sabbatical. And of course, my man crush here, Ralph Merkle. Some questions. I can repeat the question. I've been listening to a bit of a chatter between the sidechain and tree chains. And I thought you might mention tree chains. I just wonder what your opinion is. So when I started my sabbatical, I was devotedly reading everything about Bitcoin development and everything else. At some point, I realized that that's an infinite well. And I should stop reading that. And that was about when tree chains became a thing. So my exposure to tree change is kind of vague. There is certainly a degree of chatter between the two groups. Sidechains, I think, are a... Sidechains are what I was trying to do, so I'm probably biased here. But tree chains are definitely something that could be done in the sidechain, for example. One of the big selling points of the sidechain's paper was basically what this does for Bitcoin, which is incredibly important because you're trying to get Bitcoin to change. And it basically says, you can now do crazy experiments and prove that they work without having to convince people before you've done them that they should be accepted into Bitcoin. So you could argue that the sidechains enables a whole heap of innovation, including perhaps tree chains, if people decide that is the way to go. Additional questions? You said you're going to rename the NOOP. Wasn't that way there's a limited number of sort of things that you can do? Yeah, so the question is if you start renaming NOOPs, don't you're going to run out of them? Yes, there are a fair number though, so you take the last one and you'd rename it perhaps into a combination NOOP and do things like that. One of the soft forks didn't actually use the rename NOOP technique, so there are other ways. You can say, well, this particular magic pattern actually means this rather than what it looks like. So there are other ways you can do it. Renaming NOOPs is probably the cleanest and simplest, however. Still time for more questions. I could have gone slower. So there's a bunch of code here. Like you've actually developed a huge amount of stuff within that period of time. I mean, how much of this is re-usable if you re-implement it using the sideshade? That is a really good question. How much of the code is re-usable from what I do with Petticoint? So this is actually a key argument. So I looked at Petticoint and I went, what am I going to do if this thing takes off and I actually have to support it? That was a what-of-what led into my decision to write everything from scratch because the standard thing of taking the Bitcoin source code and filing off the serial numbers and changing a few things meant there were going to be whole swathes of that that I didn't understand like the back of my hand. The good thing about that approach is if I ended up as one expected throwing the first version away, which is what I'm doing, then at least there would have been another set of eyeballs on the Bitcoin code. At least then I'd be in a position to have mastered that, which is probably much more useful than writing my own code over in the corner. So in retrospect, I should have thought more about the failure case. What am I going to get out of this if Petticoint bombs? And in that case, it might have swayed me more towards reusing some of the Bitcoin code. The other thing that's really important is everyone thinks about Bitcoin, the protocol and the hashing and the proof of work and all that stuff. There's a lot of other stuff that you actually need as I discovered when I implemented this. You need the network protocol. You need a peer-to-peer bootstrap system so people can get this. While that was fun for me to develop, it was kind of a bag on the side of all this work. And it's interesting to develop a peer-to-peer protocol. I recommend that you do it at least once, but not necessarily incredibly useful. So yeah, it is disappointing to kind of get to the point where I go, okay, I'm shutting down the Petticoint network. Thanks, especially my one user who was out there faithfully reporting bugs. That's how I know I had a user. But yeah, it is kind of disappointing to get to the end of this. Now, on the plus side is there were a number of C-CAN modules that came out of the Petticoint work. So at least some of the code will live on. But as a general rule, that will stay up and get up and write, like most other code. Question at the back, Marko? No? Sorry. Tim? 20 seconds is still like an infinite amount of time in the computer world. Is there any thoughts about getting this into the millisecond type range? So you need to put the question about timing. So it gets really hard. So the problem is the propagation delay. So the shorter your block time, the more likely people are to produce blocks simultaneously. If they produce blocks simultaneously, at some point, one of them has to win. If there's long delays between producing blocks, that happens pretty naturally. You and I both produce blocks. One block will get extended before the other one. One of those will win. The shorter that time is, the more likely that we will fork. The more we fork two things. If we never converge, then you never quite know what the answer is. There's no point having really short block times if they never converge because you're waiting for convergence to make sure that this payment really did come in. But the other problem is that if you're always running five forks, then the effective strength of your network is a fifth of what it would otherwise be. So you've been wasting four fifths of your hashing power. So you do need variance. The question is how much? And it involves propagation delay. You also have to worry about various miners trying to game the system and things like that. So it gets a little bit more complicated. You also worry that it reduces incentives to include transactions because transactions make your block a little bit bigger, the amount that you have to transmit. If you're really in a very, very hard race against other blocks, you might be creating a disincentive for people to include transactions, for example. So you might be defeating yourself there. So there was a proposal called Ghost that I referred to in the caveats where you choose the most popular chain based on its siblings as well. You kind of go, more people have obviously seen this because they're producing brethren of it. Therefore, this is preferred over this isolated fork over here. That seems to help a little bit. They talked about going down to one second block times. That is seen as ridiculously aggressive. Well, on the other hand, I haven't seen anyone seriously try it. But when we're talking down to milliseconds, that's actually really, really hard. What in practice people do, and as a workaround for the 10 minute Bitcoin thing, is that they use various heuristics to say, I think this is going to go into the next block, so I'll accept it. Because honest nodes are supposed to take the first transaction they see if there's a conflict. But of course, if the second one has larger transaction fees and you're a miner, which one are you going to take? So relying on the goodwill of miners, that basically becomes a fraud protection and risk game at that point. And a lot of economic games then start to take place rather than relying on mathematical ones. So I prefer to stay out of that. But that's basically what people are doing at the moment. It's all except zero unconfirmed transactions because usually they work. So this will be our last question. My questions for the audience. Show of hands here. Everyone who thinks Merkel trees are the best thing you've heard all day. Yay, thanks Rusty. Do we have another one? Yeah, I probably do have one. They're all through my presentation. Oh, there we go. Thank you very much.