Okay, in this lecture we're going to be talking about Bitcoin as a platform. So we spent a lot of time developing all of the technical underpinnings of Bitcoin and showing how it can be used as a currency. In this lecture we're gonna be talking about what else we can do with Bitcoin. There's a lot of exciting things we can build, either without any modifications to Bitcoin or with pretty small modifications. So some of those things in order that we'll talk about in this lecture, secure commitments, secure time stamping, issuing new types of digital tokens. And tracking those things that aren't exactly currency, doing lotteries, generating randomness using Bitcoin, and finally prediction markets. So as a bit of a warning, these ideas are a little bit disparate. So there's gonna be a lot of different things going on in this lecture, a little bit of a stew with lots of different interesting ingredients. We'll hop around a little bit, but hopefully the net result will be quite nice for you. So to start with, we're gonna be talking about what we can do with the fact that Bitcoin is an append-only log. So remember, an append-only log means that it's a data structure that we can only write to. And once we've written data to it, the data will remain there forever. And we have a secure notion of time. So we can tell that certain things were written to the log before or after other things, based on which block they're included in. So we'd like to build using this as secure time stamping. And the goal here is that we wanna be able to prove that we know some value x is specific time t. We know it at no later than time t. And oftentimes, we're gonna wanna be able to prove that we know what x is without actually revealing it at time t, but revealing it later. And we want the evidence to be permanent. So we have a permanent record that we knew some information x at time t or earlier that nobody can ever destroy after the fact. So recall that we can use hash functions to commit to data. So instead of publishing the data x that we wanna prove that we know, we publish the hash of x. And the properties of the hash function guarantee that we can't later find some other value x prime that has the same hash value as x. If we did, that would be a break of the cryptographic properties of the hash function. And we also have the nice property that the hash of x shouldn't reveal any information about x, with the caveat of course, that that's only true if x comes from a large possible space. Otherwise, somebody who has the hash of x can simply try different values, different potential values for x and see if any of them match. So the idea of doing secure time stamping with an append-only log is that we can publish a commitment to x, the hash of x. And then later on we can reveal what x was. And anybody can look at this and say that we must have known x at the time we published the hash of x cuz there's no other way to have generated that data. So what can we use this secure timestamping for? This idea that we publish the hash of something and later on we reveal what that data is, to show that we knew it at that time. So one thing is proof of knowledge. If we want to prove, say, that some idea that we file a patent on was actually in our heads months earlier, we can publish a hash, say, of a design document or a schema for that idea. That thing that we would patent that proved that we knew it at that time, but we don't have to tell anybody. And then later on, when we file our patent or when we publicize the idea, we can publish the information. And anybody can look backwards in time and say yes, they must have known it earlier when they published this commitment to it. We can also prove that we've received something. So if you're submitting data to a server, say, something like a vote, the server can publish the hash of that vote. And that serves as a commitment that they actually received it at a specific time. And that will prevent them from later claiming that they never received that information from you. A whole bunch of other interesting things can be built just off of secure timestamping. There's actually a whole signature scheme that just uses hash functions. Doesn't use any of the normally relatively heavyweight cryptography required to do public key signatures. Just using hash functions in an append-only log, that's called the Guy Fawkes signature scheme, which we won't talk about anymore in this lecture. But the existence of stuff like that goes to show that this is a really powerful primitive that we can build a lot of very interesting applications with. So one thing that we can't do that would be very nice if we could is prove clairvoyance, prove the ability to tell the future. So you might think that this secure timestamping would be a way to prove that we know something before other people, before it actually happens. And the idea here would be that we publish the commitment to an event that's about to happen, say the outcome of a sporting event or an election. And then later on, we reveal that information, and that proves that we knew the outcome ahead of time. So about a month ago, during the World Cup Final, it was thought that somebody had actually done this. And they tried to prove that FIFA, the organization running the World Cup was actually corrupt. And the way they did this is that they showed a Twitter account after the match was over that had tweeted a bunch of outcomes that happened during the game. For example the fact that Germany won, the fact that Mario Gotze would score, and they proved that they had tweeted this before the game actually happened. And for a moment before you think about it, it looks like this proves that somehow this person either could tell the future or that the match was actually fixed. And that they must have know what was going to happen ahead of time. But, with a little bit of investigation, you can find out what they actually did, is they had tweeted every possible outcome before the match started. So, they had tweeted every single player involved in the match would score, all possible final scores, and a whole bunch of other information. And then before the match finished, they deleted all of the predictions that they had tweeted which turned out not to be true. And they were left with only true predictions. So, the same basic attack can be done against any secure messaging system where you simply commit to a bunch of possible outcomes. And then you only reveal the commitments that turn out to be true. So if you wanna prove that you can actually tell the future, if you have that ability, you have to prove that you aren't timestamping multiple predictions for the future. You have to prove that you're only timestamping one specific prediction, and then it comes true. And normally, if you're publishing a hash commitment, it's difficult to do that. Especially in Bitcoin, if we're writing hash commitments as our secure timestamping, if they're not tied to any individual, it's easy to just publish a large number of them. Never reveal the ones that are incorrect, and then they won't be traceable back to you. So that was a long detour to say that you can't use secure timestamping to prove that you could tell the future. It would be interesting if you could. So before Bitcoin even existed, there was a solution to this basic problem, which was to publish a hash of predictions in a newspaper or some other media, which is called widely witnessed media. So something that a lot of people see in a public place, there are a lot of records. Newspapers get maintained in libraries and online. They're cached all sorts of different places. So if you've taken the time to put a hash into the corner of the newspaper here or somewhere in the classified section, people have pretty high confidence that you actually put that hash the day that the newspaper was published. That serves as a pretty good timestamp. And for a relatively low cost, you can simply pay the newspaper as if this is an advertisement, and you can put the hash of whatever day that you want. And then after the newspaper has been published, whenever you wanna reveal the data that you committed to, you can just publish the data. People can refer back to the newspaper and the time, and they'll know that you committed to it on that date. So this is a really simple solution, it works just fine offline. The question is, how can we do this with Bitcoin? So the question is really, where can we put our hash commitment in Bitcoin? What's the right place in the block chain or in transactions to stuff this data, which will represent the hash of some information that we're trying to timestamp? So the simplest idea that people came up with first is instead of sending money to the hash of a public key, just send it to the hash of your data. You can send a very small amount, say 1 satoshi, the minimum possible transaction value in Bitcoin, to that address. And of course it's in your interest to send as little as possible, because you're never gonna get the money back. Since that is a hash of data and not a public key, there's not going to be any way to ever spend that, the coin that you send that address. So the advantage is that this is a really simple, easy way to do it. It's compatible with Bitcoin. But the disadvantage is that you're creating this transaction that you're never going to be able to redeem. And the Bitcoin miners have to track this as an unspent transaction output forever. And they have no way of knowing that this was actually a timestamp and not a valid transaction. So the Bitcoin community takes a pretty dim view of this approach because it creates these unspendable outputs that have to be tracked. So a more sophisticated way to do this is called CommitCoin. And this is a little protocol for finding public keys and signatures that have the data that you want to commit to embedded in the bits of the public key and the signature. So you have to do some brute force work here to find a special public key by simply trying to find a lot of public keys and a lot of signatures. So that the bits that you want, the bits that represent the hash of your data, are also the bits of a valid public key. And the advantage of doing this is that it's still compatible. It's invisible to miners. They can't tell that you're committing data. It looks just like any other valid public key. And you aren't actually adding any new unspendable transaction outputs. The downside of this is that it's more expensive to do. You have to do the brute forcing to find this key. And your data rate is gonna be a little bit lower since it's more expensive to do this style of commitment. So the preferred way to do this now is with a provably unspendable output. And you include your data in the provably unspendable script that you're trying to commit to. And we talked about this earlier when we were talking about scripts, when we were talking about proof of burn, where you have this script with the OP_RETURN, which can never be satisfied. And then you can push some arbitrary data. So the same way that you could use this to do proof of burn, you can use this to commit to some data. You just have a script that returns immediately. The return command of course throws an error, so the script can never be run successfully without an error. And you can include some data. So this is cheap. There's no bloat in the unspent transaction outputs. You only lose a little bit of money every time you do this. The only downside is that this still isn't a standard transaction. So it won't be relayed by default. But this is the preferred way to commit to data in the block chain. And there are actually a bunch of startups that actually start up small web sites that will do this for you. So they'll collect a lot of people's commitments into a large Merkle tree. And then publish one unspendable output that looks like this form that has all of the commitments that everybody wanted to make for the day. So in fact, you don't even need to spend the small value yourself. A lot of people can amortize that cost together, and this is another way to limit the amount of bloat that you're adding to the block chain. So what's the data rate of a scheme like this? Well, mostly you can get a 40-byte commitment for the cost of 1 transaction fee, which is currently about 0.0001 Bitcoin, or about $0.05, US. And that's enough to commit to the hash of whatever data you want. So essentially for about $0.05 you can commit to an arbitrary amount of data. So the downside of being able to write arbitrary data into the block chain is that people might abuse this, and they might abuse it by trying to write illegal content into the block chain. And in some countries there are things that are very illegal. So, think about child pornographic images, copyrighted material, or other things that you may face very stiff penalties if you're caught having that data. So sure enough, several people have tried to do this as a griefing action against the Bitcoin community simply to harass the community and try to bother people. They've at least claimed, I've never seen it actually verified, that they've published pornographic data into the Bitcoin block chain. And the idea is that this makes it dangerous to download the block chain onto your hard drive and to run a full node, because you're now downloading this illegal material. So this is basically just an unfortunate fact of life. There's no good way to prevent people from writing arbitrary data into the Bitcoin block chain. If you force everybody to use pay-to-script-hash, that's one countermeasure that would make it a little bit more expensive to write this data in. But in general, there's no way to prevent people from writing arbitrary bits into Bitcoin if that's what they really want to do. So an observation on the positive side from the fact that we can write whatever data we want into Bitcoin, is that we can actually build an entirely new currency system without developing a new consensus mechanism. We can just use Bitcoin as an append-only log that already exists. And write all of the data that we need for our new system directly into the Bitcoin block chain. So this is called an overlay currency. Bitcoin exists as the underlying substrate, if you will, and you just write your new data directly into the Bitcoin block chain, format it as these unspendable Bitcoin transaction outputs. Of course, you don't have the miners actually validating that what you're writing into the block chain is valid under the rules of the new currency system anymore. So you have to develop a more complicated logic for understanding the new currency, because you don't have miners policing what's written into the, effectively the new overlay block chain. Anybody can write anything in there who's wiling to pay the Bitcoin transaction fees. So instead of having miners rejects double spends, everybody as a community has to simply look at the history of what's been written. And if two transactions attempt to spend the same coins, everybody has to understand that the second one is considered invalid. So the most prominent effort to actually do this, is called Mastercoin. So Mastercoin is an overlay currency. It's built on top of Bitcoin. All of the Mastercoin transactions are written into the Bitcoin block chain, and it supports a much larger, richer feature set than Bitcoin. So the idea is that they don't have to develop a new consensus algorithm. And since the Bitcoin miners don't need to know about the Mastercoin rules, they can support a lot more fancy features, more sophisticated smart properties, smart contracts, user defined currencies. Essentially the API is many times larger than the Bitcoin API because the miners don't have to understand it. They're willing to just blindly write anything into the block chain which is formatted as a valid Bitcoin transaction. And the Mastercoin community has to look at all of that data and piece together valid ownership of Mastercoins based on what's written into the Bitcoin block chain. So this is very nice. You can develop a currency without having to create your own new consensus system. You don't need new miners, you can add more features, you can develop it faster. But you're inherently reliant on Bitcoin here. And this can be somewhat inefficient because you might have to write a lot of data because you don't have miners policing to prevent invalid transactions from being written into the block chain. And I believe that we'll talk a little bit more about Mastercoin in lecture 11.
