So we've just invested the effort to understand Bitcoin scripts a little bit, but I haven't really shown you what's so cool about Bitcoin scripts yet. It turns out, you can do quite a lot of neat things that will justify the complexity of having the scripting language instead of just specifying public keys. So one of them is to do an escrow transaction. So this is a classic situation online. Alice and Bob wanna do business with each other, maybe Alice has just won some online auction and is ready to buy some things from Bob. Now Alice wants to pay Bob in Bitcoin for Bob to send some physical goods back to Alice. But we get into this problem where Alice doesn't want to pay until after she has received the goods but Bob doesn't want to send the goods until after Bob has been paid. So what can we do about that? There is quite a nice solution in Bitcoin that's actually used quite heavily in practice. Which is to introduce a third party and do escrow transactions. So how does this work? Well, Alice is gonna send the money not directly to Bob, but create a MULTISIG transaction that requires two or three people to sign in order to redeem the coins. And those three people are going to be Alice, Bob, and Judy, who is a judge, who is going to come into play in case if there's any dispute. So, Alice will create this transaction for the desired amount. With that two out of three MULTISIG between Alice, Bob and Judy. Alice signs the transaction redeeming some coins that she owns and this will get published in the block chain. So at this point these coins are held in escrow between Alice, Bob, and Judy. And any two of them can specify where the coin should go. So Bob will be satisfied after that happens that he's safe sending the goods over to Alice. So he'll mail them or deliver them physically. Now what we hope happens in the normal case is that Alice and Bob are both honest. In which case the goods arrive on time, they're what Alice was expecting, and she wants to actually release the money from escrow so that Bob can spend it. So if this happens, Alice and Bob can both sign a transaction redeeming the funds from escrow and sending them to Bob. And the great thing here is that Judy never had to get involved at all. There was no dispute. And so, Alice and Bob were able to sign, and that represents two out of the three people required by the MULTISIG transaction. So in the normal case, this isn't that much less efficient than Alice just sending Bob the money. It requires just one extra transaction on the block chain. Now, what would have happened if Bob didn't actually send the goods or if he tried to send them and they were lost in the mail, maybe he sent the wrong size? Alice now doesn't wanna pay Bob, cuz she thinks that she got cheated and she wants to get her money back. So Alice and Bob are definitely not both going to sign a transaction that releases the money to Bob. But Bob's also not going to sign a transaction that releases the money back to Alice because he may be denying Alice's claim of fraud here. So now we're going to have to get Judy involved. Judy is going have to decide which of these two people was honest, which one doesn't deserve the money. And if Judy decides that Bob cheated, Judy will be willing to sign a transaction along with Alice sending the money from escrow back to Alice. So Alice and Judy can get together, that's two of the three required signatures, and Alice can get her money back. And of course Judy would have the opportunity to rule in the other direction. If Judy thinks that Alice is at fault here and Alice is simply refusing to pay when she should, Judy can sign a transaction with Bob sending the money to Bob. So Judy essentially has full control here, but the nice thing is that she won't have to be involved unless there's a dispute. Another cool application is what are called green addresses. So the problem here is that Alice wants to pay Bob and Bob's offline. So Bob can't go and look at the block chain to see if the transaction that Alice is sending is actually there. Maybe Bob simply doesn't have time to go and look at the block chain and wait for the transaction to be confirmed. Remember that normally we want a transaction to be in the block chain, and be confirmed by six blocks, which takes up to an hour before we trust that it's really in the block chain. Or maybe Bob is just in a Faraday cage and doesn't have any connection to the Internet at all, so Bob is never gonna be able to check the block chain. This would be the case, say, if Bob is the person selling food on the street. So to solve this problem, of being able to send money using Bitcoin without the recipient being able to access the block chain, we have to introduce another third party, which is the bank. So Alice is gonna talk to her bank, and say, hey, it's me, Alice. I'm your loyal customer. Here's my card or my identification. And I'd really like to pay Bob here, could you help me out? And the bank will say, sure, I'm gonna deduct some money out of your account and draw up a transaction from one of my green addresses over to Bob. So notice that this money is coming directly from the bank to Bob. Some of the money of course in a change address is going back to the bank maybe. But essentially the bank is paying Bob here from a bank controlled address. That bank controlled address comes with a guarantee that that money will never be double spent. So as soon as Bob sees that this transaction is signed by the bank, if he trusts the bank, if he trusts the bank's guarantee not to double spend the money, he can accept that, that money will eventually be his when it's confirmed in the block chain. Now, notice that it is not a Bitcoin enforced guarantee, this is a real world guarantee, so Bob has to trust that the bank in the real world Is doing a business, and cares about their reputation, and won't double spend for that reason. And the bank will be able to say, you can look at my history, I've been using this green address for a long time, and I've never double spent. Therefore, I'm very unlikely to do so in the future. Of course if the bank ever does double spend, trust in this whole system is gonna collapse pretty quickly. And in fact, the two most prominent online services that implemented green addresses, which were Instawallet and Mount Gox, both ended up collapsing. So, for that reason, green addresses aren't used as much in Bitcoin as when they were first proposed. People were really excited and thought this was a great idea and a way to do payments more quickly and without accessing the block chain. Now people are actually quite nervous about this idea and they're worried that this puts too much trust in the bank. As a result, this isn't used that much in practice even though it's a cool protocol. A third example I'd like to show you, is a way to do efficient micro-payments. So this set up here is that Alice is a customer who wants to pay Bob a low amount of money for some service that she's gonna use. So maybe in this case Bob is really Alice's wireless service provider, and Alice wants to pay a small amount of money for every minute that she talks on her phone. Now you can see why a solution that won't work here is to simply create a Bitcoin transaction every minute that Alice speaks on the phone, that's gonna create too many transactions. There will be too many transaction fees and nobody is happy about that. The simple solution here is to create a new, low value transaction every minute that Alice talks on the phone. So if she talks for two hours you might might need over a hundred transaction. The problem that you're gonna get into with that system is that those transactions might all be very low value and that transaction fees might really kill you. So if the value of each one of these transactions is on the order of what the transaction fees are, you're going to be paying quite a high cost to do this. So what we would like is if you can combine all these small payments into one big payment at the end. And there's actually a neat way to do this with serial micro-payments. So how is this gonna work? So we start with a MULTISIG transaction that pays the maximum amount Alice would ever need to spend to a MULTISIG transaction requiring both Alice and Bob to sign to release the coins. Now after the first minute that Alice has used the service or the first time Alice needs to make a micro-payment, she signs the transaction spending those coins that were sent to the MULTISIG address sending one coin to Bob and returning the rest to Alice. After the next minute of using the service, Alice signs another transaction, and this time she's paying two coins to Bob and sending the rest to herself. And notice that these are just signed by Alice, they haven't been signed by Bob yet. Alice is gonna keep sending these transactions to Bob every minute that she uses the service. Notice that these aren't getting published in the block chain. They're just getting sent from Alice to Bob. Eventually Alice is gonna finish using the service. In which case she'll tell Bob, I'm done, you can cut off the service, I'm not gonna pay you anymore. And Bob is going to say, great I'll disconnect your service. And I'm gonna take that last transaction that you sent me, and I'm also gonna sign that and publish that to the block chain. So since each transaction was paying Bob a little bit more and Alice a little bit less, whatever the final one is is what Bob is gonna choose to actually redeem, paying him for the service that he was provided and giving the rest of the money back to Alice. And the great thing is that all those transactions that Alice signed along the way, won't make it to the block chain, Bob doesn't have to sign them, they'll just get discarded. So technically all of these transactions are double spends. So unlike the case with green addresses, where we were specifically trying to avoid double spends with a strong guarantee. With this micro-payment protocol, we're actually generating a huge amount of potential double-spends. Although in practice, if both parties are operating normally, Bob will never sign any transaction but the last one, in which case the block chain won't actually see any attempt at a double-spend. Now there's one more detail here, if you stop and think for a second. Which is somewhat tricky to deal with, what if Bob never signs the last transaction? He may just say I'm happy to let the coin sit there in escrow forever. In which case maybe the coins won't move but Alice will be out the full value that she paid at the beginning. So there's a very clever way to avoid this problem using a feature that I described earlier but haven't explained yet, which I'll need to introduce now. And that feature is called Lock Time. So to avoid this problem before the micro-payment protocol can even start, Alice and Bob will both sign a transaction which refunds all of Alice's money back to her, but is locked until some time in the future. So before Alice signs the first transaction paying for the first minute of service, she's gonna wanna get this refund transaction from Bob and be able to hold that in her hand. And know that if she makes it to time t and Bob hasn't signed any of the small transactions that Alice has sent, Alice can publish this transaction which refunds all of the money directly to her. So what does it mean when I said it's locked until time t, how do we do that? Well you'll remember when we looked at the metadata in Bitcoin transactions that there was this lock_time parameter which I had left unexplained. It's quite simple actually, if you specify any value other than zero for the lock time, that tells miners don't publish this transaction until this point in time. The transaction is invalid and can't be published, until either a specific block number, or a specific point in time based on the timestamps that are being put into blocks. So this is a way of preparing a transaction that can only be spent in the future if something else doesn't happen. And it works quite nicely. And that micro-payments protocol as a safety valve for Alice to know that if Bob never signs, eventually she'll be able to get her money back. So hopefully those examples have shown you that you can do some pretty neat stuff with Bitcoin scripts. Those are just three examples that are the most practical and simple to explain but there are a lot of other things that people have looked in to doing. One of them is multi-player lotteries, which is a very complicated, multi-step protocol, with a lot of transactions, a lot of transactions with different lock times. There are escrows in case people cheat. But you can actually run a fair multi-party lottery over Bitcoin using just the scripting language, which is really neat. There are other things. Like you pay some one if they know the pre-image of a hash, so you can try to pay somebody to do some brute force work for you. And there are a couple of neat protocols for different people to get their coins together and mix them so that it's harder to trace who owns which coin. And we'll talk about that a lot more in our lecture on anonymity. So the general term for contracts like this is smart contracts, which means that the contracts actually have some technical enforcement of something that used to be enforced through things like laws or courts of arbitration. So it's a really cool feature of Bitcoin that we can use scripts, and we can use the miners, and we use transaction validation to enforce things like escrow or the micro-payment protocol. And you don't have to rely on any centralized authority to actually enforce these contracts. Now the whole field of smart contracts goes quite deep. There's a lot more smart contracts people would like to apply, a lot of which you unfortunately can't build with the Bitcoin script today. So the Bitcoin script is fairly limited in the types of things that you can address. There's a lot of smart contracts people wish they could build that either are impossible or nobody has come up with the way to do it yet. But you can do quite a few interesting smart contracts with the Bitcoin script.
