This is Brett with Summit Auto. We are here at the 2019 Chicago Auto Show and just happen to see this Lincoln aviators sitting here. We're doing videos on just about everything we can at the auto show today. This is a 21-inch rim painted in polished aluminum has Pirelli Scorpion 0271 or 275 45R 21s And just wanted to do a quick walk around on this vehicle. Unfortunately, it is locked So other than looking in the windows, we really can't get inside it and play around a little bit It does look like it has the third row seating in there Quad seating there as well. This is a black label, which is Lincoln's top of the line vehicle Really good-looking vehicle four-wheel disc brakes, of course As the panoramic Sunroof Can't see inside there, but we can see As the cool bolstered seats there the Lincoln emblems So very cool vehicle just want to do a quick walk around I know a lot of people are interested in this Ride and it coming out soon So remember to like subscribe and share on this video and all the videos that you see on our YouTube channel We'll be at the Chicago Auto Show the rest of the day doing more videos and from yesterday We did about 20 videos so lots of stuff going up check our YouTube channel Which is youtube.com slash summit auto and remember to like subscribe and share thanks again for checking out my videos


Welcome. So today we're talking about inodes. Also, we'll leave a bit of time because there's TA evaluations the department wants. So we'll leave a bit of time for that as well at the end. So let's get talking about inodes, which we left off talking about, you know, indexed allocation and how that could be pretty good. But our file sizes we could support are only something like 16 megabytes, which isn't that great. So what an inode would do and this is the predominant data structure in the kernel when it comes to file systems. That's where all the information about the contents of a file actually lives. So that's where the mode is stored for a file and the mode is all the permissions. And then there's space for the owners, which is a user ID for the user that that belongs to and then the group that that belongs to. And then there's some timestamps to keep track of when a file is created, accessed and modified last, which you could of course change it will. Then there is a field for the number of blocks that this file occupies.   There is some pointers that point directly to blocks, in which case you should use them directly. And that's as an optimization for smaller files. So if a file only takes up a few blocks, well, it doesn't need to use a block for all the indexes. It can just point directly to the blocks that it occupies. And then there is a field for single indirect, which was an idea for index allocation before. So that's to represent, you know, big er files in the smaller ones, but still not that big. So single indirect block points to a disk on the block or a block on the disk. And then that block contains all of the index nodes. So it just contains a bunch of pointers. And then similar to how we have multi-level page tables, well, the same idea applies to files. So there is one pointer that should be treated as a double indirect block.  And then finally, to support even bigger massive files, there are triple indirect blocks, which is like a three-level page table. So it points to a block, which points to a block, which points to a block, and then all those have the index bits that actually point to the actual blocks on the disk. So any questions about that? It's the same idea as page files except now, instead of just having, you know, on our page system, we just had three levels and that was it. Here we have a, we have a varying number of levels, depending on how big the file is. So if it's little files, we don't have to worry about that. Then for slightly bigger files, it just points to a single block, which is full pointers, and then we have the double and then triple indirect ones for larger files. So the goal of this is to be efficient for small files and also support large ones. So the inodes will hold all the metadata and pointers to blocks, and we'll see how this comes into play when we look at files.  So there's also a small optimization here where if it's a very small file, it can actually hold its contents directly on the inode itself. So here there's like a number of direct blocks, single direct, double indirect, and triple indirect. Typically you will have 12 direct blocks and then one single indirect, one double indirect, and one triple indirect. So you'll have 15 pointers. And if they're each four bytes, then you have 60 bytes of information. So one of the optimizations is if your file contents are less than 60 bytes, I don't need to point to any blocks, I can just use that information and store the contents of the file directly on the inode itself without having to waste any more blocks. So given that, now we can figure out how big of a file we could support. So this is the scenario I was talking about before for an inode. So it could store 12 indirect blocks, one single indirect, one double, and then one triple. So given that, and then each block is eight kilobytes in size, a pointer to a block is four bytes, and indirect blocks only consist of pointers only. So it's however many pointers you can fit on a block. So now we can answer the question, well, under this scheme, what's the maximum size of a file indexed by that can be represented by this inode? Well, it's the same thing as last time. We still have the same number of pointers that we can fit inside of a block. So that is two to the 13 divided by two to the two. So we can fit two to the 11 pointers on a block. Then if we want to calculate the total number of addressable blocks, well, in this case, we have 12 blocks that can be directly addressed just from the inode itself because those are the direct ones. And then for a single indirect block, it would point to a table and that single table could hold two to the 11 because that's the number of pointers. And then if we had a double indirect block, we have to take two to the 11 to the power of two because each entry points to another table. So it'd be two to the 11 to the power of two. And then for triple indirect blocks, it would be two to the 11 to the power of three. So instead of adding all these numbers together and having a not nice power of two, we can just estimate it to be the largest one since I'll probably dominate the size of all of them. So to the 11 to the power of three is going to be two to the 33. So the total number of bytes that we could hold in a file would be two to the 33 blocks times how big a block is. So a block is to the 13, which would mean the maximum file size we could have is two to the 64, which would be 64 terabytes for a single file. So that's more like a file system we would have nowadays and this is the actual structure the kernel uses. So your maximum file size, there is a maximum and it's 64 terabytes for a single file. It'd be slightly over this because we didn't estimate estimate. So you could have this many more blocks, but you know ballpark, it's about 64 terabytes. So there is a so how files get represented are the entries in your directory are not the actual files themselves. Every entry in a directory is just a pointer to an inode. So it just records the inode that represents whatever file that is. So your todo.txt, if you have it somewhere on your drive, it looks like it's in a folder. Well, if you know the structure of the file system and how Linux works, todo.txt is actually going to reference an inode, which will be some particular number. So in this case, assume todo.txt points to inode one, that would contain all of the contents of the file. So that would contain the metadata, what blocks it points to all permissions and things like that. And within a directory, all it would record is the name and what I know it points to. So the directory, they don't a directory doesn't have that much in it. All it is is pairs of name to inode and that's it. So hard link points to one inode and typically this is the case if you have a file that you just create there, it points to one inode and nothing else points to that inode. But what you can do is create something called a hard link. So multiple hard links can point to the same inode if you know what to do. So todo.txt and b.txt can point to the same inode and when you remove that file, it only removes the hard link and that doesn't mean that content of the file is actually deleted because something else could be pointing to that pointing to that inode. So POSIX only has an unlink call and that's what unlink does. All unlink does is remove this and like if you did RM, b.txt while there's no actual remove system call, what's going to happen is they're going to be unlink and unlink would just remove b.txt. So now b.txt is no longer pointing at inode one but since todo.txt is pointing at inode one, well it's not going to actually be deleted. So then there's something called a soft link. So a soft link, all that does is point to the name of another file. It doesn't point to an inode, it just points to a name. So when resolving whatever file that is, the file system is redirected somewhere else and it reads that content. So if I have create b.txt as a soft link, instead of pointing to an inode, it just points to a name. So it could point to something like todo.txt and if you want to read the contents of b.txt, well you have to know from b.txt you have to follow it to todo.txt and then you can get the inode and then actually figure out the contents of the file. So we can see when we play with this too that sometimes soft links, the targets can be deleted so we could delete todo.txt and then you can't resolve the target of a soft link, although it still exists and that would be a condition you have to cover in your programs that hey, the files I accessed might actually be soft links and they might not actually point to somewhere. So we're soft links? Yeah, soft links are essentially like shortcuts in Windows. So they just point to a name, point to a path. So in Windows if you have a shortcut and then you delete whatever that's a shortcut to, then your shortcut doesn't work anymore. So same idea as here, it's just the unixy way of doing something. So let's take this example so we can play around with this and see what would happen. So in this say we have, we touch todo.txt and all touch does if you haven't seen it before is it just creates a new empty file. So if we look at our directory, we just have one file in it called todo.txt and now we can actually expand our skills a little bit. So we know ls-l to show kind of more columns. So over on the left here, there are all the permission bits and then here is a number of links which we didn't know before and then that is the user that owns the file, the group that owns the file and then the date modified and all that stuff. So if we add in a i, well we get a new column here and that new column all the way to the left is the actual inode number that todo.txt points to. So what we can do is create a hard link. So has anyone used ln before like dash s? No? Okay, so ln-s is how you make a soft link but we'll see that in a bit. If you just use ln that creates a hard link. So if I do ln, the first argument is a hard link to what? So this is a hard link to whatever todo.txt, whatever inode todo.txt is and I'm going to call the new entry into the directory b.txt. So if I create this, whoops I hit a bad key, if I create this then I have a file called b.txt and now if I look at it through this I can see that the number on the left column is the same so they have the same inode. So if I go ahead and edit todo.txt and say hello, so I save it, now if I cat it what should I see? Hello hopefully. So I can cat it and say hello and but now what would happen if I cat it b.txt? What should I see? Any guesses? Hello? Oops. Yeah, so if I cat b.txt I see hello because they're actually pointing to the same inode and the inode points to the contents of the file. So I can access the same inode through todo.txt or b.txt. It doesn't matter which, right? I could edit b.txt, edit in from b. So if I go ahead and edit b.txt and then just look at todo.txt, well I can see that it's actually the same contents of a file because it's the same inode so I can edit it directly. So the other thing we could do is create a soft link so it's the same, works the same way as creating a hard link except you just use dash s and that means it's a soft link. So I'll create a soft link to the name todo.txt and I'll call this c.txt. So if I go ahead and look at the directory again, well I'll see that there's this new entry called c.txt. I should move myself out of the way. So I see this new entry called c.txt and c.txt, whoops, here I can increase it. So c.txt you can see it just points directly to todo.txt but all the way on the left here it's actually a new inode. But because it's pointing to todo.txt if I cat c.txt well it will just magically go ahead and resolve that. So it knows that c.txt is a sim link so it would go ahead and access todo.txt instead and then get the inode from todo.txt which would then lead us directly to the contents of a file so we can display it. So the other thing we can do is we could, now if we move todo.txt to something like d.txt well all that does is change the name of todo.txt, it doesn't change anything else. So if I do an ls again I can see the d.txt well it was todo.txt move just simply renamed it, it didn't actually move anything unlike its name. So its inode is exactly the same as it was before I just changed its name. And now we can see in red that I broke the soft link. So the soft link isn't guaranteed to exist or point to anywhere that you care about it's just a name. So c.txt just has an entry that says hey I point to todo.txt and now I don't have anything named todo.txt anymore.  So and then finally we can go ahead and you know remove b.txt which of course removing b.txt doesn't change just removes that entry that points to that inode but I still have something else that points to that inode that d.txt so my original contents that I edited before are all still there even though I moved around to do.txt and changed up and deleted one thing which didn't actually delete anything it just removes entries in the directory. So any questions about that fun stuff? Cool so if you were to write out what the file system looks like before and after the remove commands well it would look something like this so before the move we created todo.txt which would have created its own inode and then we created a hard link where b.txt points to the same thing as todo.txt so they would both point to the same inode and then c.txt is a soft link to todo.txt so hard links point to inodes soft links point to other names so before the move this is what my file system looks like and then after the move all I'm doing is renaming todo.txt as d.txt so it's pointing to the same inode I just changed its name but now c.txt is pointing to a name that no longer exists anymore so you could put it in black to say that hey it doesn't exist anymore and then if I remove b.txt all that happens is I just remove that name in a directory so the name b.txt no longer points to that inode so in Unix everything is a file so directories are just files of type directory there's additional things so files can be a regular file which is what you're used to a block device so you which means you can only access it in big blocks so that's represents like a hard drive or an ssd something like that we've seen pipes and we've seen sockets before so just so we know directory inodes do not store pointers to data blocks all it stores are file names and pointers to inodes so it's just a bunch of tuples that are just file name inode what are all what are they all so looking at that too let's go back to our example here let's recreate that hardlink so I'll create a hardlink to d.txt called b.txt again so if I do that two things point to the same inode and then if you want to read the contents of an inode well there's a stat system call and also a stat command you can run so the stat command will tell you a bunch of information about what you just accessed and then what is specifically on the inode so this is the file to do.txt or b.txt which that's gotten from the directory and then the rest of the information is the inode itself so it is 22 bytes large it occupies eight blocks my io blocks are four kilobytes it's on some device so and then it's inode number and then we can it actually keeps track of the number of links there are to it so right now there's two links there's b.txt and d.txt so it keeps track of that information on the inode itself so the kernel actually knows when it can delete the inode so the kernel can only delete the inode if there are zero things pointing to it as long as there's one thing pointing to it it can't actually delete it and when you are on it you don't actually know if it's deleted unless you know ahead of time you check that there is only one link to it before you deleted it so then you can see the access the user id the group id and then all the access modify change timestamps and there's also a birth timestamp as when i created it so if i go ahead and say i remove d.txt and i stat b.txt again well now i can see that my number of links decreased from two to one so i'm one step closer to being able to actually delete it if i'm the kernel so any questions about that so after that we should have a good understanding of what's kind of stored on the inode itself so the file name is not stored on the inode itself that is only inside the directory because the directory keeps track of names to inodes and inode itself has no idea what its name is it doesn't really care so also to that it doesn't know where it is contained because it could be contained in multiple places at once it would know the file size it would know the file type and inode would also not know the number of soft links to a file because you'd have to follow a bunch of links from the directory and it just doesn't care so consequently it would not know the location of the soft links it would know the number of hard links to the file so we saw that in stat so it knows how many hard links are to it and the kernel has to maintain that number to make sure it is correct but it's not going to know the location of the hard links so knowing the inode you have no idea of what is actually pointing to you without actually traversing the whole file system so there's no way to go backwards from inode to a bunch of names but other things it would have on it that we saw is it has the access rights or permissions it has the time stamps it doesn't store the file contents it points to blocks of the file although sometimes if it is optimized it can sometimes have the file contents if it is actually small enough and then lastly it would definitely have an order list of data blocks because that is the whole reason we have this inode structure in the first place so here's the answers to all of that so again c is because the file contents if they're small enough will sometimes fit on the inode itself so I can go ahead and verify that and show you so usually the number of blocks that are associated with the file it will tell you if you stat it so let's see in here in here I see a c.txt which points to to do.txt but I can stat c.txt and see the actual contents of the inode itself because it's its own inode so if I look at that I can see it knows it's a symbolic link here but curiously it is pointing at zero blocks so it's not actually consuming any space on my hard drive so and the size of the file is only eight because it's not because it just holds the content of what it points to so its size is eight because to do.txt is exactly eight bytes long so all it holds so that shows that it only holds the contents of sorry it only holds the name of what it points to and that is the only thing it contains so what the optimization here is because size is eight well usually usually in the inode itself well these are all four byte pointers and then we're going to have something like 12 direct one indirect one double indirect and then one triple indirect so if we add all that this means we have 15 pointers which would also equal to 60 bytes since each pointer is four bytes so the optimization is if this size if the size of the file is 60 bytes or less it's not going to store anything it's not going to store any pointers because it can actually fit in this 60 byte so I reuse the space that I would have for pointers and I actually put the contents of the file there so in this case if the symbolic link well the only thing it contains is the name to do.txt so the first byte would be the character t then o then d t o dot t x t so I would reuse the space for the pointers and just put in the string that the sim link points to and that is the whole thing so that's a good optimization otherwise the file would have to take up at least one block and if my file is only eight bytes long and my block is eight kilobytes I'm essentially wasting eight kilobytes every time I make a sim link and usually your sim links the names you're going to refer to are going to be less than 60 bytes so this is a worthwhile optimization so any questions about that okay so that's pretty much it for my notes so the file system will again like we talked about before use a cache to speed up writing to disk so we know that writing to a disk is slow and like always we'll use a cache to speed it up so what you can do is cache file blocks and cache them in main memory and that would be something called a file system cache and then you would create the cache because well you know that if you reference a block it's likely to be referenced again if that file represents something like a database or something like that you'd constantly be revising entries and modifying them so that would also be an example like we saw before of temporal locality and then logically blocks are near it are likely to be referenced next so things could be spatially located so if I read a file sequentially well I know that I'll be reading the next contents of a file so one optimization you could do if you are the kernel is go ahead and preload that information into your cache so it's there just in case something uses it and then you could also use that file system cache to record writes to so you could record all the writes to memory and not write them out to disk until as late as possible and that is why there are special system calls to actually trigger writes so there is a flush and a sync system call and that actually triggers that file system cache to actually be flushed to disk so you know for sure that you're actually going to have that information written to the disk so if you lose power or something like that then you actually don't lose data so one of the last things about file systems are something called journaling file systems which are file systems that try and ensure some integrity so now we know all the steps you have to do if you want to delete a file on unix so deleting a file assuming that's the last thing last reference the inode involves three steps so I remove its entry from the directory and then I would decrease the count the number of counts to that inode and if it's zero then I would release that inode to the pool of free inodes and then as the third step I would whatever blocks that inode was pointing to I have to set those all to free now because other files could now use that because I'm not no longer using it so I should return it to the pool of free disk blocks so if you actually care about data integrity well a crash could occur between any of these steps so say we crash between step one and two well that inode would still look like it is in use and all the blocks it would point to are still occupied that inode also is still occupied even though nothing actually refers it anymore so we would lose some information there that we'd never be able to get back and similarly if it crashed between steps two and three well that inode would would be released so it could get reused but now all the blocks it points to are going to still appear to the kernel as being occupied even though that they're free and since we can reuse the inode now whenever you power the machine back on well all those blocks are going to be lost till the end of time so that would give you a storage leak and what a journal does it basically just contains all the operations in progress so if a crash occurs you can recover so the journal would write an entry before it starts those three steps that says hey i'm going to remove this entry in the directory and be like okay i'm starting it now and then go through the steps and only after it's done it would remove it from the journal so if it crashes it would still be in the journal and then you can retrace your steps and then knowing how you do the steps you can see at what step something broke down so that's the point of a journal so if it powers off anytime between there you can recover because you know what operation crashed so you can go ahead and actually release the blocks or something like that if that's the step it crashed on so inodes were the hybrid allocation strategies so they offer way greater flexibility over contiguous linked fat or indexed it's basically indexed but we're taking an idea from our page tables and everything is a file on unix names in a directory can either be hard links or soft links hard links point to an inode and soft links point to a name so we'll take the rest of the time to do the uh to do the ta stuff and uh just remember i'm pulling for you we're all in this together


