1 00:00:02,730 --> 00:00:07,140 So, we've been talking about the ability for participants to publish a transaction 2 00:00:07,140 --> 00:00:11,100 and get it into the blockchain as if this happens by magic. 3 00:00:11,100 --> 00:00:13,340 Of course, it doesn't happen by magic in the real world, 4 00:00:13,340 --> 00:00:14,920 it happens through the Bitcoin network. 5 00:00:16,580 --> 00:00:18,331 So what is a Bitcoin network? 6 00:00:18,331 --> 00:00:22,353 It's a peer-to-peer network, so it inherits a lot of ideas from peer-to-peer 7 00:00:22,353 --> 00:00:25,545 networks that've been proposed for all sorts of other purposes, 8 00:00:25,545 --> 00:00:28,930 it's a peer-to-peer network where all nodes are equal. 9 00:00:28,930 --> 00:00:32,070 There's no hierarchy, there's no centralized special nodes, 10 00:00:32,070 --> 00:00:37,540 no master nodes, every node on Bitcoin is an equal peer. 11 00:00:37,540 --> 00:00:41,870 It runs over TCP, it has a random topology, so there's random nodes that 12 00:00:41,870 --> 00:00:46,690 appear with random other nodes, and new nodes can come at any time. 13 00:00:46,690 --> 00:00:49,450 So you can download the Bitcoin client today, 14 00:00:49,450 --> 00:00:53,890 you can spin your computer up as a node, and you'll be a participating Bitcoin 15 00:00:53,890 --> 00:00:58,779 node with equal rights and capabilities as every other node on the Bitcoin network. 16 00:01:00,850 --> 00:01:02,280 Now the network is very dynamic, 17 00:01:02,280 --> 00:01:05,550 it changes over time, nodes are coming and going all the time, 18 00:01:05,550 --> 00:01:08,960 although there's actually no explicit way to leave the network. 19 00:01:08,960 --> 00:01:11,250 Instead, if you don't hear from a node for a while, 20 00:01:11,250 --> 00:01:16,500 three hours is the amount that's hardcoded into the common clients, 21 00:01:16,500 --> 00:01:20,730 people eventually start to forget you, so it gracefully handles nodes going offline. 22 00:01:24,450 --> 00:01:27,618 So, what does that mean that you can simply join the Bitcoin peer-to-peer 23 00:01:27,618 --> 00:01:28,520 network at any time? 24 00:01:30,150 --> 00:01:33,240 Well, if this is a picture of the network at one moment in time, 25 00:01:33,240 --> 00:01:36,510 obviously scaled down quite a bit with just 7 nodes, but 26 00:01:36,510 --> 00:01:38,335 this is a picture of what it might look like. 27 00:01:38,335 --> 00:01:42,190 7 nodes with all random connections to each other, and 28 00:01:42,190 --> 00:01:45,810 notice that the numbers are scattered around here because there's no geographic 29 00:01:45,810 --> 00:01:50,430 topology here, networks connect to other nodes in a random fashion by design. 30 00:01:53,020 --> 00:01:55,790 Now, if you launch a new node, and say you want to join the network 31 00:01:56,910 --> 00:02:01,150 you start with a simple message to one node that you know about, so 32 00:02:01,150 --> 00:02:04,610 all you need to know is how to get to one node that's already on the network. 33 00:02:04,610 --> 00:02:08,300 This is usually called your seed node, and there's a few different ways you can look 34 00:02:08,300 --> 00:02:10,600 up lists of seed nodes to try connecting to. 35 00:02:10,600 --> 00:02:13,800 But you find your seed node and 36 00:02:13,800 --> 00:02:18,320 you sent a special message saying tell me all the peers that you have, 37 00:02:18,320 --> 00:02:21,560 tell me the addresses of all the other nodes in the network that you know about. 38 00:02:23,330 --> 00:02:26,790 And that node will respond and say, well I'm peered with nodes 1 and 39 00:02:26,790 --> 00:02:31,308 7, you can try them, and then you might go talk to 1 and 40 00:02:31,308 --> 00:02:34,400 7 and say, hey tell me everybody on the network that you know about. 41 00:02:34,400 --> 00:02:40,180 And they'll send you the nodes that they know about and you can iterate 42 00:02:40,180 --> 00:02:43,909 as many times as you want until you have a list of peers to make connections with. 43 00:02:45,680 --> 00:02:48,020 And then you can choose which ones to peer with, and 44 00:02:48,020 --> 00:02:50,530 you'll be a fully functioning member of the Bitcoin network. 45 00:02:52,320 --> 00:02:55,340 And again there's a few steps of randomness here, so depending on which 46 00:02:55,340 --> 00:02:59,450 seed node you used or which of the peers of the seed node you decided to go and 47 00:02:59,450 --> 00:03:03,800 talk to, you'll end up with a random set of nodes that you're connected to, but 48 00:03:03,800 --> 00:03:04,850 that's perfectly fine. 49 00:03:07,326 --> 00:03:10,150 So now that you're a member of the network, what is the network good for? 50 00:03:11,660 --> 00:03:14,260 Well, the network maintains the blockchain, so 51 00:03:14,260 --> 00:03:17,610 if you want to publish a transaction you want to get the entire network to 52 00:03:17,610 --> 00:03:21,480 hear about it, and there's a simple flooding algorithm to make this happen. 53 00:03:22,850 --> 00:03:27,860 So let's say that Node 4 here, hears about a new transaction, so Alice wants to pay 54 00:03:27,860 --> 00:03:33,400 Bob some money, Alice creates a Bitcoin transaction and submits it to Node 4, 55 00:03:33,400 --> 00:03:38,210 or maybe her wallet software or her exchange does that on her behalf. 56 00:03:38,210 --> 00:03:43,260 But somehow this transaction gets to Node 4, now node 4 says great 57 00:03:43,260 --> 00:03:47,980 I've got a new transaction and Alice wants to pay Bob, let's tell everybody about it, 58 00:03:47,980 --> 00:03:51,830 sometimes this is called a gossip protocol because it's very simple. 59 00:03:51,830 --> 00:03:55,970 If you have news you try to tell as many people as you can and they try to tell 60 00:03:55,970 --> 00:03:59,930 as many people as they can, much like people gossiping in the real world. 61 00:04:02,010 --> 00:04:06,770 Great, so node 4 is going to talk to his neighbors node 3 and node 2 and 62 00:04:06,770 --> 00:04:11,960 say hey, check out this new transaction Alice wants to pay Bob, and 63 00:04:11,960 --> 00:04:15,030 those nodes will add it to their own pool of pending transactions. 64 00:04:15,030 --> 00:04:18,960 So, each node maintains a list of all the transactions they've heard about that 65 00:04:18,960 --> 00:04:22,090 haven't been put into the blockchain yet, and 66 00:04:22,090 --> 00:04:25,050 then they can decide to forward that onto other nodes. 67 00:04:25,050 --> 00:04:28,770 So 3 is going to talk to its neighbors and say, new transaction for 68 00:04:28,770 --> 00:04:33,530 you Alice wants to pay Bob, that'll end up in their transaction pools and so on. 69 00:04:35,510 --> 00:04:39,090 And we want to make sure that this process doesn't go on forever, so 70 00:04:39,090 --> 00:04:43,470 let's say that node 2 comes along later and tries to tell node 7, Hey, 71 00:04:43,470 --> 00:04:48,220 new transaction Alice wants to pay Bob, node 7 is going to say, 72 00:04:48,220 --> 00:04:50,240 That's all right node 2 I've already heard about that, 73 00:04:50,240 --> 00:04:54,370 I already got it in my memory pool I don't need to forward it further. 74 00:04:54,370 --> 00:04:57,980 So eventually, this thing has to stop, because every node will have heard about 75 00:04:57,980 --> 00:05:00,960 the new transaction and they won't forward it anymore. 76 00:05:00,960 --> 00:05:05,230 And remember, every transaction is identified uniquely by its hash, so 77 00:05:05,230 --> 00:05:08,080 each node can tell they've seen that hash before and that they don't need to 78 00:05:08,080 --> 00:05:12,020 keep forwarding that transaction, so it won't loop around the network forever. 79 00:05:13,610 --> 00:05:16,670 So how do nodes decide when they hear about a new transaction, whether or 80 00:05:16,670 --> 00:05:18,350 not they should propagate it? 81 00:05:18,350 --> 00:05:22,080 The most important thing they do Is they check to see, 82 00:05:22,080 --> 00:05:26,840 given their view of the block chain, whether or not this transaction is valid. 83 00:05:26,840 --> 00:05:30,480 So they do all the transaction validation we talked about earlier, 84 00:05:30,480 --> 00:05:32,960 they run the script, they see that the script checks out, 85 00:05:32,960 --> 00:05:37,200 they see that the coins are being redeemed here haven't already been spent, and 86 00:05:37,200 --> 00:05:40,570 if all of that checks out, then this looks like a valid transaction. 87 00:05:40,570 --> 00:05:44,940 That they should try to relay, with a couple of other caveats, 88 00:05:44,940 --> 00:05:50,290 by default nodes won't relay the transaction if it's a non-standard script. 89 00:05:50,290 --> 00:05:54,810 If the script has any weird features, if it doesn't match a fairly simple whitelist 90 00:05:54,810 --> 00:05:58,540 of scripts that nodes know about, even though it's a valid transaction, 91 00:05:58,540 --> 00:06:00,340 the nodes won't relay it. 92 00:06:00,340 --> 00:06:03,110 They'll also make sure that they haven't seen the transaction before, 93 00:06:03,110 --> 00:06:07,950 that's that condition to avoid infinite loops, and there's another property, which 94 00:06:07,950 --> 00:06:11,830 is that they won't relay the transaction if it looks like a double spend. 95 00:06:13,250 --> 00:06:17,100 So if they've seen a transaction where Alice tries to send some specific coins to 96 00:06:17,100 --> 00:06:22,460 Bob and then later they see a second transaction where Alice tries to send 97 00:06:22,460 --> 00:06:27,960 those same coins to Charlie, the node shouldn't relay the second transaction. 98 00:06:27,960 --> 00:06:31,290 Even though either transaction could be valid because those coins still haven't 99 00:06:31,290 --> 00:06:36,070 been spent, they'll only relay the first one they hear and 100 00:06:36,070 --> 00:06:38,230 that's an extra guard against double spending. 101 00:06:39,330 --> 00:06:41,640 But it's important to keep in mind 102 00:06:41,640 --> 00:06:44,990 that all of these checks are just sanity checks. 103 00:06:44,990 --> 00:06:46,635 So well behaving nodes, 104 00:06:46,635 --> 00:06:51,360 all implement these to try to keep the network healthy and running properly, but 105 00:06:51,360 --> 00:06:56,330 there's no rule that says that nodes have to follow these specific steps. 106 00:06:56,330 --> 00:06:59,470 So since it's a peer-to-peer network and anybody can join, 107 00:06:59,470 --> 00:07:03,670 there is always the possibility of a node not following this exact protocol, 108 00:07:03,670 --> 00:07:07,480 forwarding double spends, forwarding transactions that aren't standard, 109 00:07:07,480 --> 00:07:09,200 forwarding transactions that aren't valid. 110 00:07:09,200 --> 00:07:14,010 And that's why it's important that every node do the checking for itself. 111 00:07:14,010 --> 00:07:16,940 So it's possible that nodes will end up with a different view 112 00:07:16,940 --> 00:07:20,270 of the pending transaction pool based on what they've seen. 113 00:07:20,270 --> 00:07:22,920 So let's go back to this example where 114 00:07:22,920 --> 00:07:26,580 Node 4 originally relayed a transaction where Alice was trying to pay Bob. 115 00:07:26,580 --> 00:07:31,640 And let's say that this transaction hasn't yet flooded to the entire network. 116 00:07:31,640 --> 00:07:35,890 And before it gets to everybody node 1 is going to announce a new transaction and 117 00:07:35,890 --> 00:07:39,430 say hey, I just heard Alice is trying to pay Charlie. 118 00:07:39,430 --> 00:07:42,920 Now, from Node 1's perspective, this is a valid transaction, and 119 00:07:42,920 --> 00:07:46,690 they haven't seen the other transaction where Alice is trying to pay Bob. 120 00:07:48,426 --> 00:07:51,210 So, Node 1 is going to implement the protocol normally, and 121 00:07:51,210 --> 00:07:53,589 is going to tell all of her neighbors about it. 122 00:07:56,460 --> 00:07:59,760 Now the neighbors that haven't heard the conflicting transaction yet 123 00:07:59,760 --> 00:08:01,490 will add it to their transaction pool. 124 00:08:02,580 --> 00:08:05,480 Whereas other neighbors, like Node 6 in this example, 125 00:08:05,480 --> 00:08:09,630 they've already received a transaction where Alice is trying to pay Bob, so Node 126 00:08:09,630 --> 00:08:13,320 6 is going to say I don't want to hold two conflicting transactions in my pool, 127 00:08:13,320 --> 00:08:15,410 I'll just keep the one I already have. 128 00:08:17,100 --> 00:08:21,190 The network may end up in divided state here where different nodes 129 00:08:21,190 --> 00:08:25,190 have a different view of what the pending transaction pool is but that's fine. 130 00:08:25,190 --> 00:08:28,360 These transactions haven't been published in the blockchain yet so 131 00:08:28,360 --> 00:08:31,610 this is just a temporary state where nodes disagree 132 00:08:31,610 --> 00:08:34,050 on which transactions should be put into the next block. 133 00:08:35,310 --> 00:08:37,930 In practice, this is a race condition. 134 00:08:37,930 --> 00:08:41,370 If nodes have a different perspective on which transactions are pending or 135 00:08:41,370 --> 00:08:45,880 which blocks have been accepted, that's okay in a temporary state, and 136 00:08:45,880 --> 00:08:47,170 eventually they'll sort it out. 137 00:08:48,310 --> 00:08:52,340 So in the case of transactions, if different nodes have a different view of 138 00:08:52,340 --> 00:08:57,010 the pending transaction pool, depending on who mines the next block, 139 00:08:57,010 --> 00:09:01,470 they'll essentially break the tie, or the race condition, and decide which of those 140 00:09:01,470 --> 00:09:05,970 two pending transactions should end up being put permanently into a block. 141 00:09:05,970 --> 00:09:09,670 And once one of those two transactions has been put into a block, 142 00:09:09,670 --> 00:09:14,000 other nodes will see that the transaction that they're holding onto in their pool 143 00:09:14,000 --> 00:09:18,250 Is now never going to make it into a block because it would be a double spend and 144 00:09:18,250 --> 00:09:19,180 they'll just drop it. 145 00:09:20,480 --> 00:09:24,330 So if the transaction where Alice tried to pay Bob, successfully makes it into 146 00:09:24,330 --> 00:09:28,050 a block first, the nodes who heard the transaction where Alice tried to pay 147 00:09:28,050 --> 00:09:33,300 Charlie will just say that's not a valid transaction anymore so I can forget it. 148 00:09:33,300 --> 00:09:38,450 So the default behavior is for nodes to just hang on to whatever they hear first, 149 00:09:39,850 --> 00:09:42,380 which means that network position matters. 150 00:09:42,380 --> 00:09:46,740 If two conflicting transactions or two conflicting blocks get announced at two 151 00:09:46,740 --> 00:09:51,410 different positions in the network, they'll both flood in opposite directions. 152 00:09:51,410 --> 00:09:54,570 And the nodes which end up with one transaction or 153 00:09:54,570 --> 00:09:59,180 the other will depend on which side of the network they started out closer to. 154 00:10:01,130 --> 00:10:04,890 Of course this assumes that every minor implements this logic where they keep 155 00:10:04,890 --> 00:10:09,990 whatever they hear first, but there's no central authority enforcing this, so 156 00:10:09,990 --> 00:10:13,970 every node is free to do whatever logic they want. 157 00:10:13,970 --> 00:10:19,560 So if for some reason, if anyone wants to, they can choose to implement any 158 00:10:19,560 --> 00:10:24,850 other logic they want for choosing which blocks or which transactions to forward. 159 00:10:24,850 --> 00:10:27,340 We'll talk about that more in our lecture on mining, 160 00:10:27,340 --> 00:10:31,330 why miners want to implement some different logic other than the default. 161 00:10:33,530 --> 00:10:36,320 Now I've been talking mostly about transactions here. 162 00:10:36,320 --> 00:10:40,720 The logic for announcing new blocks, whenever minors find a new block, 163 00:10:40,720 --> 00:10:44,140 is almost exactly the same as propagating a new transaction. 164 00:10:44,140 --> 00:10:48,060 So the same algorithm is used to announce new blocks around the network, 165 00:10:48,060 --> 00:10:52,340 it's the same flooding algorithm, the same gossip process. 166 00:10:52,340 --> 00:10:55,960 And in this case, instead of verifying that the transaction is valid by running 167 00:10:55,960 --> 00:11:00,110 a script, the nodes are going to verify that the new block is valid by computing 168 00:11:00,110 --> 00:11:04,440 the hash, and making sure that it starts with a sufficient number of zeroes 169 00:11:04,440 --> 00:11:05,690 to meet the difficulty target. 170 00:11:07,510 --> 00:11:11,060 Now validating a block is also much more in-depth. 171 00:11:11,060 --> 00:11:15,670 Because in addition to validating the header and seeing that the hash value is 172 00:11:15,670 --> 00:11:20,860 correct, nodes are asked to validate every transaction included in the block 173 00:11:20,860 --> 00:11:24,010 to make sure that the block contains only valid, new transactions. 174 00:11:26,730 --> 00:11:30,290 And the other check, which is this really important, critical part and 175 00:11:30,290 --> 00:11:34,230 that makes Bitcoin consensus what it is, is that nodes shouldn't 176 00:11:34,230 --> 00:11:39,290 forward a block unless it builds on their perspective of the current longest chain. 177 00:11:39,290 --> 00:11:40,960 So they have a view of the blockchain, and 178 00:11:40,960 --> 00:11:44,660 they should only forward new blocks if they come at the very end of the chain, 179 00:11:44,660 --> 00:11:49,500 not at some earlier point, and this avoids forks building up. 180 00:11:49,500 --> 00:11:53,450 So just like with transactions, nodes can implement different logic if they want, 181 00:11:53,450 --> 00:11:57,570 they're free to relay blocks that aren't valid or 182 00:11:57,570 --> 00:12:01,210 to relay blocks that build off of an earlier point in the block chain. 183 00:12:01,210 --> 00:12:04,280 So some nodes may be trying to relay a block that 184 00:12:04,280 --> 00:12:08,870 doesn't extend the current longest chain that actually builds a fork and 185 00:12:08,870 --> 00:12:12,180 that's okay, the protocol is designed to withstand that. 186 00:12:12,180 --> 00:12:14,720 So how long does this flooding algorithm actually take? 187 00:12:14,720 --> 00:12:16,400 How much latency is imposed here? 188 00:12:17,470 --> 00:12:19,660 This is a graph showing the average time for 189 00:12:19,660 --> 00:12:22,470 new blocks to propagate to every node in the network. 190 00:12:22,470 --> 00:12:27,860 And the three lines show the 25th, the 50th, and the 75th percentile. 191 00:12:27,860 --> 00:12:32,070 Of how long it takes for a new block to reach every node in the network. 192 00:12:32,070 --> 00:12:37,720 And if you look at the 75th percentile there for some of the larger blocks, and 193 00:12:37,720 --> 00:12:42,310 this is heavily dependent on size, because the bandwidth constraints that some nodes 194 00:12:42,310 --> 00:12:48,070 have, you'll see that the average propagation time is over 30 seconds. 195 00:12:48,070 --> 00:12:51,730 So this shows that this isn't a particularly efficient protocol. 196 00:12:51,730 --> 00:12:54,320 On the Internet, 30 seconds is a pretty long time for 197 00:12:54,320 --> 00:12:55,510 people to hear about something. 198 00:12:56,610 --> 00:13:00,920 The reason it takes so long is because the protocol is not very efficient, 199 00:13:00,920 --> 00:13:04,780 it wasn't designed to be efficient, it was designed to be simple and to have no 200 00:13:04,780 --> 00:13:09,020 structure, so that every node is equal and that they can come and go at every time. 201 00:13:09,020 --> 00:13:13,840 And as a result the topology may not be optimized for fast communication. 202 00:13:13,840 --> 00:13:17,590 A block may need to go through many nodes before it reaches some of the most distant 203 00:13:17,590 --> 00:13:19,330 nodes in the network. 204 00:13:19,330 --> 00:13:22,020 Whereas if you designed a network top down for efficiency, 205 00:13:22,020 --> 00:13:28,170 you would design it to make sure that the path between any two nodes was very short. 206 00:13:28,170 --> 00:13:31,870 For BitCoin, it's more important to have a decentralized structure where all nodes 207 00:13:31,870 --> 00:13:33,000 are equal, 208 00:13:33,000 --> 00:13:38,610 even if that means that the propagation time can be over 30 seconds in some cases. 209 00:13:38,610 --> 00:13:40,830 So how big is a BitCoin network? 210 00:13:40,830 --> 00:13:43,860 Well, there's no official statistics anywhere, because again, 211 00:13:43,860 --> 00:13:47,270 there's no central authority overseeing it, it's simply whatever the nodes 212 00:13:47,270 --> 00:13:50,610 participating they are the Bitcoin network. 213 00:13:50,610 --> 00:13:54,570 So it's impossible to measure exactly, and it's changing all the time, but 214 00:13:54,570 --> 00:13:58,270 a number of researchers that looked into this and tried to come up with estimates. 215 00:13:59,320 --> 00:14:03,030 On the high end, some researchers have said that over a million IP addresses in 216 00:14:03,030 --> 00:14:06,940 a given month will at some point be running the Bitcoin protocol and 217 00:14:06,940 --> 00:14:09,400 acting at least temporarily as a Bitcoin node. 218 00:14:10,920 --> 00:14:14,340 But if you look at full nodes that are actually permanently connected, and 219 00:14:14,340 --> 00:14:18,550 are fully validating every transaction they hear and running the full protocol, 220 00:14:19,570 --> 00:14:23,520 it's only about five or ten thousand, which may be a surprisingly low number. 221 00:14:25,030 --> 00:14:28,680 And in fact, that number may be dropping, there's no evidence that the number of 222 00:14:28,680 --> 00:14:32,645 fully validating nodes is going up, and there's some concern that the number of 223 00:14:32,645 --> 00:14:34,870 fully-validating nodes is actually going down. 224 00:14:37,000 --> 00:14:41,750 So to be a fully-validating node, you want to stay permanently connected so 225 00:14:41,750 --> 00:14:43,240 that you hear about all data. 226 00:14:43,240 --> 00:14:45,960 The longer you're offline the more catchup you're going to have to do to 227 00:14:45,960 --> 00:14:49,080 hear about all the transactions you missed, and 228 00:14:49,080 --> 00:14:52,790 you're going to have to store the entire blockchain. 229 00:14:52,790 --> 00:14:55,170 You'll also need a pretty active network connection so 230 00:14:55,170 --> 00:14:58,430 that you can hear every new transaction and forward it to your peers. 231 00:14:59,830 --> 00:15:03,800 So you can see the growth over time here, and 232 00:15:03,800 --> 00:15:07,110 currently it takes about 20 gigabytes to store the entire block chain. 233 00:15:08,880 --> 00:15:12,330 Which isn't too bad if you have a few years old PC with an active 234 00:15:12,330 --> 00:15:16,540 network connection, you have what it takes to be a fully validating node. 235 00:15:16,540 --> 00:15:19,620 Although you basically need to dedicate that machine to doing that and 236 00:15:19,620 --> 00:15:20,450 not much else. 237 00:15:21,470 --> 00:15:26,790 Fully validating nodes maintain the entire set of Unspent Transaction Outputs. 238 00:15:28,710 --> 00:15:33,070 So every coin that's available to be spent, and remember those are just unspent 239 00:15:33,070 --> 00:15:39,620 output transactions, ideally you'd like to store this in ram so that when you hear 240 00:15:39,620 --> 00:15:44,060 a new proposed transaction on the network you can quickly check the transaction that 241 00:15:44,060 --> 00:15:48,990 it's attempting to claim, run the script and see if the signature is valid. 242 00:15:50,050 --> 00:15:53,090 So currently there are about twelve million unspent transactions and 243 00:15:53,090 --> 00:15:56,460 that's out of 44 million transactions that have ever been proposed. 244 00:15:57,640 --> 00:16:02,000 So, fortunately that's still small enough to fit in less than a gigabyte of ram, 245 00:16:02,000 --> 00:16:03,680 in an efficient data structure. 246 00:16:03,680 --> 00:16:06,740 So that if you are running the fully validating node 247 00:16:06,740 --> 00:16:08,860 every time you hear about a new transaction, 248 00:16:08,860 --> 00:16:12,780 you can quickly check, run the redemption script and see that this is 249 00:16:12,780 --> 00:16:16,400 a valid transaction that you should put in your pending transaction pool. 250 00:16:18,650 --> 00:16:24,190 So in contrast to being a fully validating node, there are lightweight nodes, 251 00:16:24,190 --> 00:16:27,919 also called thin clients or simple payment verification clients. 252 00:16:29,840 --> 00:16:33,480 This is actually the vast majority of nodes on the BitCoin network, and 253 00:16:33,480 --> 00:16:36,785 the difference here is that these nodes aren't attempting to store the entire 254 00:16:36,785 --> 00:16:38,670 blockchain. 255 00:16:38,670 --> 00:16:42,810 They only store the pieces that they need to verify some specific transactions that 256 00:16:42,810 --> 00:16:43,470 they care about. 257 00:16:44,780 --> 00:16:48,810 So for example if you run a wallet, your wallet might want to be a simple payment 258 00:16:48,810 --> 00:16:54,100 verification node, and if somebody sends money to you, you'll act as a node. 259 00:16:54,100 --> 00:16:56,990 You'll download the bits of the blockchain that you need to 260 00:16:56,990 --> 00:17:00,350 verify that the person sending you the money actually owned it and 261 00:17:00,350 --> 00:17:05,030 that the transaction sending it to you actually gets included in the block chain. 262 00:17:05,030 --> 00:17:08,010 You won't care about the thousands of other transactions going on 263 00:17:08,010 --> 00:17:09,030 that don't affect you. 264 00:17:10,140 --> 00:17:12,590 Now an SPV client like this 265 00:17:12,590 --> 00:17:16,150 won't have the full security level of being a fully validating node. 266 00:17:17,450 --> 00:17:19,700 And the reason is that when they hear a new block, 267 00:17:19,700 --> 00:17:22,290 the only thing they can check is the block header. 268 00:17:22,290 --> 00:17:26,660 They can check to see that the block was difficult to mine, but they can't check to 269 00:17:26,660 --> 00:17:30,410 see that every transaction included in that block is actually valid. 270 00:17:30,410 --> 00:17:33,630 Because they don't have the entire previous blockchain, 271 00:17:33,630 --> 00:17:37,220 they don't know the entire unspent transaction output set. 272 00:17:37,220 --> 00:17:40,350 They can only validate the transactions that actually affect them. 273 00:17:41,630 --> 00:17:45,810 So, they're essentially trusting the fully validating nodes to have 274 00:17:45,810 --> 00:17:49,220 validated all the other transactions that are out there. 275 00:17:49,220 --> 00:17:52,492 So, this isn't a bad security trade off, you're assuming there are fully 276 00:17:52,492 --> 00:17:55,620 validating nodes out there that are doing the hard work. 277 00:17:55,620 --> 00:17:59,010 And then if miners went through the trouble to mine this block, 278 00:17:59,010 --> 00:18:03,260 which is a really expensive process, they probably also did some validation 279 00:18:03,260 --> 00:18:05,300 to make sure that this block wouldn't be rejected. 280 00:18:05,300 --> 00:18:09,999 And the cost savings of being an SPV node are huge. 281 00:18:11,310 --> 00:18:15,110 It's about a thousand times smaller to just store block headers than to store 282 00:18:15,110 --> 00:18:17,670 all of the previous transactions. 283 00:18:17,670 --> 00:18:22,820 Instead of storing about 20 gigabytes of data, you're down to about 20 megabytes. 284 00:18:22,820 --> 00:18:27,167 Which is something that almost anybody on a PC or even on a phone can store and 285 00:18:27,167 --> 00:18:29,792 act as a limited node in the BitCoin network.