 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 talked at a relatively high level, in this lecture we're going to be trying to give it to you as real as possible. So 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 want to 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 the 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 there a 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. Alright so we'll start by looking at transactions in Bitcoin. Transactions are really the fundamental building block which the whole currency is going to 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 going to 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'd 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 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 be 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 the 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 going to 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's 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 affecting Alice and whether or not her net balance at the time that she 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 going to require a lot of extra housekeeping besides 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 1 which has no inputs because 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 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 0 from transaction 1 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 and now you might ask why does Alice have to send money to herself here she's taken the 25 coins that were assigned to her in transaction 1 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 this is what's called a 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 want to 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 because we know exactly which input to look at so we just need to go to transaction 2 output 1 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 2 went to Alice with 8 coins therefore it's enough to cover the outputs of this transaction it's a finite backward 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's 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 tracked account values for each person but the nice thing is that 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 2 different transactions that send some money to Bob 17 coins in transaction 1 and 2 coins in transaction 2 Bob might say I'd like to have 1 transaction I can spend later where I have all 19 coins so this is pretty easy you just create a new transaction that has 2 inputs now and only 1 output so all of those coins go to Bob and you've combined the 2 previous transactions into 1 that Bob can then spend later similarly we can do joint payments pretty easily so let's say that's Carol and Bob both want to pay David we can have a transaction with 2 inputs that are actually owned by 2 different people and combine the value and pay all 8 coins to David and the only extra thing here is that since the 2 outputs that are being claimed here are owned by 2 different people we're going to need 2 separate signatures from 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 going to 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 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 3 parts there's some metadata there's a series of inputs and a series of outputs so we'll start with the metadata so there's some housekeeping information which is the size of the transaction the number of inputs and the number of outputs is 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 all the sum of all the inputs and then there's this funny thing 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 that looks like a script and in fact it is a script and we'll talk more about that very soon okay so like we said each transaction output doesn't just specify a simple public key it actually specifies a script so what do I mean by that what is a script and why do we use scripts in this section we're going to talk about what the bitcoin scripting language is and why script is used instead of simply assigning a public key okay so to understand scripts I think the easiest way is by an example and we'll take as an example the most common script in bitcoin which is to redeem a previous transaction by signing with the correct public key so this is what the output address would look like in that case the output address is really a script and in this case the script is going to have four instructions so what happens to this script who runs it, how does this script indicate who has the ability to spend these coins the secret is that the input address is also a script so that's a bit of script that you combine with the output address you simply concatenate them and that gets you a script that has to run successfully in order to claim a bitcoin so traditionally these two scripts are called scriptSig and scriptPublickey and that's because in the simplest case the output script just specifies a public key and the input script specifies a signature with that public key when a transaction is being validated the two scripts get pasted together they get run and if the concatenated script can run without any errors this is considered a valid transaction so where did this scripting language come from it doesn't really have a proper name it's just called script or the bitcoin scripting language and it was built specifically for bitcoin it was probably most inspired by a language called 4th which is an old stack based simple programming language but you don't need to understand 4th to understand bitcoin scripting the key design properties here were to have something that was quite simple quite compact but yet had support for pretty sophisticated cryptography so there are special purpose instructions to compute hash functions and to compute signatures and verify signatures and this is a stack based language and you may have never seen a stack based language before in your life but I'll explain on the next slide what that means and why that was chosen so there are a lot of limits here that you can keep in mind in particular there are no loops in the bitcoin scripting language every instruction is executed exactly once in a linear manner so if you look at a script just based on the number of instructions in the script you know exactly how long it might take to run and how much memory it could use so this is not a Turing complete language it doesn't have the ability to compute arbitrarily powerful functions in these scripts which are submitted by arbitrary participants in the network so you don't want to give them the power to submit a script that might have an infinite loop or might run forever and since it's not a Turing complete language we don't have the halting problem you can look at any bitcoin script and be sure that it's going to terminate within a finite number of steps which is just the number of instructions that are in that script ok now the fun part we're going to look at a specific bitcoin script and exactly how it's executed this is the same example as before this is the most common script in bitcoin a script where the sender of coins simply specifies the public key of the recipient and the recipient of the coins to redeem them has to specify a signature using that specified public key so the first two instructions in this script are simply data instructions like I said these are the signature and the public key used to generate that signature and these were specified by the recipient in that script SIG component or the input script so executing data instructions is easy in a stack based language if you see data you just push it onto the stack and that's the only interaction with memory that you have in a stack based programming language there's no variables so the only thing you can do to write data to memory is to push it onto the stack so after we've pushed those two values onto the stack we're going to start executing the second half of the script which was specified by the sender of the coins so this is the script pub key component of the script and now we're going to start to actually manipulate some of those values on the stack so this duplicate instruction op-dupe simply take the value that's on the top of the stack pop it off and then write two copies back to the stack so we're just going to duplicate that public key the next instruction hash 160 says take the top value on the stack and compute a cryptographic hash of it so this top value is going to be converted from the public key into a hash of the public key now we're going to do one more push of data onto the stack and this data remember was specified by the sender of the coins so this is the public key that the sender specified had to be used to generate the signature to redeem these coins so now at the top of the stack we have two values we have the hash of the public key as specified by the sender and the hash of the public key that was actually used by the recipient when trying to claim the coins and we'll just run this equal verify command which just says are the two values of the top of the stack equal if they aren't an error is going to be thrown and the script will stop executing but we'll assume that they are we'll assume that the recipient of the coins actually did use the correct public key that instruction will consume those two data items that are at the top of the stack so now we're left with two data items on the stack a signature and a public key and we've already checked that the public key was the right public key specified by the sender of these coins and now we want to check that the signature is actually valid so this is where the power of the bitcoin scripting language really comes into play there's one instruction here that lets you verify a signature so it's easy to write scripts that do signature verification without calling any special library to check the signatures that's all built into the bitcoin scripting language now one thing I haven't told you is what is this actually a signature of the signature function and turns out there's only one thing you can sign in bitcoin which is an entire transaction so this check sig instruction is going to verify that the entire transaction was successfully signed so in just one go hopefully the check sig instruction will pop those remaining two items off of the stack check that the signature is valid and now we've executed every instruction in the script there's nothing left on the stack and if we haven't had any errors the output of this script will be a simple yes so every bitcoin script can only produce two outcomes it can either execute successfully with no errors in which case the transaction is valid if there's any error while the script is executing the whole transaction will be invalid and shouldn't be accepted into the blockchain so a little bit more about the bitcoin scripting language it's very small there's only room for 256 instructions because each one is given one byte and of those 15 of them are currently disabled so you can't use them at all and 75 of them are reserved so haven't been assigned any specific meaning yet but might be instructions that are added later in time so there's a lot of the basic instructions that you'd expect in any programming language are going to be there there's basic arithmetic basic logic like if and then throwing errors, not throwing errors returning early and finally there are crypto instructions like I said so there are hash functions instructions for signature verification and there's a special very important instruction for multi-signature verification that's called check multi-sig so this even more powerful than checking just a single signature with one instruction, bitcoin actually lets you check multiple signatures with one instruction so with multi-sig you specify n public keys and you specify a parameter t or a threshold and for this instruction to be to execute validly there have to be at least t signatures t out of n of those public keys that are valid so we'll show some examples of what you'd use multi-sig for in a second but this is quite a powerful primitive that in a compact way in a scripting language you can express the concept that t out of n of these public keys must sign in order for this transaction to be valid so there's an important bug here there's a gotcha which has been there since the beginning of time which is that in the original implementation of this the check multi-sig instruction actually pops an extra data value off the stack and ignores it so this is just a quirk of the bitcoin language it's something that in programming you have to deal with by putting an extra dummy variable onto the stack and at this point it's considered a feature in bitcoin in that it's not going away the costs of removing it are much higher than the damage it causes so this is just a fun bug that everybody in the bitcoin community gets to live with so like I've said we have this whole scripting language that lets us specify in some sense arbitrary conditions that must be met in order to spend coins but as of today this isn't used very heavily so if you look at the history of bitcoin and look at what scripts have actually been used the vast majority 99.9% are exactly the same script which is in fact the script I showed you in our example of a script execution a script that just specifies one public key and requires a signature for that public key in order to spend the coins there's a few other things that have some use so multi-sig gets used a little bit and there's a special type of script called pay to script hash that I'll talk about in just a minute but other than that there hasn't been too much creativity in terms of what scripts people actually use and one reason for that is that bitcoin nodes by default have a white list of scripts and they refuse to accept scripts that they consider not standard this doesn't mean that those scripts can't be used at all it just makes them harder to use and I'll talk about exactly what that means a little bit later when we talk about the bitcoin peer-to-peer network okay so I mentioned that some of the scripts are what we call proof of burn so proof of burn is actually a script that can never be redeemed so if you have a proof of burn script it's provable that those coins have been destroyed there's no possible way for them to be spent this is quite simple to implement you just use this code op return which throws an error if it's ever reached and no matter what values you put before then that instruction will get executed eventually in which case this program will crash the data that comes after op return is never going to be looked at so this is an opportunity for people to specify arbitrary data in a script so what is the point of proof of burn? well there's two main things that this gets used for the first is to write arbitrary data into the blockchain and for some reason you want to write your name or if you want to timestamp and prove that you knew some data at a specific time you can create a very low value bitcoin transaction that's proof of burn so you can destroy a very small amount of currency and in exchange you can write whatever you want into the blockchain which should be kept around forever the other example of proof of burn we'll talk about in a later lecture on alternate currencies but it can be a way to bootstrap an alternative to bitcoin by forcing people to destroy bitcoin in order to gain coins in the new system so one thing that's funny about this is that the sender of coins has to specify the script exactly so this might be funny if you're a consumer, you're shopping online you're about to order something and you say alright I'm ready to check out I'm ready to pay, tell me the address where I should send my coins and the retailer came back and said oh well we're doing something fancy now we're using multi-sig we're going to ask you to send the coins to some complicated script you might say I don't know how to do that that's too complicated as a consumer I just want to send to a very simple address so in response to that problem there's a really clever hack in bitcoin which is that instead of having the sender specify the entire script the sender can specify the size of the script that is going to be needed to redeem those coins so this looks like the sender specifying a very simple script which just hashes the top value on the stack and checks to see if it's equal to the required redemption script so the receiver of those coins all they have to do, it looks like is just specify the right script and then this transaction will verify so the basic script is very easy to satisfy here the receiver just has to specify as a data value the value of the script whose hash the sender specified but after this happens a special second step of validation is going to occur where that top data value from the stack is going to be reinterpreted as instructions and then it's going to be executed a second time as a script so we see there were two stages that happened here first there was this traditional script which checked that the redemption script had the right hash and then the redemption script will be deserialized and run as a script itself and here's where the actual signature check is going to happen so this is called pay to script hash in bitcoin as an alternative to the normal mode of operation which is pay to a public key and the reason this was so complicated is that this was added to bitcoin after the fact this wasn't part of the initial design specification this is probably the most notable feature that's been added to bitcoin that wasn't there in the original specification and it solves a couple of important problems it removes complexity from the sender so the recipient can just specify a hash that the sender sends money to and it actually has a nice efficiency gain as we'll talk about later since miners have to track the set of output scripts that haven't been redeemed yet the output scripts are now as small as possible with pay to script hash because they just specify a hash and all of the complexity is pushed to the input scripts 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 satisfying public keys so one of them is to do an escrow transaction so this is a classic situation online Alice and Bob want to 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 and 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's 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's 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 going to send the money not directly to Bob but create a multi-sig transaction that requires two of three people to sign to redeem the coins and those three people are going to be Alice Bob and Judy who's a judge who's going to come into play in case there's any dispute so Alice will create this transaction for the desired amount with that two out of three multi-sig between Alice Bob and Judy Alice signs the transaction redeeming some coins that she owns and this will get published in the blockchain 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 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 multi-sig transaction so in the normal case this isn't that much less efficient when Alice just sending Bob the money it requires just one extra transaction on the blockchain 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 want to pay Bob because 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's going to 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 blockchain to see if a transaction that Alice is sending is actually there maybe Bob simply doesn't have the time to go and look at the blockchain and wait for the transaction to be confirmed remember that normally we want a transaction to be in the blockchain and be confirmed by six blocks which takes up to an hour before we trust that it's really in the blockchain or maybe Bob is just in a faraday cage and doesn't have any connection to the internet at all so Bob is never going to be able to check the blockchain this would be the case say if Bob is a 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 blockchain we have to introduce another third party which is the bank so Alice is going to 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 going to 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 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 you can accept that that money will eventually be his when it's confirmed in the blockchain now notice that this 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 going to collapse pretty quickly and in fact the two most prominent online services that implemented green addresses which were insta wallet 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 blockchain 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 the setup here is that Alice is a customer who wants to pay Bob a low amount of money for some service that she's going to 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 going to 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 she talks for two hours you might need over a hundred transactions the problem that you're going to get into in that system is that those transactions might be all very low value and the 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 going to work so we start with a multi-sig transaction that pays the maximum amount Alice would ever need to spend to a multi-sig 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 a transaction sending those coins that were sent to the multi-sig 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 going to keep sending these transactions to Bob every minute that she uses the service notice that these aren't getting published in the blockchain they're just getting sent from Alice to Bob eventually Alice is going to finish using the service in which case she'll tell Bob I'm done, you can cut off the service I'm not going to pay you anymore and Bob is going to say great I'll disconnect your service and I'm going to take that last transaction that you sent me and I'm also going to sign that and publish that to the blockchain giving Bob a little bit more and Alice a little bit less whatever the final one is is what Bob is going to 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 blockchain 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 blockchain 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 and ask her 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 going to want to 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 0 for the lock time that tells miners to not 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 time stamps 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 in that micro payments protocol as a safety valve for Alice to know that if Bob never signs he'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 into doing one of them is multiplayer 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 with Bitcoin using just the scripting language which is really neat there are other things like you can pay someone 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 can 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 a way to do it yet but you can do quite a few interesting smart contracts with the Bitcoin script so now let's talk about how Bitcoin blocks get put together so we've been talking about the blockchain and the fact that transactions are actually grouped by blocks but everything in this lecture so far we've been talking about just individual transactions getting published so why do we group transactions together into blocks? well a couple reasons one is that that creates a nice single unit of work for miners that's bigger than the individual transaction size so if the miners had to do work and do hashing and add metadata for every transaction in the system that would provide too much overhead it also makes the hash chain of blocks shorter because we only need one block for a large number of transactions and that's going to make it easier for us to verify the blockchain data structure so what does the blockchain data structure look like? it's a pretty clever combination of two different hash-based data structures so on the top here we have a hash chain of blocks each one has a block header and then a pointer to some transaction data as well as a pointer to the previous block in the sequence and remember these are hash pointers and then we have a tree of all of the transactions that are included in each block so this is a hash tree or what's called a merkle tree which commits to all of the transactions in the block in quite an efficient way so it's easy to provide just the path through the tree which will be logarithmic in size to prove that that transaction is included in a specific block so that's the high level idea behind a block what does it look like in practice at the low level so we'll do another deep dive into the actual data here so this is what a bitcoin block looks like there's what's called the block header which has all of the metadata for that block and then there's that merkle tree of transactions so basically a long list of transactions all of the hashes are arranged in this tree structure which gives you the ability to efficiently prove which transactions are included in a block the most important part of course is the header which mostly has information related to the mining puzzle which was talked about in the lecture on consensus and we'll revisit in the lecture on mining but recall that the most important thing here is that the hash of the block header has to start with a large number of zeros for the block to be valid and then there's some other data to make that happen there's a nonce that miners can change there's a time stamp there's an indication of how difficult this block was to find that's all stored in the header and the important thing is that the header is the only thing that's hashed during mining and to verify that chain of blocks all you need to do is look at the headers and the only transaction data that's included in the header is that one root of the transaction tree so that's this merkle root parameter the other thing that's interesting about blocks is that they have one special transaction in the merkle tree which is unlike all the other transactions we looked at before and this is the coin based transaction so this is where the creation of new coins in bitcoin happens and mostly it looks like a normal transaction with a few exceptions so the value of this transaction is going to be equal to currently a little over 25 bitcoins as we discussed this is a flat mining reward which is set by the system and which is having every four years in practice it will be a little bit more than 25 bitcoin because it also gets to include the transaction fees collected from every transaction included in the block so the pointer to the output transaction that this coin based transaction is receiving is a null pointer it's a hash of all zeros and this is an indication that since this is the creation of new coins there is no antecedents there's no previous transaction that's being consumed to create these coins and there's also this special coin based parameter and the coin based parameter is completely arbitrary the miners can put whatever they want in there so famously in the very first block ever mined in bitcoin the coin based parameter had a quote from the newspaper it had a quote from the Times of London describing a story involving the chancellor bailing out banks which was both a political commentary on the motivation for starting bitcoin and served as a commitment that bitcoin the first block was obviously mined after this newspaper came out but since then miners are free to put whatever they want in the coin based parameter it's been used as a place to put some arbitrary data for different reasons to signal support by miners for different new features but there's no actual limits on what miners can put in there so with both the block format and the transaction format that we described earlier the best way to learn it is to just see for yourself so there's a lot of websites that make this data accessible this is a screenshot from blockchain.info which I found very helpful myself in understanding and exploring what's going on at a low level in bitcoin there are a lot of other websites that do a great job of making this information accessible so you can look at the graph of transactions see which transactions redeem which other transactions look for transactions with complicated scripts you can look at the block structure and see how blocks refer to other blocks it's all available online because again the bitcoin is a public data structure so a lot of different people have put very pretty wrappers around this to explore it graphically so we've been talking about the ability for participants to publish a transaction and get it into the blockchain as if this happens by magic of course it doesn't happen by magic in the real world it happens through the bitcoin network so what is a bitcoin network? it's a peer-to-peer network so it inherits a lot of ideas from peer-to-peer networks that have been proposed for all sorts of other purposes it's a peer-to-peer network where all nodes are equal there's no hierarchy, there's no centralized special nodes, no master nodes every node on bitcoin is an equal peer it runs over TCP, it has a random topology so there's random nodes that are paired with random other nodes and new nodes can come in any time so you can download the bitcoin client today you can spin your computer app as a node and you'll be a participating bitcoin node with equal rights and capabilities as every other node on the bitcoin network now the network is very dynamic, it changes over time nodes are coming and going all the time although there's actually no explicit way to leave the network instead if you don't hear from a node for a while three hours is the amount that's hard-coded into the common clients people eventually start to forget you so it gracefully handles nodes going offline so what does that mean that you can simply join the bitcoin peer-to-peer network at any time? well if this is a picture of the network at one moment in time obviously scaled down quite a bit with just seven nodes but this is a picture of what it might look like seven nodes with all random connections to each other and notice that the numbers are scattered around here because there's no geographic topology here networks connect other nodes in a random fashion by design now if you launch a new node and say you want to join the network you start with a simple message to one node that you know about so all you need to know is how to get to one node that's already on the network this is usually called your seed node and there's a few different ways you can look up lists of seed nodes to try connecting to but you find your seed node and you send a special message saying tell me all the peers that you have tell me the addresses of all the other nodes in the network that you know about and that node will respond and say well I'm peered with nodes one and seven you can try them and then you might go talk to one and seven and say hey tell me everybody on the network that you know about and they'll send you the nodes that they know about and you can iterate as many times as you want until you have a list of peers to make connections with and then you can choose which ones to peer with and you'll be a fully functioning member of the Bitcoin network and again there's a few steps of randomness here so depending on which seed node you used or which of the peers of the seed node you decided to go and talk to you'll end up with a random set of nodes that you're connected to but that's perfectly fine so now that you're a member of the network what is the network good for? well the network maintains the blockchain so if you want to publish a transaction you want to get the entire network to hear about it and there's a simple flooding algorithm to make this happen so let's say that node 4 here here's about a new transaction so Alice wants to pay Bob some money Alice creates a Bitcoin transaction and submits it to node 4 or maybe her wallet software or her exchange does that on her behalf but somehow this transaction gets to node 4 now node 4 says great I've got a new transaction Alice wants to pay Bob let's tell everybody about it sometimes this is called a gossip protocol because it's very simple if you have news you try to tell as many people as you can and they try to tell as many people as they can much like people gossiping in the real world great so node 4 is going to talk to its neighbors node 3 and node 2 and say hey check out this new transaction Alice wants to pay Bob and those nodes will add it to their own pool of pending transactions so each node maintains a list of all the transactions they've heard about that haven't been put into the blockchain yet and then they can decide to forward that on to other nodes so 3 is going to talk to its neighbors and say new transaction for you Alice wants to pay Bob that'll end up in their transaction pools and so on and we want to make sure that this process doesn't go on forever so let's say that node 2 comes along later and tries to tell node 7 hey new transaction Alice wants to pay Bob node 7 is going to say that's alright node 2 I've already heard about that I already got it in my memory pool I don't need to forward it further so eventually this thing has to stop because every node will have heard about the new transaction and they won't forward it anymore and remember every transaction is identified uniquely by its hash so each node can tell they've seen that hash before and that they don't need to keep forwarding that transaction so it won't loop around the network forever so how do nodes decide when they hear about a new transaction whether or not they should propagate it the most important thing they do is they check to see given their view of the blockchain whether or not this transaction is valid so they do all the transaction validation we talked about earlier they run the script they see that the script checks out they see that the coins that are being redeemed here haven't already been spent and if all of that checks out then this looks like a valid transaction that they should try to relay with a couple of other caveats a default nodes won't relay the transaction if it's a non-standard script if the script has any weird features if it doesn't match a fairly simple white list of scripts that nodes know about even though it's a valid transaction the nodes won't relay it they'll also make sure that they haven't seen the transaction before that's that condition to avoid infinite loops and there's another property which is that they won't relay the transaction if it looks like a double spend so if they've seen a transaction where Alice tries to send some specific coins to Bob and then later they see a second transaction where Alice tries to send those same coins to Charlie the node shouldn't relay the second transaction even though either transaction could be valid because those coins still haven't been spent they'll only relay the first one they hear and that's an extra guard against double spending but it's important to keep in mind that all of these checks are just sanity checks so well behaving nodes all implement these to try to keep the network healthy and running properly but there's no rule that says that nodes have to follow these specific steps so since it's a peer-to-peer network and anybody can join there's always the possibility of a node not following this exact protocol forwarding double spends, forwarding transactions that aren't standard forwarding transactions that aren't valid and that's why it's important that every node do the checking for itself so it's possible that nodes will end up with a different view of the pending transaction pool based on what they've seen so let's go back to this example where node 4 originally relayed a transaction where Alice was trying to pay Bob and let's say that this transaction hasn't yet flooded to the entire network and before it gets to everybody node 1 is going to announce a new transaction and say hey I just heard Alice is trying to pay Charlie now from node 1's perspective this is a valid transaction and they haven't seen the other transaction where Alice is trying to pay Bob so node 1 is going to implement the protocol normally and is going to tell all of her neighbors about it now the neighbors that haven't heard the conflicting transaction yet will add it to their transaction pool whereas other neighbors like node 6 in this example they've already received a transaction where Alice is trying to pay Bob so node 6 is going to say I don't want to hold two conflicting transactions in my pool I'll just keep the one I already have the network may end up in a divided state here where different nodes have a different view of what the pending transaction pool is but that's fine these transactions haven't been published in the blockchain yet so this is just a temporary state where nodes disagree on which transaction should be put into the next block in practice this is a race condition if nodes have a different perspective on which transactions are pending or which blocks have been accepted that's okay in a temporary state and eventually they'll sort it out so in the case of transactions if different nodes have a different view of the pending transaction pool depending on who mines the next block they'll essentially break the tie or the race condition and decide which of those two pending transactions should end up being put permanently into a block and once one of those two transactions has been put into a block other nodes will see that the transaction that they're holding onto in their pool is now never going to make it into a block because it would be a double spend and they'll just drop it so if the transaction where Alice tried to pay Bob successfully makes it into a block first the nodes who heard the transaction where Alice tried to pay Charlie would just say that's not a valid transaction anymore so I can forget it so the default behavior is for nodes to just hang onto whatever they hear first which means that network position matters if two conflicting transactions or two conflicting blocks get announced at two different positions in the network they'll both flood in opposite directions and the nodes which end up with one transaction or the other will depend on which side of the network they started out closer to of course this assumes that every miner implements this logic where they keep whatever they hear first but there's no central authority in forcing this so every node is free to do whatever logic they want so if for some reason if any node wants to they can choose to implement any other logic they want for choosing which blocks or which transactions to forward we'll talk about that more in our lecture on mining why miners might want to implement some different logic other than the default now I've been talking mostly about transactions here the logic for announcing new blocks whenever miners find a new block is almost exactly the same as propagating a new transaction so the same algorithm is used to announce new blocks around the network it's the same flooding algorithm, the same gossip process and in this case instead of verifying that the transaction is valid by running a script the nodes are going to verify that the new block is valid by computing the hash and making sure that it starts with a sufficient number of zeros to meet the difficulty target now validating a block is also much more in depth because in addition to validating the header and seeing that the hash value is correct nodes are asked to validate every transaction included in the block to make sure that the block contains only valid new transactions and the other check which is this really important critical part that makes Bitcoin consensus what it is is that nodes shouldn't forward a block unless it builds on their perspective of the current longest chain so they have a view of the block chain and they should only forward new blocks if they come at the very end of the chain not at some earlier point and this avoids forks building up so just like with transactions nodes can implement different logic if they want they're free to relay blocks that aren't valid or to relay blocks that build off of an earlier point in the block chain so some nodes may be trying to relay a block that doesn't extend the current longest chain that actually builds a fork and that's okay the protocol is designed to withstand that so how long does this flooding algorithm actually take how much latency is imposed here this is a graph showing the average time for new blocks to propagate to every node in the network and the three lines show the 25th, the 50th, and the 75th percentile of how long it takes for a new block to reach every node in the network and if you look at the 75th percentile there for some of the larger blocks and this is heavily dependent on size because of bandwidth constraints that some nodes have you'll see that the average propagation time is over 30 seconds so this shows that this isn't a particularly efficient protocol on the internet 30 seconds is a pretty long time for people to hear about something the reason it takes so long is because the protocol is not very efficient it wasn't designed to be efficient it was designed to be simple and to have no structure so that every node is equal and they can come and go at every time and as a result the topology may not be optimized for fast communication a block may need to go through many nodes before it reaches some of the most distant nodes in the network whereas if you design the network top down for efficiency you would design it to make sure that the path between any two nodes was very short for Bitcoin it's more important to have a decentralized structure where all nodes are equal even if that means that the propagation time can be over 30 seconds in some cases so how big is a Bitcoin network? well there's no official statistics anywhere because again there's no central authority overseeing it it's simply whatever the nodes participating they are the Bitcoin network so it's impossible to measure exactly and it's changing all the time but a number of researchers have looked into this and tried to come up with estimates on the high end some researchers have said that over a million IP addresses in a given month will at some point be running the Bitcoin protocol and acting at least temporarily as a Bitcoin node but if you look at full nodes that are actually permanently connected and are fully validating every transaction they hear and running the full protocol it's only about 5 or 10,000 which may be a surprisingly low number and in fact that number may be dropping there's no evidence that the number of fully validating nodes is going up and there's some concern that the number of fully validating nodes is actually going down so to be a fully validating node you want to stay permanently connected so that you hear about all data the longer you're offline the more catch up you're going to have to do to hear about all the transactions you missed and you're going to have to store the entire blockchain you'll also need a pretty active network connection so that you can hear every new transaction and forward it to your peers so you can see the growth over time here and currently it takes about 20 gigabytes to store the entire blockchain which isn't too bad if you have a few years old PC with an active network connection you have what it takes to be a fully validating node although you basically need to dedicate that machine to doing that and not much else fully validating nodes maintain the entire set of unspent transaction outputs so every coin that's available to be spent and remember those are just unspent output transactions ideally you'd like to store this in RAM so that when you hear a new proposed transaction on the network you can quickly check the transaction that it's attempting to claim run the script and see if the signature is valid so currently there are about 12 million unspent transactions and that's out of 44 million transactions that have ever been proposed so fortunately that's still small enough to fit in less than a gigabyte of RAM and an efficient data structure so that if you're running a fully validating node every time you hear about a new transaction you can quickly check, run the redemption script and see that this is a valid transaction that you should put in your pending transaction pool so in contrast to being a fully validating node there are lightweight nodes also called thin clients or simple payment verification clients this is actually the vast majority of nodes on the Bitcoin network and the difference here is that these nodes aren't attempting to store the entire blockchain they only store the pieces that they need to verify some specific transactions that they care about so for example if you run a wallet, your wallet might want to be a simple payment verification node and if somebody sends money to you, you'll act as a node you'll download the bits of the blockchain that you need to verify that the person sending you the money actually owned it and that the transaction sending it to you actually gets included in the blockchain but you won't care about the thousands of other transactions going on that don't affect you now an SVV client like this won't have the full security level of being a fully validating node and the reason is that when they hear a new block the only thing they can check is the block header they can check to see that the block was difficult to mine but they can't check to see that every transaction included in that block is actually valid because they don't have the entire previous blockchain, they don't know the entire unspent transaction output set they can only validate the transactions that actually affect them so they're essentially trusting the fully validating nodes to have validated all the other transactions that are out there so this isn't a bad security trade-off, you're assuming there are fully validating nodes out there that are doing the hard work and that if miners went through the trouble to mine this block which is a really expensive process they probably also did some validation to make sure that this block wouldn't be rejected and the cost savings of being an SPV node are huge it's about a thousand times smaller to just store block headers and to store all of the previous transactions so instead of storing about 20 gigabytes of data you're down to about 20 megabytes which is something that almost anybody on a PC or even on a phone can store and act as a limited node in the Bitcoin network so how many different implementations are out there? since this is an open protocol ideally what we would want is that there are a bunch of different implementations that are all interacting with each other seamlessly and that way if there's a bad bug in one the entire network is not likely to crash at once so the good news is that the protocol has been successfully re-implemented there are a couple of different implementations out there there are implementations in Java, in C++, in Go and people are working on quite a few others but about 90% of the nodes on the network are running the core Bitcoin library written in C++ where the core Bitcoin developers work some of which are previous out-of-date versions that haven't been updated but most are some variation of this one common client so this might be a risk to the network if there was some bad software bug that caused all of those nodes to crash you would knock the majority of the network offline there's also one other client which people are quite curious to study although isn't actually run anymore which is the original Satoshi client so this is the code that was written with the very first version of Bitcoin that was released as far as I know nobody is running that on the actual network anymore so famously the code was very bizarrely written very brilliantly written in a lot of ways but also very difficult to maintain so that client is basically a historical curiosity now so finally we'll talk about some built-in limitations to the Bitcoin protocol and why it's challenging to actually improve them there are a lot of hard-coded constants that are implemented into the Bitcoin protocol which were chosen when Bitcoin was proposed in 2009 before we really had any idea that it might grow into this globally important currency so the most important limits are probably the limits on the average time per block the size of blocks, the number of signature operations in a block and the divisibility of the currency the limitations on the total number of Bitcoins in existence as well as the structure of the mining rewards are very likely to never be changed because the economic implications of changing them are too great miners have invested a lot of real-world resources into becoming miners assuming that Bitcoin rewards would take a certain shape and that the limited supply of Bitcoins would remain the way it's been planned so if you change that that would have large financial implications for people so for that reason the community has basically agreed that those values whether or not they were wisely chosen were basically stuck with some other changes you'd like to make seem like they would make everybody better off things about Bitcoin that just weren't quite properly designed at the beginning but are also hard to change the main aspect of Bitcoin that people are worried about and would probably like to change if they had time to design it over again are limits that affect the throughput of the system how many transactions can the Bitcoin network process per second so this limitation comes from the hard-coded limit on the size of blocks each block is limited to a million bytes and each transaction has to be at least 250 bytes so if you divide through and the fact that blocks are found every 10 minutes you're left with about seven transactions per second which is all that the Bitcoin network can handle and it seems like tweaking those numbers would be very easy it's just one constant in a file somewhere that you'd have to change it would actually be very hard to change this in practice for reasons that will become clear in a few seconds so how does seven transactions per second compare? well if you went down to the offices of Visa and told them I'm proposing a new payment system that can handle seven transactions per second they would probably tell you that's terrible and then they would laugh and throw you out the door they've been working for a long time to build a payment network that goes way bigger than this so it's said that Visa handles on average about 2,000 transactions per second around the world and on the busiest times so think the Saturday before Christmas when everybody's out shopping and swiping a credit card the Visa network can handle about 10,000 transactions per second and other payment card networks are similarly big you can also look at PayPal which is not as big or as old as Visa but even PayPal can handle 100 transactions per second at peak times so in order of magnitude more than Bitcoin another limitation that people are worried about in the long term is that the cryptography in Bitcoin is fixed there's only a couple of hash algorithms and there's only one signature algorithm which is Elliptic Curve DSA over a specific Elliptic Curve called SEC P256 and there's some concern that over the lifetime of Bitcoin which people would like to be for a long time this algorithm might be broken cryptographers might come up with a clever new attack that we haven't foreseen which makes us an insecure algorithm and the same is true of the hash functions hash functions in the last decade have actually seen steady progress in cryptanalysis with SHA-1 which is included in Bitcoin already having some known cryptographic weaknesses so to change this we would have to extend the Bitcoin scripting language to support new cryptographic algorithms so what would it look like to make a change like this where we just said we had a problem with Bitcoin we're going to release a new version of the software and everybody is going to have to switch this is what we would call a hard forking change so in practice it's impossible to assume that every node would upgrade some nodes in the network would fail to get the new software or fail to get it in time and what would be the implications of that well let's take a look at a network here where most of the nodes have upgraded but there are a few that haven't and now let's say one of the new nodes says hey I found this nifty great new block maybe it has some new signature algorithm in one of the transactions using the new features that we've added to Bitcoin so block 4 has found this and says okay I'm going to update and say that's now the newest block so I'm at block index 24 the rest of the network is at 23 but I'm going to propagate that to all of my peers using the normal block flooding algorithm so node 4 is going to send block 24 out to its neighbors nodes 3 and 2 node 3 is going to get it and say great I got that one I'll update my version of the blockchain to have that as the newest block whereas node 2 is going to say that's crazy you have some operation code that is disabled or reserved I have to reject this block I don't understand it I can't accept it and similarly when it gets over to node 6 node 6 is also going to say nope I can't accept that block either and now you're going to end up in a state where the new nodes have one picture of the blockchain and the old nodes have all refused to accept this latest block so the new nodes will go off and work on a version of the blockchain including this new block with the new fancy feature and the old nodes will all be stuck on an old version of the blockchain and unfortunately they're never going to catch up because until they upgrade their software they'll keep rejecting all of the blocks that are proposed by the nodes in the network that have upgraded to the new version of the protocol so the reason it's called a hard fork is that the blockchain will split every node in the network will be on one side of it based on which version of the protocol it's running and they'll never join together again and this is considered unacceptable by the community that old nodes would effectively be cut out of the Bitcoin network if they don't upgrade their software so by contrast there's an approach called soft forking which tries to avoid creating a permanent fork like this the observation is that we can add new features to the Bitcoin protocol if they only restrict the set of valid transactions or the set of valid blocks because we want to avoid this hard fork situation we can try to add new features in a way that will cause only a soft fork so the key to making this happen is that the new features can only make validation rules stricter they can only limit the set of blocks or the set of transactions that are considered valid so the new nodes in the network will be enforcing some new tighter set of rules so we're relying on enough nodes switching to the new version of the protocol that they'll be able to enforce the new rules knowing that the old nodes won't be able to enforce the new rules because they haven't heard of them yet there is a risk here which is that old nodes might be mining an invalid block because they include some transaction which used to be valid but according to the new, more strict rules is not valid anymore so that could be bad those nodes could waste a lot of time mining a block that the new nodes will reject but when they try to announce that new block, the new nodes will reject it the old nodes will at least figure out that for some reason, even though I don't understand the reason the rest of the network has rejected my new block therefore I should move on to the version of the blockchain that all of my peers have and it won't be a hard fork they'll have a temporary fork by virtue of the new block they tried to mine that was rejected by the network but they'll recover and get back on to the main chain so the classic example of a change that was made via a soft fork was pay-to-script hash which we introduced earlier in the section discussing the scripting language so the view of pay-to-script hash from old nodes and again pay-to-script hash was not present in the first version of the Bitcoin protocol they see this script as really simple all it's doing is hashing this one data value and checking to see if it's equal to the value specified in the output script the old nodes never do that second step of verification in pay-to-script hash where they then check to see that that value before being hashed runs as a valid script so what could we possibly add with a soft fork? pay-to-script hash was successful it's also possible that new cryptographic schemes could be added by a soft fork or that we could add some extra metadata in blocks that had some meaning and the place you'd add this is in the coinbase parameter so today any value is accepted in the coinbase parameter but we could in the future say that the coinbase has to have some specific example one idea that's been proposed is that in each new block coinbase contains a merkle root of the entire set of unspent transactions it would only result in a soft fork because old nodes might mine a block that didn't have the required new coinbase parameter that got rejected by the network but they would catch up and join the main chain that the network is mining other changes might require a hard fork that would be if we wanted to add new opcodes to Bitcoin change the limits on block or transaction size or do a lot of bug fixes for example the bug I showed earlier where the multi-sig instruction pops an extra value off the stack that would actually require a hard fork and that's the reason why even though it's an annoying bug that people wish wasn't there anymore it's much easier to just leave the bug in the protocol and have people work around it rather than have a hard fork change to Bitcoin so all of these hard forking changes even though they would be nice they're very unlikely to happen at least within the current climate of Bitcoin but a lot of these ideas have been tested out and proved to be successful in alternative currencies which start over from scratch and we'll be talking about those in a lot more detail in our lecture on altcoins so I spent a lot of time talking about details today I know this has been a long lecture with a lot of technical detail very hard to absorb at all at once so like I said I would certainly recommend you can go online and see some of this stuff and practice see what blocks and transactions look like it took me a couple of times looking at them before I really had a good sense of what was going on but I think the practical examples do really help in the next lecture given all these mechanics we've introduced we're going to look at the human side of things because after all human beings aren't Bitcoin nodes and you're never going to run a Bitcoin node in your head so how do you as a human actually interact with this network to get it to be usable as a currency how do you find a node to tell about your transaction how do you get Bitcoins in exchange for cash how do you store your Bitcoins so all of these questions are crucial for making the currency that will actually work for people as opposed to just software