Name: John Newbery Topic: Contracts in Bitcoin Location: She256 Onboarding to Bitcoin Webinar Date: April 8, 2020 Video: Transcript completed by: Caralie Chrisco # Introduction John: My name is John. I am a Bitcoin Protocol Engineer at Chaincode Labs in New York. I'm going to talk about contracts a little bit from a theoretical perspective, but I'm not a lawyer, and I'm not a legal scholar. For all of you legally minded people out there, I apologize in advance if I gobble this and say some nonsense. Before I do that, I'm going to tell you a story and the story based on this picture. This is Odysseus and his sailors going past the island of the sirens on his way home from the war in Troy. And the sirens were beautiful women who sang very alluring songs to sailors who passed the island, and any sailors who heard that song would not be able to resist the temptation of the sirens. They would steer their ships towards the island, and the ship would be dashed on the shore, and they would be shipwrecked and devoured by the sirens. Odysseus knew this was going to happen, and so he had his sailors cover their ears up with wax and wool and ordered them to tie him to the mast. Then he gave him a very strange order and said, "from now on until we get past the island, disobey any of my orders. If I tell you to steer towards the island, disobey me. If I tell you to untie me from the mast, bind me harder to the mast." So they sailed past the island, Odysseus heard the song the sirens, but he couldn't do anything about it. They say he got passed, and eventually, Odysseus got home to Ithaca. Alright, enough of the storytime. I am going to talk about contracts and what we call smart contracts. I'm going to talk about this language we have in Bitcoin called script and then more generally talk about contracts on a public blockchain. I'll talk a bit about the history of script in bitcoins who has changed over the last 11 years, and then I'll finish up with some possible future directions for scripts and contracts in Bitcoin. # Contracts What is a contract? Well, a contract is, in some ways, a meeting of the minds where two or more parties come together with shared intentions, and it's a situation where there's a common understanding in the formation of this contract. But a contract is also binding. I might want to borrow money to buy a house, for example. And at some point in the future, I'll pay back that money, but I know that the future me would prefer not to pay back that money. All things being equal, I prefer to keep the money and the house. So I bind myself into a contract where there's a penalty for future me if I don't pay back the money. Because obviously, no one would lend me money if I could just run away with it. So this is similar to Odysseus, binding himself to the mast. He knows that future Odysseus will want to go and visit the island of the sirens, but present Odysseus enters a contract with his sailors where he limits himself, and so he's bound to the mast just as we are bound to contracts. The concept here is limiting future me's freedom. The freedom to renege on my debt or to order his sailors to steer to the island expands present-me's freedom because I can borrow money. This concept of contracts has existed for centuries, for millennia. It is a fundamental building block of civilization and the market economy. We naturally think of contracts as written, but oral agreements count as contracts and have been around since prehistory. People were thinking about this for many years as the internet came online, and it would be impossible to rederive all of the wisdom contained in this tradition of contract law and norms very quickly. If we start from scratch using just kind of reason and first principles it would take us many centuries to redevelop sophisticated ideas like contract law. The digital revolution is coming and is challenging us to develop new institutions in a much shorter period of time than that. # Smart Contracts This man named Nick Szabo and he said, "New institutions new ways to formalize the relationships and make up these institutions and now made possible by the digital revolution. I call these new contracts "smart" because they are far more functional than their inanimate paper-based ancestors. A smart contract is a set of promises specified in digital form, including protocols within which the parties perform on these promises." Nick Szabo was writing this back in 1996. If you think of smart contracts as new or introduced by Ethereum or Bitcoin or blockchains, this predates Bitcoin by over a decade, and smart contracts are possibly older than you expected. A little bit more about contracts before we get into Bitcoin. I'm going to outline some objectives when designing a contract, which I'm going to come back to throughout the talk. One objective is observability that the participants in a contract should be able to observe each other's performance in that contract. Another is verifiability. That is that participants can prove to an arbitrator or third party that the contract is being performed faithfully or prove that it's been breached. Another important aspect is privacy. That knowledge and control over the contents of the contract should be distributed among parties only as much as it is necessary to observe and perform that contract. Then enforceability. That probably speaks for itself, but at the same time, I should add when we design a contract, we'd like to minimize the need for enforcement or minimize the need to go to a court, for example. # Script Enough theory. Enough armchair law. Let's talk about script in Bitcoin. Bitcoin was introduced by Satoshi Nakamoto in 2008, and we know that we can script on Bitcoin. So here's the white paper. Let's have a look for script. Oh, look at that; there's no mention of the word script in the white paper. Or maybe contracts? No mention of contracts either. Let's just scroll down a bit and look at what the white paper has to say about transactions. "We define an electronic coin as a chain of digital signatures. Each owner transfers the coins for the next by digitally signing a hash of the previous transaction and the public key of the next owner." Okay, so the idea here is that ownership of coins is defined by public keys, and then transfer of coins is executed by creating a signature with a private key that matches a public key. No mention of scripts, no mention of contracts here. But if we look at the first version of Bitcoin 0.1 that was released by Satoshi in 2009 we do see this function `EvalScript`. The comment here is script is a stack machine like FORTH that evaluates a predicate returning a ball indicating valid or not. There are no loops. Perhaps Satoshi thought that talking about script was getting in the weeds too much for a white paper that was just an overview of Bitcoin. But I think a more likely explanation is that this scripting system, this function was bolted on at quite a late date in the development of Bitcoin. The reason I think that is if we look at where that `EvalScript` function is called, you can see right here at the bottom here is a function called `VerifySignature`, which makes me think that Satoshi's original design for Bitcoin was this chain of signatures and public keys. But then later, Satoshi added on this scripting language. Why did Satoshi do that? We don't know. We can't ask him. He's not around, but there's this mailing list post from 2010 where Satoshi says, "Once version 0.1 was released, the core design was set in stone for the rest of its lifetime. Because of that, I wanted to design it to support every possible transaction type I could think of. The solution was script. The nodes only need to understand the transaction to the extent of evaluating whether the sender's conditions are met. The script is actually a predicate; it's just an equation that evaluates to true or false. Predicate is a long and unfamiliar word so I call it script." So Satoshi early on wants to add all kinds of fancy contracts like escrow transactions, bonded contracts for third-party arbitration, multi-party signatures, and so on. And as he was developing Bitcoin, the problem was, each of those special cases required special support codes and data fields, booleans to say whether the function was used or not. It was just this explosion of special cases. So script is the answer. It lends a flexibility to use Bitcoin and supports a tremendous variety of possible transaction types with a very limited set of primitives. Satoshi's reasoning was that if Bitcoin catches on in a big way, that later on, people could explore these different use cases because script was there for people to use. So that's where scripts in Bitcoin comes from and the idea of contracts. Zooming out a bit and talking about contracts in general on public blockchains and whether they're a good fit for these smart contracts that Nick Szabo was talking about in the 90s. So how do they fit? Well, the good news is observability is good. Participants can all see all the possible parts in a contract, and they can see how the other parties had acted. So that's great. And verifiability is good because the contract is on a public blockchain. Everyone can see it, and participants can prove to third parties that they executed the contract faithfully. And enforceability seems pretty good. The contract is executed, and rules are enforced by all nodes. So you might think at first glance that a public blockchain is a pretty good place for smart contracts. I put enforceability in yellow there because it's not all good news. In Bitcoin, we have blocks, and they arrive every ten minutes. So if you want a transaction to be confirmed, you need to wait for an average of ten minutes for the first block. You might not get confirmed in that block, and even if you are, there might be a reorg, and that transaction gets undone and doesn't spend. So we never really have a solid idea of finality in Bitcoin. Finality is kind of fuzzy. So enforceability seems somewhat good, but somewhat not good, and there are worse things. Privacy is terrible. If we want to execute a contract, sometimes we want that contract to be private. That contract might include financial information. It might include trade secrets or proprietary business information. It might include medical information. It could include all kinds of data, and we don't necessarily want the whole world to see all of that. And if we execute a contract on a blockchain the whole world sees everything, not just now, but for all time because it's stuck in the blockchain forever. Here's another thing: expressiveness. In Bitcoin, we have this limited set of primitives in our contracting language, which, when combined, can achieve quite complex things. But if we ever want to add new primitives, if we want to add, for example, time locks or sequence locks, which we did in 2015 and 2016, we need a consensus change in Bitcoin. Those things are slow and difficult to do and can sometimes get political. So adding expressiveness to the contracting language is very difficult. Fungibility is a very important aspect of Bitcoin, and if everyone can see all of the details of a contract, the outputs of their contract are no longer fungible. A miner might be located in a jurisdiction where certain kinds of contracts are illegal, and they might find themselves forced or coerced or threatened to not include those transactions in the block, which would be bad for the blockchain and bad for Bitcoin. Scalability is also not very good if we put everything on the blockchain. It means every single node on the blockchain needs to execute every step of every contract. We, therefore, have a trade-off. Either we exclude small underpowered nodes from taking part in consensus, or we limit their total throughput of the system. So those are pretty bad things about trying to use a blockchain as a platform for smart contracts. This is Andrew Poelstra. He's got a really great talk from 2017 called "using chains for what they're good for." And Andrew says, "contracts executed by explicitly published code are really only using the blockchain for one thing - to get an immutable ordering of what order the transactions happen in. All that they really care about is that their transaction is not reversed and not double spent. All of the extra details of the contract execution can be done by things that are not on the blockchain." # Post's Theorem I'm going to have one very technical slide, and it's got some symbols in it. This is Post's Theorem. I'm going to talk a bit about logic from the 1930s. So turing-complete languages -- Alan Turing defines these in the 50s and 60s, as computably enumerable predicates. So like we said earlier, predicate is just a function that returns a boolean true or false. In the 1930s, Emil Post defined an Arithmetic Hierarchy. So there are Δ0 predicates, and they have no unbound quantifier. So an unbound quantifier is one of these "∀x's or Ǝy", where there's no bound on what it could be. So, for example, for ∀x and the natural numbers, there's an infinite range where it could fall. Δ0 predicates, all of the quantifiers are bound. For example here: ∀x < z . Ǝy < z s.t.x+y = z. Then Σ1 predicates are those which contain an unbound ∃ (exist) sign. So for: ∃X in the natural numbers s.t. ∀y>z and x