Welcome to the third lecture in our series on Bitcoin. This lecture is going to be all about the mechanics of Bitcoin at a fairly low level. So whereas in the first two lectures, we've talk in a relatively high level, in this lecture, we're going to be trying to give it to you as real as possible. So we'll look at real data structures, real scripts. Try to learn the details and language of Bitcoin in a precise way to set up everything that we wanna talk about for the remainder of the course. So in some ways, this will be the most challenging lecture because a lot of details are going to be flying at you. It's also one of the most real, where you're really learning the specifics and the quirks that make Bitcoin what it is. So to recap where we left off last time, the Bitcoin consensus mechanism gives us an append-only ledger, so a data structure that we can only write to and once data is written, it's there forever. And there's a decentralized protocol for establishing consensus about the value of that ledger. And the miners, who perform that protocol, are validating transactions. So making sure that transactions are well-formed, that there aren't double spends, and that this thing can function as a currency. Although, it's kind of funny, because we assumed that the are currency existed to motivate these miners. So in this lecture, we'll be looking at the details of how we actually build that currency to make the miners make this whole process happen. [MUSIC] All right, so we'll start by looking at transaction in Bitcoin. Transactions are really the fundamental building block which the whole currency is gonna be based on. So remember, we have this ledger. The ledger is append only, so as time goes on we just add more and more units to it. We're gonna take a simplified model here, where instead of having blocks, we just have individual transactions being added to the ledger one at a time. So how can we build a currency this way? So the first model you might think of, which is actually a lot of people's mental model for how Bitcoin works that we'll look at first, is that you would have an account based system. So you can add some transactions that create new coins and credit them to somebody. And then later you can transfer them and you would just have a transaction that would say, we're moving 17 coins from Alice to Bob. That will be signed by Alice to authorize the transaction. And that's all the information that would be contained. Now backing this up, there would some state that says that after Alice received 25 coins in the first transaction, and then transferred 17 coins to Bob in the second transaction, Alice would have an account that is left with 8 Bitcoins. So now, after that transfer from Alice to Bob, we can add some more transactions to ledger. We'll say that Bob pays some Bitcoins to Charlie, Charlie pays some coins to Alice. And at this point, each participant, Alice, Bob and Charlie has an account with a different value in it. And those values are gonna mutate each time we add a new transaction. Now the downside of this system, if we add a new transaction at the bottom here, is that we have to remember what the account balance is for each participant to figure out if this transaction is valid or not. Does Alice have the 15 coins that she is trying to transfer to David here? So sure enough looking at this just with your naked eye, it's fairly hard to tell, to do the mental arithmetic, to figure out if Alice has enough money to transfer to David here. And in fact, to figure this out you'd have to look backwards in time forever to see every transaction effecting Alice and whether or not her net balance at the time that tries to transfer 15 coins to David is greater than 15 coins. Okay, so to tell if this transaction is valid or not, we have to figure out whether or not Alice has the 15 coins that she's trying to transfer to David. And to figure that out, we might have to look backwards forever to the beginning of time at every transaction that's ever involved Alice. Every time Alice is sent to receive coins, we need to find all of those transactions and add them up to see if she really has the 15 coins that she's trying to transfer to David. And, of course, we can make this a little bit more efficient with some data structures that track Alice's balance after each transaction, but that's gonna require a lot of extra housekeeping beside the blockchain itself. And that's why Bitcoin isn't based on an account based model like this. Instead Bitcoin uses a ledger that just keeps track of transactions. So how does that work? So this is a transaction based ledger, which is very close to Bitcoin. So now transactions explicitly specify a number of inputs and a number of outputs. And transactions also each have a unique identifier. So we'll start with transaction one, which has no inputs cause this is new currency being created, and an output of 25 coins going to Alice. And again since this is a transaction where new coins are being created, there's no signature required here. Now, let's say that Alice wants to send some of those coins over to Bob. Well now, she has to explicitly refer to the previous transaction where these coins are coming from. So the input to this transaction will be output index zero from transaction one, which we can see from the very previous transaction, the log was a transaction that assigned 25 Bitcoins to Alice. And now there are two outputs of this transaction. One of them is 17 coins to Bob and one of them is 8 coins to Alice. And of course this whole thing is signed by Alice so that we know that Alice actually wants to do this transaction. I know you might ask, why does Alice have to send money to herself here? She's taking the 25 coins that were assigned to her in transaction one, she only wanted to pay 17 to Bob and she has to have a new output where 8 coins are sent back to herself, possibly to a different key, but to herself. So this is what's called change address. And the design here is that you always completely consume the output of a previous transaction. So there's no way to say, I only need 17 coins from that previous output, you have to say I'm using all 25 coins from the previous output. But since you wanna keep some, you just have a second output that sends some of the coins back to yourself, which is called a change address. Now, let's say that we keep going with this system, and now we add a new transaction and we ask ourselves again, is this new transaction valid? Now it's much easier to look at the blockchain and figure out whether or not this transaction is valid, cuz we know exactly which input to look at. So we just need to go to transaction two, output one, and verify that there's enough money there and that it hasn't been sent already. And of course, we can look back and say yes, that second output of transaction two went to Alice with eight coins, therefore it's enough to cover the outputs of this transaction. It's a finite backwards scan to check for the validity. And we implement this with hash pointers. So, again, each transaction has a unique ID. In reality they're not serial numbers like this, it's the hash of the block. And each transaction actually gets its specific ID as well, which is the hash of the transaction. And now it's basically just following one pointer to figure out whether or not there is enough money to cover the desired outputs in the new transaction. Now, conceptually you could say maybe this isn't that much different than just maintaining a separate data structure which tracks account values for each person. But the nice thing is it now this data structure is embedded within the data in the blockchain itself. So some other things that we can do quite easily here, we can merge value. So let's say there's two different transactions that sends the money to Bob, 17 coins in transaction one and two coins in transaction two. Bob might say I'd like to have one transaction I can spend later, why I have all 19 coins? So this is pretty easy, you just create a new transaction that has two inputs now, and only one output so all of those coins go to Bob. And you've combined the two previous transaction into one that Bob can then suspend later. Similarly, we can do joint payments very easily. So let's say that Carol and Bob both wanna pay David, we can have a transaction with two inputs that are actually owned by two different people and combine the value and pay all eight coins to David. And the only extra thing here is that since the two outputs that are being claimed here are owned by two different people we're gonna need two separate signatures, one by Carol and one by Bob. So, conceptually that's really all there is to it to a Bitcoin transaction and let's look at what it looks like at the low level. So again one of the goals of this lecture is gonna be to show you the real data structure, the real deal of what Bitcoin looks like and here it is. Now this isn't exactly what a Bitcoin transaction looks like, this is a representation of it that is pretty printed. It looks kinda like JSON. In reality, there's a compact binary format that this gets compiled down to that's not human-readable, but this is very, very close to the actual low-level transaction. So there's three parts. There's some metadata, there's a series of inputs and a series of outputs. So we'll start with metadata. So there's some housekeeping information, which is the size of the transaction, the number of inputs and the number of outputs. Pretty straightforward stuff. There's the hash of the entire transaction, which as I said, will serve as a unique ID for the transaction to let us do hash pointers. And then there's this funny lock _time parameter, which I'll come back to later. The transaction inputs is just an array of inputs that all have the same form. The inputs specify a previous transaction specifically, so they have the hash of the previous transaction, or a hash pointer to it. And the index of which output from that transaction you're actually claiming. And then there's a signature. So remember that we have to sign to show that we actually have the ability to claim those previous transaction outputs. And now the outputs have just two things. They have a value, so each output can have a different value. The sum of all the outputs has to be less than the sum of all the inputs. And then there's this funny thing that looks like what we want to be the recipient address, so each output is supposed to go to a specific person, or to a specific public key. And there is some stuff in there that looks like it's the hash of a public key. But there's also some other stuff. It looks like a script. And in fact, it is a script and we'll talk more about that very soon. [MUSIC]