Moodle 4 – Site Admin Presets Site admin presets allow Moodle 4 administrators to create, apply, download and import different site admin configurations. Our administrator accesses this new feature from Site Administration – Site Admin Presets. Two configurations are already available – the starter and the full. And from Actions, she can review the settings to see what is enabled or disabled and then decide whether to use this configuration, i.e. apply the preset. She can also download a preset to use it somewhere else. Presets can be imported from the Import Preset button, but our administrator wants to create her own preset. So once she has made some changes to her site configuration to personalise her site settings, she clicks Create Preset, gives it a name and description. She can then apply or download her personalised Site Admin Preset. To summarise, Site Admin Presets give administrators more control over their site configuration.


I'm graduate assistant coach Ashley Harper at Stevenson University. I've been called out by our head coach Tracy Johnson for Strikeout ALS, and now I challenge the entire Stevenson University women's ice hockey team to the challenge.


So So this morning I want to give Well, I say a technical introduction to Bitcoin and crypto currencies So we'll talk about the Bitcoin is some people call it a cryptocurrency. That's a currency that use cryptographic techniques to Ensure that we have the features of that we expect of a currency We're going to focus on Bitcoin there are others but Bitcoin the most popular will mention some others towards the end so we try to explain well, what is Bitcoin, but I'm going to focus mainly on the technical aspect of how it works and Towards the end we'll go through and look at some of the maybe the financial aspects what it's worth how to make money how to lose money and some other issues so To understand Bitcoin we need to know something about Cryptography because the way it it relies on cryptographic techniques. So we need to know the basics, but we can get away with Going through a lot of details So the next few slides and the handout Includes these slides and on the back of the handout. There's just a printed sheet starter wing assumptions, which is A little bit more detail of the first few slides Some people have seen it before they've sat in some of my courses and we've gone through this before but let's Look at the cryptographic principles that we need to understand Bitcoin And we'll not look at all the things that are presented in these next few slides Just go direct to the ones that are needed. So we're clear on the assumptions Actually, I've got and we've mentioned this before but not in much detail that cryptography to encrypt things We've got the the original approach called symmetric key encryption. I Want to encrypt some data I? Use a key a secret key. I encrypt it. I send the data to you you use that same secret key to decrypt That's symmetric encryption. This is just some notation that we may see we don't use that in Bitcoin Don't care about that today So there's another form public key cryptography And we did see that a little bit last week where we used email encryption using public key cryptography In his so let's say about that this because it is used in Bitcoin Each user has a pair of keys so everyone in this room has let's say you have your own key pair and One of them is called the public key and one's called the private key P you and PR as the name suggests The public key you tell it you can tell anyone you can make it public the private key You keep secret to yourself if you don't then it's no longer private and it's no longer secure and The algorithms in public key encryption are such that if you normally if you encrypt with one of those keys Encrypt some data with one of those keys in the pair Then you can only decrypt if you have the other key from that key pair Not all algorithms have that but that's the common that in either direction if I encrypt with a Public key of a particular key pair. I can only decrypt using the corresponding private key and Similar the other direction if I encrypt with a private key. I can only decrypt with a corresponding public key so that's common with some algorithms and We use those features to provide confidentiality and also signatures. So what do we mean by them? Confidentiality I want to keep my data secret. I want to send it to someone so that no one else can see the contents Only that recipient can see it. So I'm user a what I do is I have my message M and I use The destinations public key to encrypt okay, so I Want to send Sam a message Confidentially so that someone else cannot intercept What key do I use? The public key of who of Sam okay, so if I want to send to Sam I Encrypt using Sam's public key Okay, so confidentiality Encrypt the message using the destinations public key Okay, so another test You want to send a message to me Confidentially what do you do? encrypt Using so yeah, correct. So you encrypt and when we encrypt we use a key which key You want to send it to me? Use the public key of who of Dana of you of me or Of me, okay, so that's that's all we need to know how that works well the algorithms that implement that You need to study them to see why it works, but it works You encrypt with the destinations public key The only person who can decrypt is of course that destination because only they have the private key Okay, so that's the concept the other feature and commonly used Public key cryptography is to provide a signature Here we don't care if someone sees the message what we want to be sure that someone a Particular person created that message or generated that message and we can verify later that it came from that person We want to sign something. That's the idea here. We use the keys in the opposite direction and The person who wants to sign something encrypts the message using their private key. I Have a message I Encrypted using my private key. I send it to whoever to everyone to a particular person Can anyone read the message if I encrypt with my private key and send it to one person and others intercept Can they see the contents of the message? Yes, why? Yes, because the public key is public that is I encrypt with my private key I send to someone and someone else intercepts to decrypt they need my public key and By definition my public key is known by everyone. It's public This does not provide confidentiality People can still see the message But what it does do is proves that this message came from me Because if it decrypts with my public key it means it must have been encrypted with my private key And the only person in the world that has my private key is me So that's the concept of a signature to sign something You encrypt with your private key Anyone else can verify it came from you if they have your public key What if you want to sign a message and make sure no one else can read it, what would you do? Again, you want to send me a signed message and you don't want anyone else to read it What would you do? Encrypt the message with When we say by a private key always identify who everyone has a private key encrypt the message with whose private key you want to send to me a signed and Confidential message what you do You don't have my private key if you did it wouldn't be private Yeah, if you want both of these features signature and confidential. They just use them both that is encrypt the message with my with my the destination's public key for confidentiality and also encrypt using your private key For the signature part of it. So they're two separate Features two separate operations and we can do both of them if we like in Bitcoin we're mainly going to use the signature part. So what you should remember is That if you encrypt a message with your private key, we say it's signed and people can prove it came from you Okay, and that's all we need to know at this stage There are many different algorithms for doing this. There's just some of them or not many of these are the main ones This we're not going to focus on the algorithms just the concept any questions about signatures Of course, everyone needs a pick key pair. We can generate them and Then you need to distribute public keys Let's say we have a way to do that then we sign with our private key Another thing that's useful very useful and is an important part of Bitcoin is hash functions Everyone knows hash functions from Some data structures course maybe We've you've probably seen hash functions in programming when people talk about data structures But we use them in cryptography as well and Without going into the details What can we say a hash function is something that takes an input of any size of any length and Produces with a cryptographic hash function produces a fixed usually small output Which is effectively random Okay, the output is a random number or a set random sequence of bits and If we take the hash function of a different piece of data on input, we'll get a different output Okay, you hash one file You get some random number as an output you hash a different file you get a different random number as output Okay, and these outputs are usually small hundreds of bits and It's a one-way function in that if you hash some input and get a hash value as output That's going one way in the function going back taking that hash value and finding the original input is hard or impossible Okay, that's given a hash value. So let's Summarize this notation a hash function is some function that takes some variable size input some message M as in and it produces a fixed size Usually small output value called the hash value or the hash And I denote that as lowercase h here So the hash of M equals h If you know the hash value h you won't be able to find the message M That's this one-way function property That's this second one if I give you the hash value, but say say nothing about the message It'll take you forever so Practically impossible to find the original message But if I give you the message, it's easy to calculate the hash value easy going in one direction hard going the other direction some other properties If I have a hash value Well, we won't cover this we'll simply say that two different messages will always produce two different hash values it's Usually true in practice, but maybe in theory. It's not true But for the cases we'll deal with it will assume It's true that if you hash two different messages, you'll get two different hash values some examples You may have seen in different occurrences of different places MD five It's a hash function Sha the secure hash function sha one and there's sha version two and some other hash functions Okay, so there are different hash functions and we'll assume that they have these properties of one way only and Two different inputs get two different outputs Where have you seen hash functions? Apart from on this slide where maybe you've come across them in the internet or in computing where When you download the file you can check That the file that you downloaded is the correct one Why would it be incorrect? Maybe the download didn't download everything? Okay, or maybe there was someone malicious in between you the between you and the web server that changed it along the way So you go to some website to download a file and on that website they'll publish the hash value of the file Okay, so there's the file the link to the file and the hash value the MD five or sha hash What you do is download the file once you've downloaded the file You calculate the hash of the file you have and compare it to the one on the website If they match it means you've got the same file that the web server had if they don't match If the two hash values are different it means the two inputs were different Which means the hash the file at the web server and the file you have is different So you'll see it with that purpose of that's mainly for error detection To check that the file you received has no errors in it some examples I Have four files on my computer ex one through to ex four So the first two are text files and the other two are binary files Looking at the first two there are 23 bytes in length same length. Okay. Are they the same file? Or how do you know you need to look at the contents of the file? So Ex one is just a text file with a simple message. Hello. This is a demo. So it's just a ASCII file Length is 23 bytes. Okay. There are 23 characters if you include the new line We can calculate the hash and I have a program called char two five six some Hash is also called a checksum. So the program char is the algorithm There are different variations of char There's one that produced the 256 byte 256 byte 256 bit output. Okay, so If I use this program on that file, it will calculate the char hash value There it is. Okay, this long in hexadecimal If you convert that to binary, there are 256 bits there That's the hash value of the contents of the file not the file name the contents of the file So it this program took this text applied the char algorithm and Produced the 256 bit hash value and Example two Is it the same as example one? Oh? Well, if you can't see let's calculate the hash of example two different If you notice that it's the same text except I change one letter is to it Okay, so two different inputs produce two different hash values as output See do you see any structure in these hash values? patterns They are effectively random. Okay, there's no Relationship between these two even though the inputs are very similar There's only one byte that differs in those inputs the outputs are completely different and Random, okay, so that's what we'll assume hash functions produce random outputs If we hash the same file again What will the output be? If I calculate the char 256 hash of example two What will the output be? It will be the same When I say random It's not It's not just generating a random number But it produces a random sequence of bits such that if if we take the same input we'll always get the same output Okay, that's important So these two are the same because the inputs are saying but when the input's different we'll get a different output EX3 and EX4 a binary file is just larger about two megabytes They have files and so of those two megabytes I changed I Copied the first file and I changed I just one byte of those two million bytes. I changed just one of them So all of the bytes in these EX3 and EX4 files are the same except one of them Let's see This is a bit Out of scope, but I just show you that the binary or the hexadecimal of that file What I'm showing is the first 64 bytes of EX3 and then the first 64 bytes of EX4 and in hexadecimal Doesn't make much sense. It's a binary file. It's an application actually I think If you look closely 5735 5835 the only difference Of all these bytes in the file is this this one here. It's 57 and here's 58. Everything else is the same three four four seven Zeros and if you went through all the two million bytes, they're all the same except This byte okay, I just changed one byte And just to show that our hash function works again hash of EX3 is this C11 C7 that it Hash of EX4, which is almost the same as EX3 is completely different just random hash values with different inputs questions so Really for now all you need to know is that to sign something we use our private key and Hash functions produce Random outputs and for two different inputs will produce two different outputs and If I give you this hash value one be a F. I tell you this You will not be able to find the original file. It's impossible in this case Or practically impossible that is If I just give you the hash value go and find the original input We say that's practically impossible to take the hash and find the input. I think that's Set us up for Bitcoin But digital signatures we've basically said in practice digital signatures We said we use the private key or in practice we hash the message first, but not important that's Random numbers, we're assumed that we've got good random number generators as an entire topic on How to implement random number generators in a computer? But that's not for for this So there's nothing more to say a tax Again, that's not relevant When I say that we have a private key We assume that that's kept private if if you if you've got a private key And you tell someone else then all of the conditions that we're building Bitcoin upon Will not work. Okay, it must be kept private If it's made public then things fail the security of things that's that's the assumption But I think those points are not relevant to go through this point Let's get into Bitcoin And if there are questions which come back to these cryptographic principles will return to them if needed What I'll do to try and introduce Bitcoin is go through a simple example of how we transfer money between people using a bank and then look at Well, how do we do it using Bitcoin? because we'll see that Bitcoin tries to be a decentralized currency a decentralized payment system really a Payment system is something that we can transfer money to someone else pay someone With banks we can think think of them as centralized systems So the bank is this central point which all our payments go via. I Want to transfer money into your account? Well, that's transfer is actually via banks. Okay, so I use my bank account to transfer into your bank account The bank plays a role there Bitcoin tries to make that decentralized that there are no banks But I can still transfer money from me to you Okay, so we want to see how that works so how do we pay people using Normal banking and we just use a simple example and a game Let's say we all have an account with one bank Everyone here has an account and we want to pay or transfer money between people. I want to pay for something And how does it work when we use a normal bank? Well, the bank keeps track of Your account balances. Okay, the bank knows how much you have in your bank account and They keep track of transactions So if I transfer 10,000 bar to one someone else's account That's a transaction. Okay, it comes out of my account and goes into your account So the bank has a record of that transaction and From that transaction, they know that my balance has gone from 100,000 down to 90,000 and the destinations account balance has gone from 10,000 up to 20,000 Okay, transactions change the balances So from a transaction point of view, we can think there's always an input account Transfer from my account is the input Then an amount how much I want to transfer And the output account who am I transferring to and if you use online banking, that's the basic setup you say Okay, from my account transfer 10,000 bar into this destination account That's a transaction. That's all done via bank when we use In this example, so it's a centralized system in that the bank Is involved and the bank is the one that keeps track of these transactions and keeps track of your account balances Can we do it without involving the bank? That's what Bitcoin tries to do try and do it so that I can pay someone and Have the same features That okay that people can't cheat. Okay, it's no good if I pay someone. I say Here's 10,000 bar and then sometime later someone comes back and says no, you didn't send me that 10,000 bar or I've got an account balance of 5,000 bar. That's my current balance and I try and pay you 10,000 bar That shouldn't be allowed. I've only got 5,000 bar. I shouldn't be able to transfer to you 10,000 bar or I Have 5,000 bar in my account and at the same time I pay one person 3,000 bar and another person 3,000 bar If my balance is 5,000 and I try to spend more than 5,000, it shouldn't be allowed A bank keeps track of those your account balance and those transactions and prevents that from happening Okay, a bank won't let you spend more than your about your balance So what Bitcoin tries to do is create a decentralized system with no bank involved but still has those features Let's go through and look at transactions and then we'll move and see how that's implemented So in a normal banking situation, we may view it We've got three people three accounts okay Me, Tanarak and Pekini, okay different faculty members. We want to transfer money between each other and Let's say to get started We each have the balance according to the first row. I have zero Units but whatever dollars doesn't matter Tanarak has 30 and Pekini has 45. That's this opening balance and Then over time as time increases. We make transactions. We transfer money to each other So in this example Tanarak transfers five units to me as a result His balance goes from 30 to 25 mine goes from zero up to five. So the blue one is the transaction Input account was Tanarak output was mine. The amount was five Then some time later so the rows keep track of the balances Pekini transfers eight bar to me Mine goes up those goes down and then maybe another case. Here's a special case. We don't often see Tanarak transfers five to me and ten to Pekini in A single transaction. Well with banks. We don't normally allow that But we'll see Bitcoin. That's possible that you can have a transaction and you can specify different destinations So we'll see that come up that is Of course Tanarak's account balance will go from 25 down to 10 15 is coming out Ten of it will go to Pekini. So hers will go up to 47 and five that's going to me So mine will go up to 18 And then a last one I transfer. So the Balances at the end of 7 21 and 47 We'll try and go through and see how Bitcoin implements such transactions And look at some of the issues Any questions on what I've shown here. This is just for the normal bank easy Okay What if I? Want to create a transaction to pay Pekini 10 units 10 bar what happens? What does a bank do if I at the next step? I try to transfer 10 to someone the bank or the system would prevent that from happening It would reject the transaction because I only have a balance of seven If I try to transfer 10 to someone else the the banking system will reject that transaction the bank Is the one that keeps track of these transactions Okay, so the bank has a record In their computer system of all of these transactions so that they know if these were the starting balances These are the current balances It's easy to calculate You just look at all the transactions and you work out what the remaining balance is That record of transactions is sometimes called or is often called a public ledger or a ledger a Ledger is just a record of these transactions We'll see the Bitcoin looks at transactions. So we We could present this information from a transaction point of view. Look at the blue lines five from Tanarak to Steve I Could write that as a transaction one txn meaning transaction In was Tanarak. That was the input account out. It went out to me the amount was five So I just summarized that transaction Transaction to From Pikini to me eight units That was this one. Okay, so the blue lines I've written as four transactions Transaction three in from Tanarak Output one was me Five units output to Pikini ten units. So we could have a transaction with two outputs or multiple outputs It turns out in Bitcoin. You can have a transaction with multiple inputs as well so if we know the opening balances and We have this list of transactions Then we know how much everyone has How much do I have at the end of these transactions? Well from that I start with zero Out to me five so plus five out to me eight plus some plus 13 Out to me five. I'm 18 In from me that is I'm spending minus 11 so 18 minus 11. I've got seven units at the end of these four transactions So we can if we have the list of transactions and We know the opening balance Then we know the current balance and what we're seeing a decentralized payment system is that and in Bitcoin We record all transactions that ever occur There's a public list of all transactions So if everyone knows this list Then everyone can work out what everyone else has So from this information Steve Pikini and Tanarak all know what each other have As their current balance therefore if If I try to send 20 baht to Pikini She will not accept that Because she can determine that my current balance is only seven baht Or seven units So if you know the list of transactions You can Provide these features of a bank that is working out who has what And stopping people from double spending or overspending questions Nothing about bitcoin really yet just about banking or payments But we'll see that All right Let's extend this what about these opening balances? Well, we can treat them as special transactions Where does my balance or where does Tanarak's balance opening balance of 30 come from? Well, let's treat that as a special transaction Let's say all users start with zero but If everyone has zero then we cannot transfer anything Okay, so what do we do? Well, somehow we need to create money All right, we was talking about how at the moment But let's say somehow we magically create money and we say a transaction was there was no input But the output was Tanarak of 30 units So I'll record that as a transaction Let's think of that this creation of money How do we create money nowadays? How do we create it in the past? Anyone from America here? What do you do before what did the Americans and you see it in movies or popular what happened? I guess in california. I don't know when in the 1800s A gold So there was a really a gold rush People discover gold Okay, so what happened is that people found gold in the in the ground. What did they do? And other things so they they mined the gold And then I guess what they would do is they take that piece of gold to a bank and the bank Puts into their account the value of that gold Okay I find a piece of gold in the ground I take to the bank and the bank says okay, this is worth a thousand dollars So now my account balance is a thousand dollars My account balance was initially zero But I mined and found the gold Took to the bank and the bank treats that as some some value of say a thousand dollars So this is this initial transaction of how we created money in the account And there are other Examples, but that's let's assume that's what we do and what we'll do in bitcoin That there's some process that we can create this initial Money And we'll treat that as a transaction a special transaction where there's no input We don't transfer money from someone's account. We just create it so that Tanarak gets 30, Pekini gets 45 Three through to six are the same as one through to four here. I've just introduced these two transactions In bitcoin we'll see later. These are referred to as coin based transactions. These create new coins Create new money And it happens via mining So we come back to see how they work So now if we Assume all users start with zero and we have a list of all transactions. Then we know everyone's current balance And if we know everyone's current balance Then we can do things like detect if someone's trying to spend more than they have Okay, which is the feature we want in a banking system or a payment system so We can think a bank stores this information a bank When you go and create an account of the bank you deposit your 30 bar Then think of that as transaction one You put some cash into the account so the account now has a balance of 30 It started at zero when you created it you deposited money. It's now 30 So they record that transaction And they record all the transactions of transferring money from one account to others Therefore given this information the bank knows that What the current balances are? So the bank effectively records this log of transactions We want to decentralize log of transactions instead of the bank records it It's not recorded in one single place, but it's recorded everywhere by everyone So we don't rely on the central bank So we get a decentralized log of transactions Instead of the bank storing this list of transactions This list of transactions is stored by everyone I have a copy You have a copy Everyone in the network has a copy of that list of same transactions And we'll see The way that it works is that let's say now we have a network of users who are going to use bitcoin for example The group of people who want to use it Then when you want to create a transaction you want to pay someone You create a transaction and tell everyone else that transaction You inform everyone in the network. Here's a transaction transfer five from steve to tuner Then everyone else in the network will verify that transaction And verifying means Performing some checks Including making sure if it's a transaction for steve paying tunerak five units to make sure that steve has five units to pay We should reject any transaction that Overspends or double spends money that is If my balance is 10 Then I should be able to make any transaction that is Up to an including 10 I shouldn't be able to pay someone 11 Okay, so the verification of the transaction is done by other users in the network With respect to the previous transactions in the log For example, if everyone knows this and then transaction seven comes along steve pay tunerak 20 Everyone should verify that transaction and find no it's not allowed because steve doesn't have 20 But if transaction seven is steve pay tunerak five Then it should be allowed because I have five more than five in my account So a user creates a transaction Everyone else in the network of users verifies that transaction And if it's Acceptable if it's not rejected then they add that to the log Okay, so it's added to the end of the log and then distribute that entire that updated log to everyone else So that's bitcoin That's how it works users create transactions. There's one log of all transactions But everyone has copy As a new transaction comes then that people verify that it's valid and then add it to the log There are a number of issues Now we're in the internet and there's many users across the world trying to use this system We need to get this log the same log of transactions To everyone in the network It made mean that I have a log which is different from someone else So we need to somehow reach a consensus that everyone agrees upon that same log We want to do things like stop people changing past transactions. Okay. I shouldn't be able to go back and say Uh What Steve sent 11 to tuneruck. I shouldn't later be able to go back and change 11 down to nine And say I only sent nine to him So once a transaction is verified and added to the log It shouldn't be able to be changed And we shouldn't be allowed users to double spend double spend is if I have it a balance of seven And I make two transactions both sending three to other people Uh, sorry not three, uh four Okay, if I send four to two other people that shouldn't be allowed I'm spending my money more than I've got Okay, two times four is eight, but I've only got seven So I shouldn't allow that Here's an example We had our previous log of up to six transactions And then there's a new transaction submitted to the system to the network Assume everyone knows these six transactions. We all know and agree upon them And then a new user in this case bikini Creates a transaction saying send from bikini to tuneruck 15 units This transaction seven is submitted to everyone else Everyone else checks Based upon the previous log is this one allowed? And they determine yes, it's allowed Why? Because bikini has enough Balance to transfer 15 out if you check she starts with zero She has 45 She sends out eight No in is the input account who it comes from So she's down to 37 She receives 10 she's up to 47 So she's allowed to send 15 out. She has a balance of 47. So this transaction is accepted Okay, and it's added to the list So we now have seven transactions and then I create a new transaction. I send it to everyone And everyone checks I want to send 10 to tuneruck and you do the sums if you see beforehand my balance was seven If I try to send 10 to tuneruck that Transaction should be rejected. It is not added to the log Okay, it fails What if I go back and change transaction six? Okay, so this one would be rejected So we've got seven in our log What if I go back and somehow everyone's agreed upon these seven six was accepted in the past So this log think of it as a large file recording all these transactions. Everyone has a copy What if I could go back and change the values in the file and make everyone believe that I change this one. I sent 11 to tuneruck. I go back and change it and change it to eight If I could do that Then my transaction to tuneruck would be accepted Because if I change that to eight you can calculate that I would now have a balance of 10 We shouldn't allow this this should not be possible You shouldn't be able to go back and change transactions which were previously accepted Okay, so it should be just one record of all the accepted transactions We need to prevent users from changing the past transactions Now All right, so that's one one challenge. We have how do we do that? Well, we'll see what bitcoin does is that The aim is to make sure that verifying transactions when you verify that A transaction is valid Doing so requires a lot of effort And that once one transaction is verified It depends the next transaction depends upon that What bitcoin will do to try and stop this is to make sure that to verify a new transaction It requires some time or some effort on the people on part of people who verify and that The subsequent transactions depend upon the previous one What that means is that if I go and change this value if I try to change it It's just some data in a file It's easy to change But then I need to re-verify that transaction Or get the network to re-verify and that takes effort and we'll see it takes computational effort and The system is set up such that all subsequent transactions also would need to be re-verified That is this one would need to be re-verified And we'll see that the bitcoin is set up so that The verification requires some computational effort You need your computer to compute something And If I want to go back and change it I would need to get either my computer or other people to re-compute this one and re-compute this one The amount of effort it takes to re-compute these transactions to make this change Is usually too great And there'll be other ways to uh So that is a lot of effort is needed to make this change And it's too much effort to get some benefit from So we'll see how that works That'll make sense after we go through bitcoin in some more depth So we've just talked about transactions nothing about what is a bitcoin or what is this this system Any questions on transactions so far? Think of we have a an input account Where the money comes from The amount that we want to send and an output account where we want to send to And we have a log of all transactions think of it Simplistic simply as a large file Every transaction is recorded in that file And that file Everyone else everyone has a copy. I have a copy on my computer. You have a copy on your computer and so on And there's a communications network that if when a new transaction is added The file is updated and everyone's file is updated. That's the idea So let's see how bitcoin implements this concept So we can think of bitcoin as a payment system a way to pay Pay people to transfer money from one account to another Sometimes called a cryptocurrency or a digital currency and even other things The unit of currency or the accounts Is bitcoin which is lowercase b or btc So the unit of currency of my bank account with bankock bank is bar The unit of currency of my bank in australia is australian dollars The unit of currency in bitcoin Is bitcoin Okay or btc All payments are recorded as transactions Shortened as txn. So everything's thought of as a transaction And there's this what's called a public ledger Which is just a long list of all transactions This record of all the transactions that have occurred in the past When a new transaction takes place the user who creates that transaction Sends it to everyone in the bitcoin network. So there's a network of users In practice people run bitcoin software on their computer And when I create a new transaction, I want to send money to someone else I distribute that transaction to everyone who's Or to the network. It's not necessary everyone immediately, but I think of everyone else who's running the bitcoin software I distribute it to everyone and everyone else verifies and checks Is this transaction allowed? Is it accepted or rejected? And if it's accepted It's added to this public ledger. It's added to the list of trusted transactions Users are identified using public keys. So now the first use of cryptography In my bankoc bank my account. I have an account number. It's got my name on it So my account really is identified as me If someone wants to transfer money to my bankoc bank account, what do they need? Usually just my account number Okay, so if I you want to send me money, I'll just give you my account number And you can send me money Okay, in bitcoin users are identified using their using public keys So each user has a key pair Everyone has their own public and private key If you want to send someone else money, you need to know their public key Or a someone version of their public key, but You can have multiple key pairs So I can create a thousand of my own public keys I don't is not restricted to one per person. I can have as many key pairs as I like I just generate them easy to generate on your computer So if I want someone to send me money pay me for something Then I just advertise my public key And when someone wants to send me money they get my public key and they will use that as the destination Who to send to them so think of accounts or users are identified using public keys So on that public keys Yep Yes, correct Yes Right, so you're right. That is I I create a new transaction pay Someone a thousand bitcoin. Okay, that's the transaction. I'm going to transfer them some bitcoin Then that transaction is I'm just talking generally sent to everyone in the bitcoin network And they verify it the verification takes time Okay, it takes some computational effort to verify And therefore the person I'm paying So I submit that transaction to the network it takes time To be sent across the network and also more importantly to be verified And Therefore the person who I'm paying shouldn't believe that I've got the money until it's verified Okay, let's say I pay Sam one bitcoin and he's going to do some work for me So I create the transaction. I send it to the network. It's being verified Sam shouldn't believe that he's got the money until it is verified So, yes, there's some delay from when the transaction is created until it should be trusted to be verified It's not accepted instantly So So then the destination has to wait. Well, it's up to the destination as to how long to wait If Sam trusts me and he knows that Steve's not going to create a transaction that Is is invalid Then when I tell him I've sent the transaction then he may even though it hasn't been verified He may believe that he's got the money and do the work But if I've never met Sam before he doesn't trust me and I say I send him an email. Okay transactions being sent Then he may not He may wait until there's some confirmation from the network. Okay, so the how long do you wait depends upon How much do you trust the sender? Okay, and we'll talk about some rules as to how long to wait. So there are some some rules that your software will use to wait before If you think now you use software to keep track of your account balance. It's called a wallet That account balance will only be updated after some time after the confirmation transaction Yes, so we'll see the confirmation requires We'll see that in a moment We'll see that later How long to wait or how many people to verify We'll see that once we see what the verification actually is because that's important It could be in the order of tens of minutes hours in practice And we'll see why Back to our our accounts or our identity. We have public keys. So each user can generate one or more public private key pairs Okay, so it's quite easy. The software will do it for you And you don't need just one. You can have as many as you like the public key Here's some numbers the private key is 256 bits the public key is 512 bits plus some extra header information Not so relevant. Not not important. So for example coming back to our transactions Steve has his public key p us and his private key prs. Tanarak has his key pair and maybe pikini has multiple key pairs The advantage of having multiple is that You can have some you can start to become anonymous It can be more convenient, but also it's harder for people to track Which transactions you were involved in We'll see that at the end the How to be anonymous in bitcoin. So let's say our three users have their own key pairs. I've generated them The public keys are actually hashed Really for convenience. So I have a public key which is 256 bits That value is run through a char 256 hash and then some other hash Function right md 160 and the output is 160 bit value Slightly shorter a little bit more convenient to tell someone But actually more convenient is that that public key hash Is encoded into some a little bit easier format so that I can post it on my website Or I can include it on in an email easy because this public key hash Think of that as my account number if you want to send me money you need this value If I write 160 bits in my email, it's likely I'll make a mistake And you'll send it to the wrong person But so there's some way that the Hash value is encoded. So this has some error checking so that it's hard to make mistakes in that value This is a bitcoin address Bring up some examples I think I've got one This way I'll bring up an example I'll just search on a website Be patient Just an example that Has some hash values So Someone creates a private key. So there's an algorithm for creating your own key pair. So you get a private key So an example value here. So you keep this value This is encoded in a nice form so that it's it's actually a 256 bit value which is encoded And you can generate a public key from that It uses an algorithm such that you just need to store your private key and later you can create your public key from that And here's an example of a public key. It's quite long here But then you take a hash of this value using char 256 and you get this And then you take this value and apply this other hash algorithm right md 160 and you get 160 bits or in encoded form So this is the what's called the public key hash That's what you can tell other people Your private key you keep private There's some extra information added where'd we get to They add some version to identify what version of the protocol being used And Apply some some more operations and I think we get down to the bottom. We get the the address Like the one down the bottom here Almost there Apply some operations just to make it more convenient to use and you get a what's called a bitcoin address And that's what you may often see if you want to transfer money to someone You get some random looking string like this. It actually identifies or comes from the a public key So you want to transfer someone's Someone some money That person has their public key. They apply some hashes on their public key and they get this address They tell you this address and you send money to this address So transactions so addresses are public keys Or based upon public keys transactions similar to our previous simple example, we have inputs outputs and an amount In bitcoin, so we have inputs they identify where the bitcoin comes from And we actually may have multiple inputs Normally with a transaction one person sends to one other person we think but bitcoin allows To send to multiple in a single transaction and actually we'll see allow multiple inputs to send to multiple outputs It's hard to Explain until we go through see how it works There'll be some transaction ID txn id Some of this we'll explain through example The input Will include the sender's public key Okay, I'm sending to someone else. I'll include my public key And I will sign the transaction data when I create a transaction To pay someone else. I must sign it And we sign using my private key Okay, and that way when someone Wants to verify the transaction. They know it came from me because it was signed with my private key And they can verify it came from me Because they have my public key So we use our public key cryptography to sign The outputs will show where we're sending to so a transaction will be Send this amount to someone else We'll come back maybe through examples see these exact fields Let's go Here's our example transactions from before I think we've seen it before but I've just changed the notation. Okay We may have multiple outputs. So transaction three was Tanaruck sends to Steve five units But a special thing in bitcoin is that every transaction must spend everything that comes in that is How's the example? Come back to one of the earlier slides After transaction two, what is Tanaruck's balance? How much money does Tanaruck have after transaction two? After so before three four and five have occurred Tanaruck has 30 So his balance is 30 When he performs a transaction if we move into bitcoin he must spend all of that 30 The next transaction takes those 30 units or 30 bitcoins if we now deal in bitcoins And the next transaction has 30 coming in And there will be 30 going out That's the rule in bitcoin that everything that comes in must come out So in the our old bank view He had 30 coming in only five went out to Steve. Where's the other 25 in this case? Who gets the other 25? Tanaruck that is that's his remaining balance In bitcoin we must explicitly say that Tanaruck has 30 Transaction three he wants to spend Input is all of his 30 the output five to Steve And the leftover goes back to himself It's just a feature of every transaction. What comes in must go out And the way to deal with that is just send it back to yourself the change If you don't want to spend it all Send it back to yourself So that's this this new thing that In from Tanaruck out to Steve five units or five bitcoins out to Tanaruck 25 So his balance is now 25. He still has 25 bitcoins. That's why it's implemented So these turn out to be there are same six transactions as before so Tanaruck has 25 out and so on I think this and may be easier to read on your handouts here Tries to capture those transactions that we've gone through those six transactions And so we'll go through this and identify the notation that we start to use And we'll see when we use bitcoin so these six transactions Txn one think of that as the id for this transaction So this rectangle i've shown this was a special transaction nothing came in This is where we created money Okay So there was no input the output was 30 bitcoins And it was to Tanaruck and the notation i'm using remember the destination address Is actually a hash of a public key So this was 30 bitcoins to Tanaruck and i denote that as the hash of the public key and the subscript here is t Tanaruck's public key This transaction says that 30 bitcoins goes to Tanaruck It's his public key it identifies his account This transaction two identifies 45 bitcoin go to Pekini p1 Pekini has multiple public keys She created so p1 is one of her public keys So hash of Pekini's public key identifies the destination address Transaction three remember Tanaruck wanted to send a five to steve So the input Refers to the previous transaction if Tanaruck wants to spend money He must have that money And in bitcoin the Record of logs The the record of transactions Refers to the previous transactions So here we say the input for this transaction was transaction one Because transaction one says that Tanaruck has 30 so the input to transaction three Refers to transaction one We'll see some other information the output Will be five to steve So the hash of steve's public key saying send five bitcoins to steve And another output send 25 to Tanaruck that's think of that as the change Tanaruck has 30 bitcoins. He wants to pay me five because I did some work So he creates a transaction that pays steve five so using my Public key my address and the remaining 25 the change of that payment He sends back to himself So he still has 25 left because all all transactions must spend what comes in So we talk about the input to a transaction and the outputs The outputs identify who it goes to and how much The input identifies the transaction where the money came from The bitcoins came from And Tanaruck has 30 bitcoins. How does he get to spend those 30? Why can't someone else spend it? Well the output of transaction one included the public key of Tanaruck So for him to spend it he Includes his public key in this transaction and he and effectively signs all of this data using his private key And Someone can verify transaction three Transaction three includes Tanaruck's public key. It points to public transaction one Transaction one was paying Tanaruck Someone can verify this because they can check Using the public key from transaction one. We can verify the signature Yeah The only person who can sign this transaction is the person who has the private key t And since it refers to transaction one which includes public key t This would be verified Think of it another way. What if I wanted to spend Tanaruck's money? Transaction one sent 30 to Tanaruck if I tried to create this transaction three I must sign it I must sign it I cannot sign it with Tanaruck's private key. I would sign it with my own private key If it was signed with my private key here prs Someone would then verify this and they would check Transaction one was sent to pu to pu t But the signature uses something else. It doesn't verify What they would do is actually use the public key pu t And then try and verify the signature And it would fail because the signature if I created this transaction Would be using prs And the verification they would use pu t and if you try to Decrypt using the wrong key It will detect that So this idea of referring to the previous transaction is a way to keep track that this person has that money To spend in this transaction That's getting more confusing questions Let's just look at transaction one and transaction three Why do we need we need we have to hash the property key? Uh, I think the hash of the public key here is just a convenience really It has some minor security benefit, but mainly for convenience to keep it short and address but From a cryptographic Sandpoint think of the public key The hash also provides a A better improved chance that someone could not work back to the public key if there's some flaw In in mapping public keys back to private keys It still is hard to go from the hash value back to the public key but Mainly for convenience there. Yep. Take a hash get a unique specific value Shorter and especially for addresses But you're right from a Cryptographic point of view think of it this identifies the public key of Tanarak So when someone verifies transaction three Transaction three must be signed by Tanarak Transaction three points to money that Tanarak owns therefore for someone to spend it. They must have the private key So Let's try another one transaction four. Remember transaction two was paying Pekini It was sent to the public key of Pekini p p1 in fact in this case Therefore if Pekini wants to spend that money She creates a transaction txn4 She creates this transaction referring to the one where she was paid money And to prove that she is Pekini. She signs this using her private key And someone can verify that it's the right private key because they know that transaction two use public key pu1 pu p1 And therefore it's signed using prp1. It's verified to be matching So this this is an important part to say the person who created this transaction owns the private key corresponding to the public key that the previous transaction was sent to This one sent to public key p1 To be able to spend that you must have private key for p1 And that's what Pekini does here. She encrypts using the private key of p1 to prove to others That she owns or she's the destination of the previous transaction And then she specifies where to send this. What was it 45 bitcoin to? She sends eight to steve identifying using the public here of steve And sends 37 to herself. That's the change utx o Is an unspent Transaction something Okay, I can't remember it's written. I think somewhere on the on the slides it's it's Bitcoin currently unspent so At this point in time after these six transactions This 37 hasn't gone into another transaction yet. It may go later So we see let's follow through the last two Transaction three Tanarak sent 25 to himself P ut is the destination Therefore transaction five refers to transaction three Signed using prt If it was sent to pu t it must be signed using prt The corresponding key in the key pair to prove that Tanarak is allowed to spend this money And he specifies sending five to steve 10 to Pekini and 10 to himself Remember 10 plus 10 plus five matches the 25 from here And then the last one what was it steve received five We'll come to that in a moment. Let's recap So we're starting to get in the technical detail of the structure of each transaction The input refers to the previous transaction and in fact the id of the previous transaction So tx n1 is the input to transaction three and Remember we may have multiple outputs Here we have one two three outputs So the input refers to which of those outputs So I try to denote that as Transaction three the input is transaction one specifically output one from transaction one Transaction five the input is transaction three specifically output two Okay, so think of as an index If we can have multiple outputs The input refers to which of those outputs And therefore we know that the amount coming in here is 25 Because transaction three output two sent 25 and that sent to Tanarak Therefore we have 25 coming in and it's signed using Tanarak's private key to prove that he's allowed to spend this And he specifies three outputs One of them output one goes to steve p us So I create transaction six But here's a special case. There's two inputs Transaction five sent five to steve Transaction four sent eight to steve. So that's 13 in total So there's 13 coming in to transaction six Five from this transaction eight from this transaction 13 in And I pay 11 to Tanarak And two to myself the change goes back to me. So it's like I've got 13 bitcoins I give 11 to Tanarak and the change the two remaining is kept for me That's what this sent to myself is And it was signed using my private key Proving that I'm allowed to spend Because the previous transactions referred to my public key almost there Your question. What is an unconfirmed transaction? What's the oh Someone will find out later After these six transactions, how much do I have? What's my balance Seven if you remember back to the old example at seven, it's the same Uh, where where does it my balance? Well, look at these utxos That's your current balance This transaction unspent currently is five units to steve five bitcoins to steve So i've got five here And this is to someone else bikini. This is to bikini. This is to Tanarak and I have another two here unspent So I have seven So my wallet Would show that my current balance is seven bitcoin So it's the sum of all the unspent transactions Of course, I may create a new transaction that starts to spend that And I would specify the inputs and who would I send it to? So this is starting to introduce the structure of each transaction and also some of the concepts of Well, we sign transactions Transaction is think of bitcoins are sent to someone's public key To be able to spend it you must prove that you have the corresponding private key And you do so by encrypting with your private key you you sign For someone to verify this transaction. What do they do? Transaction three. How do they verify? Going back to our basics people create transactions and they send them to everyone in the network So these rectangles think as my computer creates this Creates some data structure some message with this information Broadcast to everyone in the network that everyone verifies that transaction How would you verify transaction three? How would you check that? It's allowed Assuming all right forget about five Four five and six assuming transactions one and two have already been verified as are in the log Then you receive transaction three. How would you verify it? What would you do? Verify the signature. Okay, so what you would do is say okay transaction three says it comes from transaction one So what you would do is check the log and you'd see transaction one was to public key t to Tanarak That's already been verified Tanarak received 30 So that this transaction refers to that so what I do to verify now is I Note the signature the signature and I haven't explained it yet, but We take all of this data in the transaction We hash it to get it small and we encrypt it with a private key That's the signature of the data To verify that signature someone uses the public key of Tanarak from transaction one Decrypts this if it was encrypted with Tanarak's private key. It can be decrypted with Tanarak's public key and then compares the hash of This data with the value included here and if they match everything's okay But if I tried to create this Transaction if I tried to spend Tanarak's money I would have encrypted with Steve's private key prs If I if this was encrypted with prs Then When someone verifies they will use Tanarak's public key to decrypt If it's encrypted with Steve's private key and try to decrypt with Tanarak's public key You'll get an error the decryption will not work and it will it will recognize that okay So that's how we verify the transaction by using the public key of the inputs to confirm that Yeah, it is Tanarak spending this money Because the only person who has the private key to sign this is Tanarak No one else should have it and of course the other part of the verification is making sure the amounts match that is okay He's not spending more than he got in the previous one That's quite easy to check So you check the signature and check the amounts match That that assumed so that example assumed transaction one was verified by someone else So remember at some point in time we have a list of transactions which have been verified Assuming the first one was verified at the very start when bitcoin started Then assuming ones verify or some are verified then the new transaction is verified with respect to all of them Okay, so in this case assuming one and two are true or valid Then we can verify three So now we have one two and three being valid right we can verify four When they're in our log of transactions We can verify five because five refers to three Three Went to the public key of Tanarak It was signed using the private key of Tanarak that passes the verification Three sent 25 to Tanarak 25 coming in 25 goes out If he tried to send more than 25 out it would fail There the verification would not work If there's 25 in and 26 out Someone would detect that So then this would be verified then eventually this one can be verified if the previous ones are verified And we keep building up the log of verified transactions So in fact in bitcoin all All transactions are recorded and logged From from the very first and I started at this website and we saw transactions being recorded on the website We'll come back to that later Each transaction you can have I don't know if there's a limit on the the number of inputs and outputs, but you can have multiple Normally just one and one one input one output But you can have multiple inputs Maybe there's the The software has a limit okay based on the data structure of the number of inputs and outputs But typically you have multiple And you can have a special case these first two no inputs This is the creation of money And we need to get to that. This is the concept of mining Somehow someone creates money And it goes out to someone So it depends on where your money comes from as to how many inputs and who you're sending to as to how many outputs So by verifying transactions we prove that the person who's creating this transaction is allowed to spend that money Okay verifying transaction three proves that Tanarak is allowed to spend 30 bitcoin Because it corresponds to the 30 bitcoin he just received And Then subsequent transactions can be proved or verified based upon that previous one Any questions before we shift from this slide? This is maybe the main one You're not spending any bitcoins. Are you? We'll see it How many how much people are spending shortly? What have we got left a fair bit? Let me just have a look before we have a break. Okay a couple more slides So that's the basics again There's one big log of all transactions so far Every transaction is recorded As we verify them we add the new transactions to that log and the way that it works is that Everyone who's running the bitcoin software keeps a record of these transactions And when I create a new one, let's say I create transaction seven to pay someone I create it and send it across the internet to everyone else who's using bitcoin And then they go to work to verify that transaction And once it's verified it's added to the log And then subsequent transactions are keep added and added and the log is updated So we can think everyone has a copy of all all transactions We'll get to the point that the verification To stop people from cheating will need to take some effort Some computational effort the next concept so send The creator of the transaction the one who wants to spend the money Broadcast that transaction to the network The others in the network validate the transaction Check that I was the person who's Had the money in the first place and check that the right amounts are used So Use the hash of the public key and check the signature And once it's validated they add new transactions to this public ledger this public list of all transactions Now there's this new new thing that This verification of adding transactions to this record of Existing ones are done in blocks or groups of transactions. We don't do one at a time We'll see that we Group a set of transactions into a block And there's some operation on that block that must be performed before all of those transactions are added to the log Okay, so now we Instead of doing per transaction. We actually group a set of transactions and then operate on them So called a block and we'll see why in a moment So one or more transactions are grouped into a block. Usually it's more usually it's hundreds of transactions are grouped into one block Now the block So instead of transaction a pure transaction log. We now have a block log instead of Listing all transactions. We have a list of all blocks and those blocks include the transactions We'll see blocks. I think the details of them We'll see the details in a moment What do we want to say here So a block refers to some transactions And we'll see that once a block is verified then all those transactions are verified or confirmed And then we actually have a chain of or a list of blocks The very first block contains the very first transactions using bitcoin When once they were verified Then a new set of transactions that people submitted were verified in the second block And that was added to the list of blocks and then new transactions came and they were verified So the transactions verified in a group. They are added to the block And we build up a chain of blocks and we get this blockchain So now we operate in not just one transaction, but usually a set of transactions and call that a block And the block chain Because each block refers to the previous block Like a link list if you know about link lists from programming one refers to the previous element It's the same with a blockchain one block refers to the previous block This is our public ledger. This is the record of all transactions Because every block contains records of transactions So everything that's verified is added to the blockchain So we'll see that referred to commonly So when you see a blockchain it means all verified transactions But grouped into blocks the challenge To make sure bitcoin works correctly is to make sure that Because we have at the internet everyone has their own computers doing this verification One challenge is to make sure everyone has the same view of all transactions being verified Because if if one person thinks these transactions are verified and another person thinks a different set of transactions are verified We can start to get errors and we can start to get cheating where One person verifies transactions that says Steve spent Five of his six bitcoin And another person verifies a transaction saying Steve spent three of his six bitcoin To someone else And we get what's called double spending that one transaction says I spent three to Tanarak Another one says I spent five to bikini. I only had six to start with if both of those transactions are verified Then it says I spent eight of my six bitcoin, which is wrong and not allowed So we must make sure that the transactions sort of are done in the right order That is if if one is verified that it says I spent five of my six Then the next transaction where I spend three of my six is rejected If people have different views of which transactions have been verified Then this problem arises. So we must make sure that everyone has the same view Of which transactions have been verified So so the yeah, so how to do that is you transact one transaction After that's finished then verify others remember it's it's a distributed system and what's happening is that I I create two transactions Send five bitcoins to bikini send three to Tanarak And I send them through the bitcoin network But I send them in such the way that the one one of them goes sort of to this area of the network in the internet So these people start to verify that transaction And the other one goes to this group of people and they start to verify this one And they don't know about the other transaction It's a distributed system and not everyone has a complete view of what's happening So that's the problem that This group are trying to verify one transaction that spends my bitcoins Where another group are verifying a different one If they both are verified then I spent more money than I had We want to stop that So if we have a bank And there's a single entity that verifies all transactions then you can do what you say is you do one after another But in a distributed system Where there's entities everywhere doing Things independently then we cannot control that How we control it is we make sure that the verification takes some effort And Some effort such that Okay, these people verify one transaction if This group verify the other one Then eventually that will be detected and then eventually we will reject one of those And that's where the blockchain comes in that's Making sure all so if we do get that case and we can get that case where two people Two transactions are verified which are wrong Then there's quite a simple way to To remove one of them. So instead of talking about verifying transactions now we'll talk about verifying blocks of transactions a group at a time and that will move to Here I will just introduce it then have a break So now verifying transactions we group transactions into a block and To verify that group of transactions they create a block and they must prove that they did some Some effort they spent some effort to Verify that And the basic way to do that is to get them to do some calculations that take time on computers And we'll see that the system in bitcoin is set up that the creation or the verification of an individual block takes about 10 minutes What takes 10 minutes on your computer? Well, we'll see that we can Make calculation of hash values to take time and set the problem such that On average it would take about 10 minutes. It doesn't matter how fast the computer is We'll set a problem such that it takes about 10 minutes to solve that problem And the idea is that it takes 10 minutes of fast processing the idea that One person will create if we have two different groups trying to verify different transactions one of them will win One of them will verify this transaction first Then they'll tell the others saying we just verified this transaction. So coming back to this case Steve had two transactions trying to double spend his money This group is trying to verify one of his transactions. This group trying to verify the other It takes time to do that Turns out by luck or these people have faster computers. They verify one of them first Once they verify they tell everyone it's verified This group who was trying to verify the second one Ah, they realized one was previously verified therefore they stopped working on this one because they see it's wrong so So we introduced this timing in there And it turns out in practice even with delays across the internet in practice There are very very few cases when Two groups of transactions are verified at the same time Okay Because the the verification requires some computational effort And it turns out in most cases If two groups of people are working on verifying different sets of transactions one of them will get there first And tell the others and the others will stop So that introduces this ordering into the system It's possible in theory that they both finish at the same time But even then the next case of verifying transactions will identify and reject one of them Let's stop for five five minutes answer any questions