Video - Bitcoin Multisig and P2SH Transactions
Bitcoin SF Devs Multisig Transaction class with Andreas Antonopoulos covering simple transactions, simple multisig transactions and P2SH transactions in bitcoin. He explains the technicalities on multisig protocols.
TRANSCRIPT
Andreas: All right. Transaction scripting at multi-sig.
Unidentified Male: Take one.
Andreas: Well, intentionally synchronize the audio. All right. So last time, we talked about Bitcoin overview and we looked at its transactions. And transactions have inputs and outputs. I'm going to use different works today to describe the same thing. So outputs express incumbrances. And incumbrance means a limitation of who could spend something. So when you creates a Bitcoin transaction output, what we're saying is these outputs can only be redeemed by X. And that X is an incumbrance. And the incumbrance is expressed in the form of a script. Most common incumbrance, which we'll see in a second, is the one that simply allows signature from one of the Bitcoin public keys. So it basically means the only person (Inaudible 00:00:56) is whoever has this key. All right. That's the basic, Alice pays Bob one Bitcoin and the incumbrance is Bob can redeem with Bob's key. All right. So if you have a transaction, you're having a series of inputs and a series of outputs, all right. So you have input zero, input one, etcetera, and output zero, output one, etcetera, right. You should think of each outputs as a puzzle that takes a key, right. So let's say, for example, this is an output, all right. And this output has a specific input key that unlocks that particular output, right. So--
Unidentified Male: You can write?
Andreas: Yes.
Unidentified Male: Can you write a curve (Inaudible 00:02:13).
Andreas: All right. We'll take a photo of it after.
Unidentified Male: Yeah.
Andreas: All right. So this output is called the incumbrance the second it goes. Can anybody see that? All right. That output is called an incumbrance. And Bitcoin terminology is called a Script -- let me try to get it right. It's called the ScriptPubKey. ScriptPubKey. It's called the ScriptPubKey even though in some cases it might not be a public key at all, all right. Simply because in the original transaction language, it was a script appointed to a public key, saying Bob's key. It's incumbrant by Bob's key. The envelope key, this one is called the ScriptSig, which means a signature that unlocks this ScriptPubKey, right. So when you use an output as part of an input when you're verifying, the input is providing this thing, the input key in the transaction. And it's referring to a previous output in the blockchain by reference to the transaction in index. So it's saying from the transaction X from last week, I'm taking the second output. And here is a ScriptSig that's unlocks it. That's how you define an input. And then you say end, I'm sending that to this new output, which is ScriptPubKey. And in order to redeem that, somebody has to offer a ScriptSig when they reference to this, the inputs, right. So if you think about this, if you use the same shapes, you know, these are little keys and these are little incumbrances. Think Tetris, right. So in a transaction, the output is this bit and then the input refers back to a previous output and provides a little key that opens it. So if you have another transaction below here and that has another inputs--and this (Inaudible 00:04:50) how long--
Unidentified Male: That's better.
Andreas: All right.
Unidentified Male: It's wonderful.
Andreas: So if this has an input, what we're looking for is this input, only fit there.
Unidentified Male: Uh-huh.
Andreas: Like those input, all right. So this input says I'm going to use this output here and here is my key. And a client, it's verifying this transaction and go and download this TXO, this transaction outputs who lock the ScriptPubKey, which is the incumbrance matches to the ScriptSig which is the key that you provided. And that produces a verified transaction. And then you send an output, which again is a different type of incumbrance, unlocks into someone else. And so what you're doing each time is you're removing an incumbrance for your previous outputs and adding an incumbrance to a new output, all right. You're essentially transferring the value by unlocking it from the ownership and relocking it to the new ownership. So far so good? All right. Notice something here, inputs don't have incumbrances. The script is always in the output. So here the input is referring to a previous transaction, it's says the transaction 27355 input number one is what I'm using, and here is my ScriptSig, the key that unlocks it. One of the critical considerations when you're doing transactions scripting is where does the script, the thing that has lots of data in it, go. There is a critical consideration Bitcoin in that at the moment, the sender pays the fee to create these incumbrances. So the scripts which are the outputs, the incumbrances, which are bigger in size, much bigger than simply a key, right. The scripts that make up this transaction are paid forth by the sender. The recipient puts a much smaller piece of data, which is a ScriptSig in their transaction. So there is an issue, a very deliberate issue here, and we see how that changes when we talk about Pay-to-ScriptHash. With Pay-to-ScriptHash, the burden is actually reverse, which means that you only put a hash of the script in here and then the script is provided as a sig here. And that shifts all of that burden, the data of the incumbrance. Instead of being in the output of the sender, it's in the inputs of the recipients. Another thing that does is, here we're putting the data heavy incumbrance in the blockchain early with Pay-to-ScriptHash, and this is very deliberate. The incumbrance is put in the walk only when it's redeemed, which means that the actual large amount data goes into the transaction as introduced much later in the process (Inaudible 00:08:16 out if it's redeemed. So that was a deliberate change that happened. And one of the reasons Pay-to-ScriptHash is use is to shift the load of data from being output in transactions that are paid by the sender and put into the blockchain early. Put most of the data as input in the redeeming transactions paid by the recipient who got the value after all and go into the blockchain later. And that's an important change because it reduces blockchain (Inaudible 00:08:46), right. You don't actually put all the big data in there until you're ready to redeem it. It makes sense. All right. So let's look at the most specific example of a ScriptHub and a ScriptSig that's used to do the basic, Alice pays Bob one Bitcoin, right. So now I'm going to read it off here because (Inaudible 00:09:13) white board because I'm going to read it again, all right. So if Alice is creating an output to give Bob one Bitcoin, that output is going to look like this, opt of Bob has 160, the Hash of Bob's key, (Inaudible 00:10:22) we're verifying (Inaudible 00:10:24). So this transaction scripting language is a forth-like left to right stack-based average, right. It's (Inaudible 00:10:33) to the reverse polish notation calculator, or forth (Inaudible 00:10:37). And what we're going to do is look at how this is actually evaluated by creating a stack and then evaluate to the script from left to right. Now this thing, anybody want to tell me what this is? This whole thing, it's found in an output. It has a funny name over there (Inaudible 00:11:08). So now this is a ScriptPubKey. This is the incumbrance. It says only Bob can repeat this. This is the incumbrance in the output that Bob created. So this is actually found in the transaction output and it's an incumbrance. It's a script, the limits the redemption of this outputs to reverse specific recipients who ever can produce a signature matching Bob's hash, right. So that's the incumbrance. And so this is called the ScriptPubKey, all right.
Unidentified Male: So (Inaudible 00:11:51) describe (Inaudible 00:11:55) language, I don't know exactly referring to the white board. Anyone?
Andreas: Oh yes.
Unidentified Male: I think most people out here is --
Andreas: Right.
Unidentified Male: -- (Inaudible 00:12:01).
Andreas: So going to an example of stack-base language, we'll execute these parts steps by step so you could see exactly how it works. First, let's looks how these all fits together. So that's an output, right. How does Alice redeem that? Or rather, sorry, how does Bob redeem that? Bob has created transaction which has, as an input, a reference to this previous output. This is an unspent output. So Bob would create a new transaction where he would refer to this as a previous inputs and unspent transaction outputs, which is now an input, right. What else does Bob need to write? The ScriptSig, right? He needs to provide this part. So this incumbrance is in the transaction from Alice to Bob. Now Bob, if he wants suspended this, creates an input that refers back to it, right, doesn't include that script. That's already in the blockchain. It's buried as Alice's output. Bob creates a new input that's says, "Go, look at the blockchain, find this transaction. I'm going to spend that first output." And so the second thing Bob provides is a ScriptSig, all right. So quick detour, let's have some fun with reverse polish notation, all right. So this is a reverse polish notation calculator. It's basically a stack-based calculator. And the way this is executed is -- so this is 63 plus one times 5 plus 7 times.
Unidentified Male: Okay.
Andreas: This is how you would write calculator expression in a reverse polish biometric. And the way it works is you have operands, basically piece of data. And they have operators and the operators do things to the operand. And they get put on the stack and the stack is a first in, last out stack, all right. The best way to write this is to draw the stack, right. And then what you want to do is you start moving your execution (Inaudible 00:14:38), which is here, you start from the left and you run to the right, all right. So the first thing we do is we find data. What do we do with data? We put it on the stack. So the two goes on the stack, it's removed from there, right. Execution point then moves one step further. Yep, what do we do with the three? Put it on the stack. The two moves down, three goes on top of it. For now, the plus, right. What does an operator do? It takes values from the stack, pops them, does the calculation, and then puts the result back on the stack. So what this is going to do? If I plus it as a (Inaudible 00:15:37), it takes two values, right. You can have unitary operators. Hash 116 is the unit to operate, as is opt two. The plus is the minor operator, it takes two parameters. So it's going to pop two and three off the stack. It's going to add them together and it's going to put the result back in the stack. We're done with the plus, move the execution to the next character, all right. What do we do with the data? We put it on the stack. First, we get it to make sense.
Unidentified Male: Yeah.
Andreas: I know that's completely bizarre, all right. So we move over. Okay. We got one and five on the stack.
Unidentified Male: Five.
Andreas: Multiplying so that opt (Inaudible 00:16:30), and that's five. Oh, so it matched.
Unidentified Male: Okay. So you increase left to right input of the profit?
Andreas: Always increase from left to right.
Unidentified Male: Okay.
Andreas: Going down --
Unidentified Male: Good. Got it.
Andreas: This is going to be easy if you implement it on machine. That's why we use forth-like languages because in machine codes, you can implement this in using a stack in an abstract state machine that includes them. It's very easy to read the grammar and you don't need the specific sophisticated cursor. It's very easy to (Inaudible 00:16:57), all right. So put another five on the stack, add them together, put a seven on the stack, multiply this together. And their execution, the final result is on the stack. Everybody got that? Yep. It's a lot easier to demonstrate with a calculator. Now let's do the same thing over here over this. So what Bob does in order to redeem this is he provides an input key or ScriptSig. So this is ScriptPubKey. Let's look at the ScriptSig now. This ScriptSig that Bob provides is a signature. I'll call that Bob's sig. And the key, I'll call that Bob's key, all right. So far so good, all right. So what the client does in order to verify this transaction is calculates. So what you get on the stack, multiply sig, make a little stack here, write a correct execution line in here, and we'll write it all down. Now this time much smaller letter side of our now white board space. So that would be Bob's sig, Bob's key, Bob key 2, Bob key hash, Bob's hash. Fine. I'm going to do it on two lines because I'm running out of space already. Actually, (Inaudible 00:19:18).
Unidentified Male: You should be going to the right.
Andreas: All right. So essentially, what the system is doing is the same. In order to verify this transaction, I'm going to take the ScriptSig. I'm going to take the incumbrance that it supposed to be unlocked from the previous output. I'm going to put the ScriptSig followed by the ScriptPubKey into my stack language. So here we've got ScriptSig and here we've got ScriptPubKey. These came from two different transactions. This one came from the output of the previous transaction and this one came from the input of the transaction that we're trying to reveal, right. See there are two different transactions. I was provided ScriptPubKey to pay Bob. Bob provides ScriptSig to unlock that. Are you following the concept here?
Unidentified Male: Uh-huh.
Andreas: All right. So who wants to run through this? Yes.
Unidentified Male: Are these two stacks number, the seventh stack there?
Andreas: Oh, yes. One, two, three, four, five, six, seven items of the stack. It's one script, you can captivate it. You know, that means you can put anything you want in a ScriptSig and anything you want to the ScriptPubKey as long it's one of the acceptance (Inaudible 00:21:14) transactions. It's rather unlimited. As more and more are allowed, the more complex types of transactions you could create is (Inaudible 00:21:23) acknowledge, right. At the moments, each part has to be a valid Bitcoin transaction. So we'll see how this work to multi-sig, too. Well, this is more (Inaudible 00:21:32). Any question so far?
Unidentified Male: (Inaudible 00:21:38) Bitcoin talk that (Inaudible 00:21:40) test scripts or something that approximates (Inaudible 00:21:49).
Andreas: Right.
Unidentified Male: (Inaudible 00:21:50.
Andreas: That's a great question. I would expect that you would have to force Bitcoin to try to verify of all transaction without getting it from the blockchain. So that you can just see that the series of all transactions and see how it evaluate. (Inaudible 00:22:14) modular Bitcoin is as you can simply pull out and invoke the function without the transaction verification and see that random inputs in which case you could create a test suite that includes the whole verity of this combinations and then just have it verified either individually or in the whole thing. Probably, yeah. So who wants to run through this? Yeah.
Unidentified Male: That's incredible.
Andreas: Okay, so Bob sig go on the stack and Bob key goes to profit. I'm just doing both of those steps simultaneously so we move through this, we move this onto the stack, right. Okay. Opt two duplicating takes one operand and doubled it, all the stack. So what it will do is actually (Inaudible 00:23:16) Bob key and then it will push Bob key, Bob key, twice. I'm probably going to do this all wrong, hasn't tried to look at it. All right. And so that's all to do. Next?
Unidentified Male: (Inaudible 00:23:46) Bob hash (Inaudible 00:23:47) function?
Andreas: Bob hash 116? So I'll pass 116 to its one operand, pops it off, calculates the 116 double hash of that operand, right. So that's a specific, right, information here. So what that does is two functions: first, it takes the inputs; and it passes the (Inaudible 00:24:28) to fifty-six and then it passes the statement puts though right in the 116, all right. So the Bob key goes away. Hash 116 goes away. It wouldn't replaces it, if all goes well. It's Bob hash. So if the key that was provided when hashed twice and has to write at the 116 should produce Bob hash. So at this point, you might be thinking, where did Alice get this? Well, Alice got this as she had Bob's public key, right. She had Bob's Bitcoin address. It starts with the one, right. That's just a convenient way of encoding a hash, right, empty encoded key. So if he stripped off the version and then check some of that which you're left with is a twenty byte, 116 (Inaudible 00:25:30) Bob hash. So this is just a different way of writing a public key. It just doesn't have the number one in front and then four-digit checks on the end. It's the stack, it's denuded a hash. So at this point, we got it Bob hash on the stack, what happens next? It goes on the stack, all right. So Bob hash, this is data, data that goes on the stack. So now, it goes. Bob hash, Bob key, fine, so far so good. Bob key will verify, takes two parameters, and produces true if those parameters are equal. So what it will do is it will actually not put anything on the stack. If there's an uptick execution of the script, it would end here and the transaction would be considered failed. If they are equal, these two values get popped. They get compared, if they are equal, nothing goes on the stack. The execution moves on. So this is essentially a conditional stop. Think about it that way. It's F equal L's rates, exception over x into it, right, what are you going to do? So there it goes up. These get popped off and now we're down to object sig. And object sig takes two parameters. It takes the public key and it takes the signature. And it tries to figure out if the signature has been made by the private key in corresponds to this public key, right. Basically, the (Inaudible 00:27:50). So it pops both of these. And if Bob sig was produced by the private key, then Bob key is the public key, too. This is the public key. This is a signature generated by private key if this signature was generated by a private key that is corresponding to this public key. You don't know it. You don't know the private key. All you know is that whether the signature is going to be generated correctly. Then it puts through on the stack. And at that point, the transaction is verified. That previous output has been correctly unincumbered or redeemed by this input. That check is going to be done not just by the first network note or client that sees this transaction coming in. It's going to run this verification, even if it doesn't have a complete blockchain, even if it doesn't know any of the previous transaction. Someone is going to have a transaction output list. It's going to find this transaction output and it's going to do the verification. Only if it is correct, will it relay a tell-tale to the network. Eventually, a miner will get it. The miner will do this same check again only if it is correct will this transaction be included in the block. Then that goes into the block. Once it's in the block and that block is mined, that transaction has been redeemed. And now its value has been transferred to a new output or incumbrance. That's a full life-circle. So who checks this? Who runs that script? Every network knows the relation about such before relaying it, and the miners that mined. Before imputing that transaction to the (Inaudible 00:29:52) block. In fact, before even including in their own verified transaction, you know.
Unidentified Male: Yeah, in the block itself (Inaudible 00:30:04), right?
Andreas: They don't accuse the block, they're mining until they found.
Unidentified Male: It was this miner things the block (Inaudible 00:30:09).
Andreas: Everybody who grabs that block in order to ensure that the block is correct, if they are running a full note client. The running of just the light-note client, what they're going to do is they're going to verify the block signature. The hash of the block is lower than the target difficulty and that it hashes correctly with odds. But they're not going to work (Inaudible 00:30:35) transactions. However, if they are keeping a full index note, then they verify every single transaction in the block (Inaudible0:30:48). There is a protocol definition within the wikis that explains step by step what the note and the miner do in order to verify transactions. What they have to do before relaying, what they have to do before mining, what they have to do to different clients.
Unidentified Male: Can I ask you a question?
Andreas: Yeah.
Unidentified Male: So is there any operand on (Inaudible 00:31:12)?
Andreas: Depends on the operands. Some consume one value, some produce an output, some don't produce an output, some consume two values on the input, some --
Unidentified Male: We needed (Inaudible 00:31:24).
Andreas: No. And that's why you need opt two.
Unidentified Male: Yes.
Unidentified Male: Okay.
Andreas: Because the whole point of opt two is that we couldn't leave Bob key on the stack. It would get consumed by the equal verify. So you have to first duplicate it in order to do the hashing.
Unidentified Male: So any accesses (Inaudible 00:31:44).
Andreas: Yes, yes. But you can't look into the stack or do other things. The stack only has two functions, push and pop, right. So you either push or pop something. And so there are specific stack commands that do things like little thing and popping, things like that. Any other question, sir?
Unidentified Male: I don't think (Inaudible 00:32:07).
Andreas: Yeah. It's implemented as a data structure with language. I have both physical mechanism form of big things up on the white board and moving them down under writing. It's hard to stack every time. This is a very inefficient stack and (Inaudible 00:32:26). To get this, it would just normally just push things down into it. So essentially, it really has a pointer. It will up data to it. It's usually a little less. So that data is (Inaudible 00:32:43) stack of talk (Inaudible 00:32:44). All right. Everybody get that? Everybody's got it. Well, so this is the standard incumbrance for a standard transaction, a more complex transaction would be multi-sig. But first, I want to do a simple one, which is the Coinbase wallet. So when you're doing a Coinbase generation, so if a miner is generate to a new block, transaction zero within that block is the Coinbase generation transaction. It's basically means from nothing to me because I found this (Inaudible 00:33:29, 25) Bitcoin, right. So from nothing part means there is no previous output. The first transaction in a block has no previous output. It simply has a Coinbase number, which is really just a number. And it doesn't have a prior incumbrance. It's an incumbrant. The incumbrant is find the damn truthful work for the entire block. So it's incumbered by 10 hashes of work. But it has a lot of incumbrance. So the ScriptPubKey is actually a lot simple, a lot simpler. And it looks like this as you see, essentially the output, the transaction output of the Coinbase generating entry. In here, it will look like this. Let's say this is a block, the transactions in the block. All right. This is what it looks like, right? So this is the first transactional block. Transaction zero is from Coinbase, from nothing to the miner's key. And this specific incumbrance, before this a Bob key, is miner key object sig. So compare this to this. It's a much simpler form because in the case of Alice paying something to Bob, Alice is going to introduce its script into the blockchain. She is doing this with zero effort. Therefore, we want to make sure what she is introducing is a fully hash-able address. So we first have to make sure that when it's unincumbered by Bob, he produced both the PopKey and the signature. And those are compared against the key and the signature. It's a more elaborate dense. The miners have already put 10 (Inaudible 00:36:46) per hashes of work to put this in the blockchain in the first place. So effectively what you're doing is, you're thrusting them. You have to put up all loaded crack data in here using this all checks here. And it's a less elaborate promises for verify. So that's a ScriptPubKey and then the miner would redeem this by putting it as in using that output. So this is an output, right, transactional output. Let's say the miner wants to spend this coin by sending into Coinbase to get dollars and buy an attributes. So he would then take that, put in the next block and do a transaction input, which takes that (Inaudible 00:37:37) the ScriptSig and then transfers it somewhere else, all right. So the ScriptSig that the miner produced is miner sig. That's it. And so that gets evaluated those follows. So when the network tries to evaluate the next transaction, which is the miner collecting the reward and actually doing something with it, the network is locate simply to put ScriptSig, which is the miner signature, the miner key in object sig. And again, how does this stack-based language work? Left to right, first operand on the list is data. So it gets push up to the stack, which is quickly. So miner sig goes on to the stack, then miner key goes on to the stack.
Unidentified Male: What is (Inaudible 00:39:01)?
Andreas: (Inaudible 00:39:03). Because you don't care about what (Inaudible 00:39:06).
Unidentified Male: (Inaudible 00:39:08)
Andreas: It's a bit more elaborate with that, so I'm simplifying. That's actually a correct process for generating a branded number that you used as a (Inaudible 00:39:18) in a signature which is part of an advance practices for ECDSA. The bulk in android, which happened because a random number wasn't random. And therefore because you're multiplying that by the key, private key, if the numbers in (Inaudible0:39:35) you know what it is, you can then divide the signature by (Inaudible 00:39:38) the key out.
Unidentified Male: Right.
Andreas: So instead there's a process for ECDSA for doing this in a more sophisticated manner, where you take random number, you permeate it, you go through a process of multiple steps to make sure that that doesn't get reflected the signature, right. But it doesn't matter because in ECDSA only you can verify that a key has been signed by an equivalent in the public key without knowing what the underlying finger sign is. Right.
Unidentified Male: I'm getting some (Inaudible 00:40:10).
Andreas: Yes. It must be the difference in our conversations basically. So that's a no, sophistic random number. And there's a more elaborate procedure so it can't be protect otherwise. But if you just took a random number and signed it, that's a great miner sig. So now, we take object sig, it takes two operands. It compares. And, in fact, this signature and this key have produced the output object sig goes away. True transaction regains, all right. It's a multi-sig. It's ready for multi-sig. Yeah. Any question so far?
Unidentified Male: The issuing of that Coinbase is done by Bitcoin Dip, right?
Andreas: It's done by actually most mining software input, yeah, it's done by Bitcoin Dip and you can pass into parameters who all gets put into the Coinbase itself. So in the genesis of work, the Coinbase itself contains an ASCII message. It says the times of (Inaudible 00:41:45) 5 November 2015 chancellor orders bailout to banks. Okay. That's the Coinbase. So basically, use the Coinbase sig data, yeah. Miners often used Coinbase to put various texts, right, like, for example, some mining pools as far as I know use a Coinbase to say how much the previous block, how it got out located or who were or things, the old super version of information in there. During the consensus election for picking which Pay-to-ScriptHash solution to use, Cavin's Pay-to-ScriptHash, which is the BIP16or Luke Junior Pay-to-ScriptHash which was BIP17. They asked the miners to say "If you start putting in your Coinbase, the string P2SH, we're going to do Cavin's. If you put CHV, we'll do Luke's. You have three months. Start mining." And some of them put both, you know, "We'll support both." And then they did a calculation of all the blocks, how many had P2SH, how many had CHV, there you go, you have an election and P2SH won, and BIP17 is (Inaudible 00:43:02). So it's actually use to communicate information back from the miners. But it's not using any rules, the blockchain protocol. It's just basically data.
Unidentified Male: Good afternoon. I have a question (Inaudible 00:43:20) like that.
Andreas: Less than?
Unidentified Male: Like three Bitcoins. And then (Inaudible 00:43:24)
Andreas: Yeah. That's a good question. I don't think we did figure out the answer. As far as I remember, we discussed it and someone said that there are transactions with less than the reward that they are processed correctly. So the validation protocol for validating the block is, is the reward less than or equal to, not is the reward equal?
Unidentified Male: But less reward.
Andreas: Sure. So you can't put less. All right. So everybody clear? Any questions? Let's see one multi-sig. All right. I'm going to put a couple of more object-sig examples. So this is a transaction output that has no incumbrance. So if ask your ScriptPubKey, you put empty, you put nothing anyone can redeem that. And in order to redeem that, they had to produce a script-sig that contains the truth of what OP-TRUE does is it puts two on the stack, as simple as that, right. It makes sense? And so if you put these two together which again is the stack that says OP-TRUE and then nothing and that puts two on the stack, lots of valid transaction. That's basically a no incumbrance. It means anyone could spend the sig-block, this output. It's all incumbrance. Why can we do that? Donations, when we're doing it, really no practical use for that. Here is a different one, this is another standard transaction, by the way. At the moment you can't actually run this on the networking (Inaudible 00:46:13).
Unidentified Male: And if I'm using run on tested?
Andreas: If it runs on tested, it runs on magnet.
Unidentified Male: Okay.
Andreas: That's the point of test that is to make sure that it runs on magnets. So they should be entirely (Inaudible 00:46:30) in terms of strict verifications. It's the same software in case of blockchain. It should be (Inaudible 00:46:34). All right. So this is an incumbrance that requests an answer. Which answer? The one that when you hashed it with opt Hash-256 produces this hash, which then goes through opt equal. And if the hash and -- so the way you would evaluate this again of our stack would be calculated 42 opt Hash-256 along hexadecimal number. Yeah. It starts here. It goes on the stack. It will be Hash-256 creates. It's a 256 hash. It's a SHA-256 of this. And puts it back on the stack. Then odd number gets put on the stack, too. And then are they equal? Sure. Right. So what this is, is basically what it says is, this output is incumbered by anyone who can find a fact to un-hash with SHA-256 produces this digital signature. What is it? Nobody knows. You can't tell. You can't reverse it, right. Is that the end? In this case, the answer, life, the universe stuff, 42. But it could be something else. Essentially, what this is, is a puzzle, right? So you're saying this is a puzzle. Whoever finds the magic treasure can redeem the solution. It's possible. Another way you can use this is to do a lottery. So, for example, you can have a lottery that takes a specific, the way you essentially roll the dice, you draw off lottery before you run it. Then you puts the result on the blockchain and says whoever finds the tickets, whose hash is this, which is why we just drew as a lottery. But you don't know what that ticket is, wins the pot. Now everybody send money in, right, and choose your ticket numbers. And whoever finds the right ticket number can then go back. Then you can announce it, and say "That was a ticket number." Everybody can go back in the blockchain and confirm to that, that hash was there and the person who used it did in fact redeem it. Make sense?
Unidentified Male: (Inaudible 00:49:47 Did Satoshi do that?
Andreas: Satoshi didn't, yeah, no. It does not do something like that. It used another trick to put information into the blockchain like that. Did you say drawing the number before so that you can verify that was the correct number or something like that? I'm not exactly sure. That would be a great study, the transactions that going to Satoshi (Inaudible 00:50:11) what does transaction is and how that works. All right. Got few more for you. This is the incumbrance. A type at the front right. So that's the traditional multi-sig transaction. It's the number of keys required, the number of keys provided and the three keys. Now where does this go? It goes to the output. It's an incumbrance, right. And then what you produce in response to redeem this? It's a ScriptSig. And I'm going to find that just -- so I believe the solution to this is Q1. Q3 into something (Inaudible 00:54:09). So we provide two keys of (Inaudible 00:54:17) searching. Sorry. Key 1 sig, key 3 sig, it could be two and three of one-three, or one-two. It doesn't matter. Any two out of the three. So it actually provides two signatures in order to un-incumbrant this output. On the way, it's process then as you put this followed by that on the stack and check multi-sig verify actually takes one, two, three, four, five, six operands off the stack and pops in it through if two out of the three (Inaudible 00:55:00) that incumbrance. Okay. Anybody tried this (Inaudible 00:55:05)?
Unidentified Male: I'm trying to do that.
Andreas: Good. How did it work? It did not?
Unidentified Male: I actually have the (Inaudible 00:55:14).
Unidentified Male: All right. As we know, outside of it.
Andreas: Okay, sweet. So the whole purpose of doing that hack fall in some five-hour cool bash on the every second Sunday after we do this. It's then try and figure out exactly how it's works, all right. Would it make sense? And figuring it out what we got it wrong at the first time. We'll come back and do it again. So if you think this is an infallible information, see to the beginning of the video where I said it's all wrong.
Unidentified Male: (Inaudible 00:55:43). It's expecting a hash decimal (Inaudible 00:55:48).
Andreas: Of this?
Unidentified Male: Yeah, you put that fraction to (Inaudible 00:55:56).
Andreas: Yes.
Unidentified Male: (Inaudible 00:55:57).
Andreas: Right. Oh, okay. So you serialized this first.
Unidentified Male: Yeah. That's right. I mean, that's correct. You got my (Inaudible 00:56:05).
Andreas: So let talk about Pay-to-ScriptHash --
Unidentified Male: Yeah.
Andreas: -- which is the next topic. And I'm going to wrap up with that in about 10 minutes. So we talked about before the fact that the transaction output contains the actual script. which is the incumbrance, right, and a transaction input contains the key that unlocks that incumbrance. And what that does is it puts the burden on the sender to create the incumbrance which usually has more data and to pay the fee to have that put into the blockchain. So one of the motivations behind Pay-to-ScriptHash is to flip that burden. So instead, what you put in the incumbrance is simply a signature of the script. And the person redeeming provides the key and the script in their input and they pay the fee for it because it's their transaction. So the recipient who gets the value of the transaction pays a fee to incorporate all of that data into the block. So Pay-to-ScriptHash is basically a magic Bitcoin address. That's not an address, instead it's a script. And so the way it works is like this, a traditional Bitcoin address. Let's say that's a Bitcoin address, right. This is actually three parts of this address. First one is prefix, right. Second part is a 20-byte address. And then the third part is a four-byte section. So Bitcoin address contains within it a 20-byte hash. The Bitcoin network hub, which is zero will be possible at the beginning of (Inaudible 00:59:27) and hash it through this algorithm and pops out through wallet.
Unidentified Male: (Inaudible 00:59:34). If I'm going to sign this transaction, (Inaudible 00:59:38) how do I know what sig can have transaction?
Andreas: We'll get to that.
Unidentified Male: Right.
Andreas: So this is not yet Pay-to-ScriptHash. This is a standard Bitcoin address. And a standard Bitcoin address what you're looking at really is a Base58Check encoding as it's called, right? Definitely, this Base58, this is a Base58check. Let's put this to block. What that means is Base58 means we're using 58 characters to encode this number, this primary number. Now so instead of hexadecimal, decimal, octal, this is 58 decimal, Base58. Why 58? Because they have taken out opt zero one lower key cell, upper key cell because those are often confused for each other individually. So by removing those, it's harder to mistype this when you're typing it in by thinking that an O, which is zero, or an (Inaudible 01:00:44) of one or visa-versa. You take out wholly, ambiguous characters, left fifty-eight characters, upper case, lower case numbers. Yeah, 26 plus 26 plus 10 minus the ambiguous ones 58. And the 58 characters, when you're encoding theory is a hash. Remember in the transaction that Alice created she doesn't put the key of Bob's. She puts Bob's hash in the incumbrance. It was the hash involved. Where does she find that? It's right in the address. The address is just the hash with the checks on and the number that tells you which network this is on. Main network, test network, etcetera, right? The address is on the test network, have a different up code in the beginning. And so they start with the lower case M, addresses in light point have a different opt code in the beginning. So they start with an L. If its terror point starts with T, if it's (Inaudible 01:01:51). But if its main point has starts with an M. So in any case, by controlling this upcode, you generate the address with different prefixes. The Prefix 1 is the main Bitcoin network, right? That includes a 25-hash of the public key. That's your SHA-256 flowed by RIPEMD-160. Then it has a 4-byte checks. And the checks from insurers, that if you mistype this thing, there wouldn't be a (Inaudible 01:02:25). So Bitcoin address contains checks. All right. So far so good? So what this is it's simply a public key wrap in some fancy stuff to make it more robust for the software that's handling these things. Now really the thing you care about is 25-hash, right. That's saying incumberant is to this output. So Pay-to-ScriptHash, P2SH, instead of a Bitcoin address it's something that looks like a Bitcoin address. So you can use it in a wallet transaction in the same way, incumberant towards this address. But instead, what it is, is opt code three. The hash of ScriptPubKey (Inaudible 01:03:36). So, for example, you could take opt two, opt hash 116, Bob hash, Bob check sig, Bob verified. All people verify object sig. You could take the standard to pay Bob, right. Hash that entire thing, stick it into there and you could create some new address, which is actually a Pay-to-ScriptHash address, which has the same (Inaudible 01:04:07). Am I making sense?
Unidentified Male: But (Inaudible 01:04:13) blockchain it says (Inaudible 01:04:15) transaction.
Andreas: Yes. No, I don't know.
Unidentified Male: Is this (Inaudible 01:04:19)?
Andreas: That doesn't matter (Inaudible 01:04:25) what it is. So essentially what we're talking about here is that instead of saying pay this public key, you're saying pay whoever can produce a full script and the necessary ScriptSig, and the script has this hash to this. You don't put the script in the output. Say the script fully provided later and this is his favorite place. So whoever writes both the script and the key that unlocks it and you push the script from being in your output to being in the redeemer's input because they now have to provide ScriptSig. The entire script and that redeems it. Yes.
Unidentified Male: So this (Inaudible 01:05:05).
Andreas: So this gets evaluated very differently. So let's see how this gets evaluated. This is somewhat more complicated. So let's takes the same one. We're going to do pop up, opt Hash-116. Opt hash. I'm good. Beautiful (Inaudible 01:06:09). All right. So this is a standard incumbrance, right. This is standard ScriptPubKey that's use the same pay (Inaudible 01:06:20). Everybody got that? Look up that board. So instead of putting this in the transaction, what you do is you put this through our hash and you produce a signature for it. You're saying this is a script that I want to redeem. This is the incumbrance that we want to put up. Instead of putting this in the transaction output, you do it all Hash-116, all right. Yep. You then take this and you add to the front of it. The output is three and then the checks up and you create a Bitcoin address. Only this isn't an address that corresponds to the public key. This is an address that corresponds to a full script. And in your wallet, you can simply say "Hey, this code three A, B, C, D, blah, blah, blah. I'm sending one Bitcoin to three A, B, C, D, E, F, G." The network doesn't know what behind it. You haven't yet produced the script, the script is hidden. You've only shown a fingerprint on it. To redeem this transaction, the redeemer needs to produce this. Based on our previous discussion, Bob would produce Bob sig, Bob key, Bob 2. So Bob now might produce a signature, a key, the actual script where this corresponds to. And in order to redeem this, the verification is going to evaluate that script, figure out when it hashes. Is it hash this, if it is this is the script that it was incumbrant against. Now it's going to put it back from the stack and it's going to evaluate it's using the same rule as before. So all you've done is essentially instead of providing the full ScriptHub front, you say, "Here is a fingerprint." When this is redeemed, the script will be given to you then. You first check that it matches the fingerprint. If it does, then you evaluate the script as if it was the transaction incumbrance, right. So the recipient who is redeeming this provides the ScriptSig and the script. Not just the ScriptSig, not just the key, but the incumbrance, too. And then the network checks that incumbrance, in fact, the one that had the signature put into the output, right. So you're not paying to an address, you're paying to a hash of a script, scripts to be provided later by whoever wants to redeem it. Make sense? So in a multi-sig case, again what would that be? The way to create a multi-sig that appears as a P2SH transaction is to key one, key two, key three, take that, put it in, you create an address, all right, and then (Inaudible 01:11:52) into transaction as Bob Hash-116 to the script address of (Inaudible 01:12:05), all right. So you've taken a multi-sig transaction, you've produced fingerprint. You start that fingerprint between a low hash and not equal. And what that says is I'm going to get something here, a script. I'm going to hash that script. When I hash that script, I'm then going to compare that hash to this hash. And if they are equal, then you got the script to use. So it's on the stack. Again to visualize this, the stack, all right. You want the ScriptSig to solve this. The ScriptSig that solves this. The ScriptSig that solves this says ScriptSig, all right, and what is that? Key one sig, key three sig, let's say that one and three signed. So you provide the two signatures. Then what do you have to provide? The entire script, which isn't in the blockchain, this one. So two K1, K2, K3, three opts (Inaudible 01:13:50). Then in the verification, the incumbrance is added to the end of this Bob Hash-116, that hash is longer to make (Inaudible 01:14:14). Three A,B,C,D, one, two, three, this is the entire thing that gets validated. So ScriptSig, script, ScriptPubKey (Inaudible 01:14:53) ScriptHubKey. So what the network is doing in this verification is it's taking the thing that was in the blockchain because the ScriptPubKey is the input to the blockchain, the incumbrance. Bob Hash-116, the hash of the ScriptPubKey. The script that you just provided is part of the ScriptSig, plus the signature that you just provided in order to redeem that up. And it runs it all in one continuous stack. And if you un-label this, all it does is it said "Hash this profit with both key hash." Compare it to this, it's equal, then you run it. But the way you run it is the same way you run the transactions, which is put this together. Yeah.
Unidentified Male: So that it will be acquainted to (Inaudible 01:15:47).
Andreas: One (Inaudible 01:15:49) does in returns all of this back into the stack that we've verified.
Unidentified Male: Is that equal?
Andreas: It's actually a reclusive verification. So you first verify that the script itself hashes to the correct value. What I mean by that is the first verification that happened is this one. And what that does is it hashes this check that it's equal and then if it's correct then it take second verification which is (Inaudible 01:16:26) and runs it through this stack again.
Unidentified Male: (Inaudible 01:16:29)
Andreas: It's not normal execution, it's two executions. Okay this is confusing, right?
Unidentified Male: So (Inaudible 01:16:41) progress of the (Inaudible 01:16:43).
Andreas: The end pull is two pulls. The first pull is in order to be able to provide vary complex scripts that enable clients that already understands addresses to have a very simple way to say pay this script or rather than putting the entire complex script end with the clients. What you do is simply put in the (Inaudible 01:17:09). So I'm going to give you an example. You're trying to buy a car using escrow. Instead of you trying, or your clients needed to be escrow aware, when you go to the car service, it says in order to pay this securely instead of paying in buck, pay this 3 address, it's a script, which include the escrow key in it. It's a multi-sig escrow key. So you just say I'm your client, snap the QR and you say send 1000 Bitcoin, that's a lot of car. You sent 15 Bitcoins for the new Tesla's and 15 Bitcoins to this 3 address. You don't know what's in it. But it was given to you by the escrow service, right. Now when that goes into the blockchain, it can only be redeem if some produces the script it was behind that 3 address. And so that would be the escrow plus your signature that you got the car, right.
Unidentified Male: Right. So this is (Inaudible 01:18:08)
Andreas: P2SH is simply a way of hiding a script inside an address.
Unidentified Male: So yes or no?
Andreas: Yes, it's using (Inaudible 01:18:20), yes. It's used any word scripts that we used. It's just a different way of expressing the script, instead of putting the script as the incumbrance in the output and bargaining that on the sender of the transaction, both in terms of their clients, knowing how to create such a script. And in terms of the fees, they have to pay to put that in the blockchain. Even though it hasn't been redeem yet. You shift that balance. You just put the signature. The client already knows how to do it because it just looks like an address. And all of the burden that goes to the recipients of the value who has provide the bigger block there, which goes as an input in the transaction, not an output, right. And only on the point of redemption whenever that happens. So stuff doesn't stay in the blockchain, it doesn't go into the UTXO, the unspent transaction output memory pool which is a very risk force constrain thing because you have all of the unspent transactions from the entire blockchain in there. It consumes a lot of memory. This isn't an output. The output is just the signature. This is all an input and we don't keep input around. We just file back the ones. So now it's not polluting the UTXO set at all. The client doesn't need to know the complexity of the script and it's only used that redemption. And then immediately once it's back to the block, everyone forgets about it. So that means that these scripts spent far less time floating around in the system. If you did a big multi-sig script and you put it as an output, every client in the world has to keep in memory. Just in case someone spent it. And all of that data and the sender paid for it, and it's there until when every it's redeemed. So if it's a trust fund that comes through when that person become 18, it's going to sit in the blockchain for 17 and a half years, right, whereas if you shift that burden to the inputs, the Script itself, which is a long part will only appear once on that person's 18th birthday. It will not be showed ever, it will just go straight to two blockchain, it wouldn't go into the UTXO, it wouldn't be (Inaudible 01:20:23). So this is all I wait to simplify the implementation of script because all clients can do an address. And only the miners need to understand how to validate if that transaction is a real script. So it limits the number of code, demand code that needs to be change. And it shifts (Inaudible 01:20:43) when the data goes in and it pays through (Inaudible 01:20:47). So if you read BIP16, the first chapter is (Inaudible 01:20:54) why on we did this. Make sense?
Unidentified Male: Yes.
Unidentified Male: All right. P2SH is (Inaudible 01:20:59).
Andreas: P2SH fully supported us in 1st January 2012 and was implemented by the miners who relates recently. I think November, October-November, you started seeing 3 addresses. I think I'm not sure entirely (Inaudible 01:21:17). Yes.
Unidentified Male: When you're doing a two of three, I guess, this will happen to run more than once because we have (Inaudible 01:21:28) essentially as in their script just to verify the two of three signatures.
Andreas: No. You have to produce both of the signatures upon redemption in this output.
Unidentified Male: Separate?
Andreas: Yeah. It's loading two separate transactions. Is it?
Unidentified Male: Yeah. And it can be, yes.
Andreas: It can be in two separate transactions?
Unidentified Male: Right.
Andreas: How does that run?
Unidentified Male: I don't know how it functions but (Inaudible 01:21:53) both side.
Unidentified Male: No.
Unidentified Male: Yeah. They did the two different transactions?
Andreas: They do the two signatures of two different transactions?
Unidentified Male: In both the sides.
Unidentified Male: Right. Two --
Andreas: So in a check multi-sig --
Unidentified Male: Yeah.
Andreas: -- here we're un-incumbering descriptive contains both of the transactions need to unlock it.
Unidentified Male: Yeah.
Andreas: We actually produces in two different inputs and two different ScriptSigs.
Unidentified Male: This video is specifically for the audience, to put your audience (Inaudible 01:22:22) functions.
Unidentified Male: So I asked like, (Inaudible 01:22:25) transaction to send out of the multi-sig address, what he does is you provide -- he hasn't (Inaudible 01:22:33). He holds an encrypted copy of the address, you have to one time decrypt just to send money often. And then he holds this for, sort of, backup in case he doesn't (Inaudible 01:22:49). Does that make sense?
Andreas: So you have two out of three already?
Unidentified Male: Yeah. (Inaudible 01:22:59)
Andreas: The purpose is not as per its back up?
Unidentified Male: Right.
Unidentified Male: Yes.
Andreas: So that if he disappears --
Unidentified Male: Yes.
Andreas: -- so it takes either your two or yours and his --
Unidentified Male: Yes.
Andreas: -- in order to ford it up. But he's not encoded in a single transaction?
Unidentified Male: (Inaudible 01:23:14)
Andreas: It's unlocked this single transaction. I don't know that you can't produces in two different transactions.
Unidentified Male: Yeah.
Unidentified Male: (Inaudible 01:23:19)
Unidentified Male: Yes.
Unidentified Male: So if you need to handle like two things, you can sign in a separate paper, but you have two different signings. But then two different people sign it (Inaudible 01:23:29), right?
Andreas: It has to be both cases. One, transaction, how you do the (Inaudible 01:23:36). Jeremice (ph), do you use multi-sig in local Bitcoins?
Unidentified Male: Not yet.
Andreas: Not yet. Don't bases on this. This is probably wrong. This is kind of the high level the implementation details are a bit more complicated. All right. That's it. That's a transaction scripting in multi-sig. Thank you.
(END OF AUDIO)