BT Babel Tube

aantonop

Consensus Algorithms, Blockchain Technology and Bitcoin UCL - by Andreas M. Antonopoulos

YouTube

Transcript context

What this page provides

This page pairs the original YouTube source with a readable transcript, timestamp controls, available language tracks, and topic metadata so the talk can be reviewed as reference material.

Tracks
2
Current cues
647
Topics
Uncategorized

Source video

Consensus Algorithms, Blockchain Technology and Bitcoin UCL - by Andreas M. Antonopoulos

The interactive player loads when JavaScript is available. The transcript below is included in the initial HTML for reading and search indexing.

en transcript

2094 source cues

  1. So, this is This is great. It's back to my roots.
  2. Um I I was a student here in 1990.
  3. Um but I was actually born in London.
  4. And I'm half British, which you won't hear in my accent anymore. Um Brooklyn changed that.
  5. The first day I arrived at UCL, I was telling my mom, "Um I'm going to be doing my orientation session at the University College Hospital, which is across the street.
  6. They have a big auditorium, and that's where they're sending all the students."
  7. And she said, "Well, just be careful, cuz last time you were there, someone assaulted you with forceps."
  8. Um turns out I was born at UCL.
  9. And then ended up going to college at UCL, and I had no idea.
  10. So, um this is this is really a a fantastic um honor for me, and I I'm truly very happy to be here and and be doing this at UCL.
  11. All right. So, today's presentation is about the consensus mechanism of Bitcoin. And we're going to go into uh whatever technical depth is appropriate
  12. for the audience. So, I need to get an idea.
  13. Uh how many people here are programmers or have a computer science background?
  14. Very good. How many people are completely new to Bitcoin?
  15. Okay. And oh, there's an overlap there.
  16. Very interesting. Excellent. All right.
  17. So, we're going to keep it quite technical.
  18. Um Bitcoin is a system that that is made up of a network protocol, some core cryptographic functions, and a set of uh
  19. game-theoretical equilibrium systems that dynamically adjust, which basically means there's some economics happening on a global scale. And these economics influence the operation of the network protocol. What we're going to talk about
  20. today is the invention that lies at the center of Bitcoin.
  21. Like many technologies, Bitcoin isn't entirely novel.
  22. In fact, uh the core idea in Bitcoin is to take five or six technologies that existed in the '70s, '80s, and '90s, and mash them together to create something
  23. completely new. All of the constituent components in Bitcoin existed about 15 years before Bitcoin actually showed up.
  24. Uh but no one had combined them in this particular way.
  25. So, what's really novel about Bitcoin is its architecture and the design characteristics that make it work. Think of it as a recipe. All of the
  26. ingredients were there, but no one had ever thought of combining them in this particular way.
  27. One of the most important components of Bitcoin um is the use of cryptographic hash functions, specifically SHA-256. So, how many people here are familiar with hash functions?
  28. At least understand a basic Okay, great.
  29. I apologize in advance for my handwriting.
  30. I type fast.
  31. I write horribly.
  32. Um SHA-256 is an algorithm that uh takes an input, and this can be an input of any size. Um any form of data as input.
  33. And then it mixes it up. And it produces a fixed-size output, which is uh 256-bit long. So, you can just take
  34. data in here, and it will always produce uh 256 bits hash, as it's called.
  35. A useful way to think of this is as a fingerprint for the data. Now, when you put data into SHA-256, you you have no way of predicting what's going to come out.
  36. And what does come out looks random.
  37. If you do any kind of statistical test on the output of SHA-256, it will appear random. However, it's deterministic. Meaning that if you put the same thing in the top, you get
  38. the same thing out the bottom, always.
  39. Which means that if you have this fingerprint and someone gives you a piece of data, you can put the data in, verify the fingerprint, and you know that they applied SHA-256 to it.
  40. So, it can be used to prove uh a certain data set.
  41. This particular technology, in 1997, Adam Back created a system for anti-spam called Hashcash.
  42. And he said, "Well, a lot of people are sending spam, so how about we use this function to make them do some work, so that before they can post uh a message on
  43. this message board, they have to do a few hundred thousand SHA operations in a row.
  44. And then at the end of that, you produce a fingerprint. Now, it's fairly easy then for someone to check that uh for a specific value. And if they check it, they know that the other
  45. person has done the work.
  46. As a result, what that means is that if you want to post a message on the message board, you have to do maybe half a second of computing before you post a message. Now, if you're a legitimate user of this message
  47. board, half a second of computing is nothing.
  48. If you're a spammer and you want to send a million messages, half a second of computing means you have to do half a million seconds to send a million messages, and suddenly it changes the economics.
  49. This mechanism is called proof of work.
  50. And what Satoshi Nakamoto did was to use this proof of work mechanism in order to establish consensus on a global decentralized network.
  51. And so, this is at the core of Bitcoin.
  52. This invention, SHA-256 has existed for decades. Hashcash had existed since 1997.
  53. Uh what Satoshi Nakamoto did was combine this with a peer-to-peer network that operates very similar to how BitTorrent operates or many other peer-to-peer networks, uh to create a digital cash system.
  54. So, let's say you have a 256-bit fingerprint. You put data in, something comes out. It's seemingly random, but deterministic. What are the chances the first bit is going to be zero?
  55. Anyone?
  56. 50% Right?
  57. So, half the hashes that are going to come out of this will have the first bit as zero. What are the chances the first two bits are zero?
  58. 25% What are the chances the first 10 bits are zero?
  59. Right? So, it gets exponentially more difficult as you increase the number of zeros in the front. So, if I say I want you to generate a random number using SHA-256 by putting some inputs
  60. into it, and the criteria I have, rather bizarre criteria if you think about it, is I want you to produce a random number, but I want that random number to have a certain
  61. pattern to it. And the pattern is it has to have zero bits at the beginning of the number.
  62. In numeric numerical terms, you can describe this as the number has to be smaller than a certain value. Right?
  63. So, effectively, if you say the first bit is zero, has to be zero, what you're saying is that the number has to be less than 255 minus one. Right?
  64. If you say the first two bits have to be zero, you're saying the number has to be less than two to the 254, etc. Right?
  65. So, what I'm saying is generate a seemingly random number that is smaller than a specific value. That value is called the target.
  66. Specifically in Bitcoin, we call it the difficulty target, because the lower that value is, the harder it is to find one of these numbers.
  67. Now, how do you find one of these numbers?
  68. Let's take a typical example. SHA-256 is often used to fingerprint documents. So, you can create um a fingerprint that allows you to verify that a document hasn't been modified.
  69. Typical example of that, let's say you signed a contract with someone. You take the PDF, you throw it through SHA-256, you get a fingerprint. Now, if the any PDF that matches that fingerprint, that produces that same fingerprint, is
  70. the exact same PDF that you originally had. And you can verify that. If you want to download software from a website, and that software is extremely sensitive, security-sensitive code, you'll often see at the bottom of the
  71. website, it will say, "Verify that the software package you download has this fingerprint." And you can know that not a single bit in that software has changed.
  72. This is due to a characteristic of SHA-256, um which is that the output changes dramatically even if you change just one bit.
  73. So, this is a cascade effect. You change one bit in the input, what you get out is not just one bit different.
  74. It is in a completely different part of the 256-bit space.
  75. So, you never know where you're going to land.
  76. So, let's take a simple example.
  77. I take this phrase, "Hello!" exclamation mark. Anybody who has a laptop can throw SHA-256 sum or SHA any Mac, any Unix-based system, any Windows-based system has that function
  78. in it. Type SHA and it it's going to give you a hash.
  79. You tell it to use the 256-bit algorithm. You type in capital H E L L O exclamation mark. It's going to give you a specific fingerprint.
  80. That fingerprint is specific to this phrase.
  81. You change the exclamation mark, you add a space, you change the first letter to a lowercase H, completely different fingerprint, right?
  82. But, as long as you enter the exact same phrase, the result will be a specific fingerprint. Anybody did that on their laptop?
  83. Okay, what's the result?
  84. Just give me the first few digits. A8D19 153 That's where the line breaks.
  85. Anyone in the world can take the phrase, "Hello!"
  86. exclamation mark, put it into SHA-256, and they will get A8D19153.
  87. So, how do I change that?
  88. Well, if I wanted to produce different fingerprints from this, I could introduce some change to the input. How about adding a number?
  89. So, I can take the same string, and instead add a number to it.
  90. Hello zero.
  91. And please help me out here, if you don't mind. Completely different. 0E0 978C 0E0978C It's
  92. uh 64 characters long.
  93. So, completely different output.
  94. And I can keep going. Hello one.
  95. No need to do it, but completely different output, right?
  96. Each time I do this, I'm going to get a different result. Now, uh you remember before I said I want my target to be let's say the target is that the first four bits are zero.
  97. Well, this one fulfills it.
  98. The first hexadecimal digit is zero, which means that this particular input produces a value less than the target.
  99. That was relatively easy to do, right?
  100. Because once again, the probability of finding a hash where the first hexadecimal digit is zero is not that not that low. I can just run a few iterations, and I'm going to get at least one value
  101. that's less than zero.
  102. Now, if I gave you if you gave me the string "Hello!"
  103. and you said, "Find me a specific random number or any number that you add to "Hello!" and when you add it, it produces a hash that starts with zeros."
  104. How do I find that number?
  105. I have to brute force it. I have to try every possible number. So, I would start "Hello zero, hello one, two, three, four, five, six, seven, eight" and just keep going in an in a loop as fast as I can in
  106. order to produce hashes.
  107. And at some point, a hash would pop out that would meet my difficulty target.
  108. And as soon as I have that hash, I can show it to you. And I can do two things.
  109. I can show you the hash, and I can show you the number. So, I can say, for example, "Hello 39,137 produces a hash that has two zeros in the beginning." I'm just guessing,
  110. right?
  111. If I do that, can you verify it?
  112. Well, of course, you could take "Hello 39,137" plug it into a hash, come out with a fingerprint, and if the first few digits are zero, you're like, "Oh, that is correct."
  113. What have I just proved?
  114. What I've proved is that I did several tens of thousands of SHA operations to find that.
  115. There is no way I can produce that result without doing the work. There is no way I can produce that result without searching through the space of fingerprints in a brute-force manner.
  116. And based on the difficulty, one bit zero 50%, two bit zero 25%, three bit zero 12%, four bit zero 6%, etc. etc. etc., you can
  117. estimate statistically simply from the pattern approximately how many operations I need to do on average before I find it.
  118. All right, who's got access to a blockchain right now and can look up the latest block? Anyone?
  119. Look up the block hash of the latest block.
  120. Quite a few zeros at the start. All right, let's Can you read me out the beginning?
  121. Uh let's see. 3 17 zeros.
  122. Followed by 5D165.
  123. This is the fingerprint of the current block in the blockchain.
  124. In order to produce this fingerprint, a miner used the header of the block, which is a known uh set of data.
  125. It represents all of the transactions that are in the block, the date and time, and a few other data sets. It's a standard data structure, right?
  126. Think of the header as the "Hello!"
  127. part.
  128. That's the useful payload, if you want, that we're trying to validate through proof of work.
  129. And then, in addition to the header, they introduced an a number, which we call a nonce, a random number. So, this is called
  130. the nonce.
  131. Now, if you take one look at this, what that means is that when you take that block's header and the specific nonce that was found by this miner, it produces this fingerprint.
  132. These are hexadecimal digits, 17 times four bits.
  133. So, uh so, 68 bits at the beginning of this hash. The first 68 bits are zero. What
  134. is the probability that the first 68 bits are zero?
  135. You can do the math.
  136. But, I can estimate approximately how many hashes that took.
  137. At the moment, the Bitcoin network is producing 500 petahashes per second.
  138. That is 500 quadrillion hashes per second.
  139. And it still takes on average 10 minutes to find a block.
  140. So, 500 petahashes times 10 minutes on average is how many hash operations the miner needed to do this.
  141. If I see this hash, I know that the only way a miner was able to find that very special nonce that produced this result. There is no
  142. way to shortcut this function. The only way they did it is by performing quadrillions upon quadrillions of hash operations. And in order to perform these quadrillions upon quadrillion hash
  143. operations, they had to use a very important precious resource, energy.
  144. So, laws of thermodynamics tell me that in order to run the SHA algorithm, you have to flip bits. To flip bits, you have to expend energy. Expending energy dissipates heat, and therefore, I know
  145. two things about this miner. One, they're running some serious hardware.
  146. Because they are able within a period of less than 10 minutes to do quadrillions of hashes. This hardware didn't exist three years ago.
  147. This hardware, I can tell you from the specs we see, is probably a 20-nanometer fabrication chip that is designed to do just SHA-256 and
  148. nothing else.
  149. And the way it works is by having hundreds of thousands of parallel SHA256 engines packed as densely as possible. These chips consume enormous power.
  150. You can heat your house with them.
  151. You can toast bread with them.
  152. And if you don't dissipate them, they will melt.
  153. And these chips consume electricity. In fact, you can estimate approximately how much electricity is consumed in terms of watts per gigahash.
  154. So, how many watts of electricity you consume to do a billion calculations of hashes?
  155. And that metric is the efficiency of this mining equipment.
  156. So, just by looking at this number, I know that the miner has expended enormous amounts of effort, which translates into enormous amounts of
  157. electricity and heat, which means that they had to pay someone to give them electricity, which means they incurred a financial cost. And this is really important.
  158. You will hear people say that Bitcoin wastes electricity. Bitcoin does not waste electricity. Bitcoin uses
  159. to underpin the security function because it creates an economic system whereby, in order to participate, you have to incur cost. By incurring cost,
  160. the only reason you would incur cost is for the possibility of reward.
  161. And the possibility of reward is determined by whether your block meets the consensus rules. Which means you spend money, and if you play fair by the rules, you
  162. get money back.
  163. If you spend money and you try to cheat, you don't get money back, which means you lose money.
  164. So, therefore, it doesn't pay to cheat.
  165. And that simple game theoretical equilibrium is the core of the Bitcoin consensus algorithm.
  166. So, every 10 minutes, a miner has to take a whole bunch of transactions, maybe a thousand transactions that are currently outstanding, unconfirmed, ready to be included in the blockchain.
  167. They have to then perform consensus rule validation, meaning they have to look at each one of these transactions and say, "Does it meet the rules?"
  168. The rules are the same for everyone.
  169. There's a list of maybe 30 or 40 rules that every transaction has to comply with, and there's a list of 30 or 40 rules that every block has to comply with.
  170. So, they must construct a block with transactions that match all of these rules.
  171. Because once they construct that block, they're then going to try and find the nonce that makes its header fingerprint look like this. And it's they're going to spend a lot of electricity trying to find that nonce.
  172. And if they then find that nonce and send it to the rest of the network, and the rest of the network says, "Sorry, doesn't meet the consensus rules."
  173. They just wasted all that electricity.
  174. So, they have to make sure that that block meets the rules, which means that every transaction in it meets the rules, which means that every transaction is properly signed, has never been spent before, is properly structured, the
  175. amount inside doesn't exceed the number of inputs, the outputs are properly formatted, it doesn't spend mining reward in less than 100 blocks, blah blah blah blah. There's a whole list of rules.
  176. And that way, you align the interest of the miner who's wasting electricity or using
  177. with validating the consensus rules.
  178. And in every block, the miner gets to write themselves a check.
  179. So, when a miner is constructing a block, the first transaction they put in that block is a transaction that pays them reward. It pays them 25 Bitcoins. And
  180. that is a unique transaction in Bitcoin because most transactions in Bitcoin, all transactions in Bitcoin have inputs and outputs. But the coinbase transaction, as it's known, the first one, has no inputs.
  181. So, what that means is it's writing a check from nowhere to myself for 25 Bitcoin.
  182. So, every miner will put a check in the beginning of the block that says, "Pay me out of thin air 25 Bitcoin." And that 25 Bitcoin is new, brand new, never existed before, and is created.
  183. So, here's a simple question.
  184. Why 25?
  185. Why doesn't the miner write themselves a check for 26 Bitcoin?
  186. Or 30 Bitcoin?
  187. Sorry?
  188. No, none of the other miners would agree to trust that. So, imagine a scenario where the miner gets greedy, and instead of writing uh check to themselves for 25 Bitcoin, they write a check for 26 Bitcoin.
  189. They construct the candidate block, they fill it with transactions, they put the first transaction to pay themselves 26 Bitcoin, and now they have the header, and now they have to search for this number, the nonce, and they do all of
  190. this work and they produce a hash.
  191. They find the proof of work. They then disseminate that block to all of the other miners.
  192. What do the other miners do? They validate the block consensus rules. And they look through, and one of the consensus rules is, "You can only pay yourself reward at the correct rate based on what block
  193. we're at." So, if it's 2009 to 2012 year, the first 800,000 blocks, 50.
  194. If it's now until approximately August 2016, 25.
  195. At a very specific moment on a specific block, that equation is going to produce a result of 12 and 1/2 shortly after approximately August 2016,
  196. uh when enough blocks have been mined.
  197. Sorry, it's after every 200,000 blocks.
  198. So, after 400,000 blocks have been mined, on the very next block, everyone will expect to see a reward of 12 and 1/2.
  199. And if you write your check yourself a check for 25 at that point, your block is going to be rejected.
  200. Okay, yes.
  201. Who sets the validation rules? This is the really good question. The validation rules are defined by the software, the reference implementation. So, if you want to know what the current validation rules are, you read the software code
  202. for the Bitcoin Core reference implementation. So, it's a C++ program that contains within it functions that do things like is block valid, is transaction valid, you know. And these
  203. functions evaluate things based on a simple set of rules. Now, um you might ask, "Where are these rules documented?" And the answer is nowhere.
  204. The rules are whatever the core implementation says the rules are. So, the rules are only documented in C++.
  205. In fact, this is one of the tricky parts of consensus. The rules are whatever the core implementation does, including the bugs, including every bug ever found since
  206. 2009.
  207. If you want to write a competing implementation, you have to simulate every bug that was found in the code since 2009, and process the blocks in exactly the same way because you have to reprocess them from the beginning until today,
  208. which means that you have to fail where Bitcoin Core failed, and succeed where Bitcoin Core succeeded, bugs and all. Yes.
  209. Who's definition of C++? Well, it's Yes. So, there is a So, with that software code comes a long list of very specific dependencies, dependencies on underlying database
  210. code, C++ versions, Boost, and various other libraries that are used. Um up to recently, OpenSSL libraries. Now, they've changed that a bit. So, yes, there is a whole edifice of dependencies
  211. that constitutes the reference code.
  212. Yes.
  213. Right. So, let's talk about that.
  214. All right.
  215. First of all, let's explain how the decision is made. Now, I've I've said until now that when miners receive a new block, they validate it by the rules, and then they decide if they're going to accept it.
  216. How do they decide? How do they vote?
  217. How is consensus actually affected on the network? And consensus is affected on the network based on um a decentralized mechanism of voting by means of the longest
  218. difficulty chain. Let me explain what I mean by that.
  219. So, the blockchain is a sequence of blocks.
  220. Each block within it contains the hash of the previous block.
  221. And the hash of the previous block is based on the header, which contains the hash of the previous block, which is based on the header, which contains the hash of the previous block.
  222. Which means that each block within it contains something that if it changed, would change its own hash, which would change the next block's hash, which would ripple all the way through the
  223. blockchain. And this all goes down back to the first block.
  224. So, in January 2009, Satoshi Nakamoto mined the first block.
  225. They did not use the Bitcoin consensus algorithm to mine this first block. They kind of jury-rigged it so that it would come out properly. Uh because there was no consensus mechanism at the time. The second block was mined based on
  226. consensus. The first block is actually embedded in every version of Bitcoin.
  227. So, every piece of software that implements the Bitcoin consensus algorithm has within it statically defined the Genesis block, including the Genesis blocks hash, its fingerprint.
  228. If you are looking at the Bitcoin blockchain and you have the Genesis block and you have its fingerprint, and someone gives you a block and says, "This is block number two."
  229. You can verify it because block number two contains a reference to the hash of the previous block, which is the Genesis block, and you have that as a constant in your code.
  230. And then you can verify that the second block was mined properly because its hash should contain a number of zeros in front, which means that the proof of work was done. And now you've validated the second block.
  231. If someone gives you the third block, you would then do the same process.
  232. You'd validate all the transactions within it. You'd validate that it links to the second block.
  233. And you would validate the third block.
  234. And if you do this process after three or four days, you're going to get to block 366,000.
  235. And then the network is going to tell you you already have the latest block. And And you've essentially rebuilt the entire chain from Genesis to today.
  236. And you can independently verify that every block you have is correctly linked to every previous block all the way back to the Genesis block, which means you have the authentic blockchain.
  237. This property is really important. This property means that in a distributed system, nodes can join and leave at will.
  238. And one of the important properties of Bitcoin is what happens when you turn your back.
  239. What happens when you leave the network, stop paying attention, and then you come back?
  240. You come back and the network tells you you're a thousand blocks behind.
  241. But, you can then retrieve each one of these blocks, rebuild them on top of what you knew to be the truth before, and arrive at the same truth as everybody else
  242. in a way that is completely irrefutable, that requires no appeal to authority, that can be verified independently by your node.
  243. So, the blocks essentially get built in this chain that references everything down to the past.
  244. So far, so good?
  245. All right. So, let's say I'm a block 366,000 and one.
  246. I validated that up to this block, I can link everything back to the Genesis block.
  247. As far as I know, this is the latest block on the network.
  248. And I'm connected to the network and somebody sends me a message that says, "I have block 366,002."
  249. So, I can add that block to the chain.
  250. And validate it.
  251. What I can also do is I can calculate how much proof of work was in this block based on how many zeros are in the front of the header.
  252. And then I can add up all of the proof of work so far in this chain, and I can estimate the total amount of difficulty represented by all of the proof of work that has gone into all 366,002
  253. blocks.
  254. That gives me the weight of that chain, which means that I can estimate the total cumulative difficulty that is represented by that.
  255. Here's why I need that.
  256. Imagine this is a network that is distributed across the world, as it is, of course.
  257. And imagine that miners are working on this problem in different places in the world.
  258. Now, the miners all start with the same data.
  259. They include more or less the same transactions, and then they race to find proof of work for a block.
  260. Let's say that a miner in Canada finds a block.
  261. And 200 milliseconds later, a miner in Australia finds proof of a block.
  262. So, the Canadian miner started construction of candidate block 366,003.
  263. And at the same time, the Australian miner started construction of candidate block 6 366,003.
  264. When do the miners start constructing these blocks?
  265. As soon as they receive the previous block.
  266. So, think of this as a race.
  267. You're trying to find blocks.
  268. But, if someone tells you there's a new block, that means you just lost the race.
  269. Right? And upon receiving a block from someone else, you validate it as quickly as possible, and then you know the race has started again.
  270. You immediately stop doing what you were doing before, construct a new block on top of it, referencing the hash of the previous block, and start trying to find proof of work as fast as possible. This is a race.
  271. Milliseconds matter.
  272. Right?
  273. So, the moment this block was broadcast across the network, the Canadian miner and the Australian miner both start their engines and they start hashing as fast as they can.
  274. They've constructed a candidate block.
  275. They stuffed all the transactions in.
  276. They calculated the header, and they start throwing random numbers next to it in order to fill that hash function and produce proof of work.
  277. Eight and a half minutes later, the Canadian miner finds a nonce that gives them proof of work.
  278. Now, their header is going to be slightly different than the Australian miner. There might be a The timestamp is going to be different. They might be off by a couple of seconds. The clocks are not perfectly synchronized.
  279. They may have received transactions in a different order.
  280. Maybe they saw the Australian transactions first, and then the Canadian transactions arrived a few milliseconds later. So, the order in which they added them to the blockchain was slightly different.
  281. All of these things completely change the fingerprint of the header, and they completely change the outcome of the proof of work. So, effectively, they're working on blocks that are slightly different.
  282. Maybe just a few bits different. Maybe a few bytes, maybe a few kilobytes different.
  283. Right?
  284. And they're both racing.
  285. At eight and a half minutes, this miner finds a block. At eight and a half minutes and a hundred milliseconds, this miner finds a block, but they're on opposite sides of the world. What do they do as soon as they find a block?
  286. They tell everyone about it.
  287. Because now the race is to make their block the one that the world knows about.
  288. They've won the race.
  289. But, they need to make sure the world knows the they won the race. Because that's what matters. So, they start propagating. They start sending that block on all of the nodes that are connected to them
  290. as fast as they can. So, imagine now you've got these nodes, and you have these two blocks. Pop. Pop.
  291. And they start propagating.
  292. Every node receives the block, says, "Okay, a new one has been found." Sends it to all of their peers after validating it, and they each receive it, validate it, and send it to all of their peers, and propagation starts. A ripple,
  293. like dropping two stones in two opposite sides of the lake, and they start creating these ripples across the network.
  294. Effectively, half the network is being painted green, while half the network is being painted red.
  295. All of the nodes that are closest to Canada see the green block.
  296. They assume this is now the latest block.
  297. All of the nodes that are closest to Australia see the red block. They assume this is the latest block.
  298. We have a race condition.
  299. In distributed system terms, we have a race condition.
  300. Now, this race condition now has to be resolved. In Bitcoin terms, this is called a fork.
  301. Both of these blocks are valid.
  302. They have all of the consensus rules.
  303. They have sufficient proof of work below the target. They're fully validated by everyone.
  304. But, only one can survive.
  305. At the moment, there are now two versions of the Bitcoin blockchain across the world, two competing versions of history. Only one can survive.
  306. So, at this moment you have this fork.
  307. What happens next?
  308. There's no voting mechanism in Bitcoin.
  309. You don't get nodes going, "Hey, I think it's green." Or, "I think it's red."
  310. Voting happens through the application of mining power. Essentially, what happens now is What does a miner do when they receive a block?
  311. They start working on the next one as fast as they can.
  312. By when you receive a block and you start building a child of that block, what you're effectively doing is you're voting for that block and your vote is your hashing power.
  313. You put your computing behind that block and you say, "This is the longest chain as far as I know. I'm going to build on this."
  314. So, at this point, you have all of the nodes that received this one building on top and all of the nodes that received this one building on top.
  315. And the race is on. But now there's two race tracks, a fork.
  316. So, what happens next?
  317. Someone finds a block.
  318. 7 and 1/2 minutes later, someone who had this block as their parent, by complete coincidence, doesn't matter,
  319. finds a new block.
  320. They immediately broadcast it to the entire world.
  321. Everybody who had the Australian block before sees the new block and says, "Okay, new block. I have its parent."
  322. Right?
  323. Connects it, validates it, and immediately starts building on top of it.
  324. What happens to these people?
  325. Everybody who is on this side and suddenly sees this block, looks at that block, starts validating, looks at the parent hash and says, "Oops.
  326. This is a child of red.
  327. I thought green was winning.
  328. I was wrong."
  329. The fact that a child of red won means that green was not the longest chain.
  330. Meaning that every miner who thought green was the longest chain now has a new picture of reality. They now know that the rest of the network thinks red is the longest chain. They are on the wrong side of the fork. So, what do they
  331. do?
  332. They orphan this block.
  333. They basically say, "That was a momentary mistake.
  334. Our history deviated into a parallel universe for 10 minutes where we were wrong.
  335. But now we know better."
  336. What happens to all of the transactions that were in that block?
  337. Well, if you think about it, most of the transactions that were in this block are also in this block.
  338. There's probably very little difference between them.
  339. So, the first thing that happens is all of these miners go, "Could somebody tell me what the red block looks like cuz I've never heard of it." Right? So, they go out on the
  340. network and they ask for the specific parent fingerprint. They say, "Please give me 5D165. I've never seen it.
  341. This one."
  342. And someone on their network says, "Here."
  343. So, it propagates the red block fully.
  344. Now, most likely they've already received it. So, this is a bit of a cheat, right? Which means that even if you got this one first, you also got this one eventually, maybe a few seconds later. And to avoid duplicating
  345. communication, what you do is you put this one on the shelf. You say, "I think we're green, but this red one also is a candidate.
  346. So, I'm going to put it on the shelf there just in case I find them on the wrong side of history."
  347. And then when you find out you're on the wrong side of history, you go back to your shelf and you say, "Ah, turns out it was red."
  348. You take green, you throw away all of the transactions that are in and you put them back in the queue.
  349. Then you take red, you start checking off the list all of the transactions that are already in red and see if there's anything left, which is the difference between the two, and you start putting those
  350. You then check off all of the transactions that are in orange and then you start building on top of orange. So, this side of the network now converges onto orange and they also join the race on top of
  351. orange.
  352. Okay. Let me just repeat that.
  353. Race condition, eventual convergence triggered by the discovery of the next block, forcing a longer chain
  354. validation. This is now the longest chain. Therefore, this wins. Therefore, this is not on the longest chain.
  355. Therefore, this loses.
  356. The entire network then converges on the longest chain.
  357. And then they vote again by building on top of this and new child and continue going.
  358. Yes, questions. Wouldn't it be possible to reach consensus earlier by um deciding between the green and the red for the next block by just saying which of the green and the red has um most people what?
  359. So, that that higher degree of voting and then you then you wouldn't have to wait for the next block before um you know which was going to be the longest chain.
  360. Well, um the difference in proof of work will be very, very minor. Yeah. Right?
  361. still a way of determining which one There are other protocols for consensus.
  362. The problem with that is that it can cause various weird effects in the network. So, this model of eventual convergence after 10 minutes works. Right?
  363. There is another protocol called uh ghost, g o s t, that does some interesting things that allow, for example, children proof of work to still be counted cuz you still did the work and to get maybe a partial
  364. reward for that.
  365. That's not Bitcoin, right? Bitcoin works with this very simplistic algorithm. Um there are many other competing consensus mechanisms.
  366. So, if I'm a miner who has who did the block that's being discovered Yes. do I lose the 25 Bitcoins?
  367. Well, so here's the question.
  368. Each one of these has a check that pays 25 Bitcoins to someone.
  369. Checks are only valid if they're on the longest blockchain.
  370. So, this check is on the longest blockchain.
  371. The entire network knows that this check is no longer on the longest blockchain.
  372. Essentially, this transaction never happened.
  373. You disappear from history.
  374. The truth is the longest chain.
  375. The other chain never happened.
  376. Now, here's where critical consideration comes in.
  377. When you earn a reward check for mining a block, you can't spend that for 100 blocks.
  378. Why?
  379. Because for one block, history is fickle.
  380. Right?
  381. After 100 blocks, if your transaction is still in the chain, it is history. Right?
  382. Think about the Bitcoin blockchain as geological strata.
  383. You're drilling uh core sample in the ice in Antarctica.
  384. The top 10 cm are slush.
  385. They come, they go, they melt, the wind blows stuff around.
  386. You can't tell anything. You go 3 m down, you're looking at 100 years of history and that layer hasn't moved in 100 years.
  387. You go 300 m down and you're looking at the Cretaceous era.
  388. And that millimeter-thin layer hasn't moved in millions of years at all.
  389. And the way that happens is because layers get deposited on top and compacted. And the deeper they are, the harder it is to change them. Bitcoin's consensus algorithm creates a geological
  390. history, if you like. At the top, the wind's blowing and things are very fickle. You go 144 blocks down, which is 1 day old, the probability of a block changing after 144 confirmations is
  391. vanishingly small.
  392. But the algorithm allows it.
  393. You can change block two.
  394. All you have to do
  395. is produce a competing longest chain that has more proof of work cumulatively than 366,000 blocks until today.
  396. In 10 minutes.
  397. Because you have to do that before the other chain gets one block longer.
  398. Right?
  399. And this is how the cumulative work Yes.
  400. They discard them um pretty quickly.
  401. Because you can always retrieve the alternate block. Because if the node is publishing a longest chain, it also has the history behind it.
  402. So, you can always retrieve that. I'm not sure I mean that's an implementation detail. Um but it's a good question. All right.
  403. Yes.
  404. So, this is a very very important consideration.
  405. Who is bandwidth rich? There are two important considerations in mining. How cheap you can buy electricity and how low latency networking you can achieve.
  406. If you have cheap electricity, you can mine as close as possible. Keep in mind that the efficiency of mining equipment is bound on the upper side by Moore's law.
  407. We're already seeing 14 nanometer chip fabrication. Bitcoin mining is approaching the edge of Moore's law faster than desktop computing. Why?
  408. Because there's a $3 billion economic incentive behind it, which doesn't exist in desktop computing anymore.
  409. Bitcoin mining is now driving the development of silicon fabrication, which is shocking. But, what that means is that you can you cannot squeeze more efficiencies out of silicon. Now, it becomes a matter of how densely you can
  410. pack that silicon in a chip, how densely you can pack the chips on a board, how densely you can pack the boards in a rack, how quickly you can suck heat out of that, and how quickly you can push gigawatts or kilowatts or megawatts of
  411. energy into that rack. It's a data center game.
  412. And then, your economic efficiency depends on the cost of your inputs, electricity, the cost of your operations and ability to maintain the hardware, and your ability to propagate these
  413. blocks faster on the network. Latency is enormously important, which means that at the moment, most mining has migrated to China.
  414. And the reason for that is because subsidized coal-fired electrical power in China is I think the ironic term would be dirt cheap.
  415. Um and so, as a result, it it leads that economic concentration there. However, China has bandwidth issues, and latency is a big problem, which means that as the block size increases,
  416. it puts the Chinese miners at a disadvantage. If you have a 1 MB block and you're trying to propagate it to eight nodes, it takes a certain amount of time. If you take that 1 MB block and you increase the size limit to 8 MB, it
  417. takes you eight times as long. And while you're propagating a block, someone else is beating you to it.
  418. All right. How often does a fork happen?
  419. Approximately every day.
  420. Once a day on average. Two block fork, maybe once a week, maybe once a month.
  421. If you start seeing a three block fork, something really weird is happening on the Bitcoin network. Why? Because imagine the two competing sides created two blocks. Then, the two competing sides of the network started building on
  422. top. And again, by coincidence, two blocks were discovered sufficiently far on the network to propagate to equal parts of the network and sufficiently close together in time to not be able to
  423. overwhelm each other. And then, everybody starts building on top. And again, by coincidence, two blocks are found almost simultaneously at opposing sides of the network. The probability of that happening once,
  424. okay, twice, rare, three times, exceedingly rare, etc. etc. It's an exponential function.
  425. And that is the basis of the consensus algorithm. Do we have a crowd?
  426. If someone shows up, we'll have to leave in a hurry.
  427. All right.
  428. Um So, how often do forks that are longer than this happen?
  429. In April of 2013, Bitcoin experienced a two block fork.
  430. Eight minutes later, Bitcoin experienced a three block fork.
  431. 10 minutes after that, Bitcoin experienced a four block fork.
  432. At this point, people started getting worried.
  433. Statistically, we are now in a three four sigma event.
  434. Then, Bitcoin experienced a five block fork, followed by a six block fork, followed by a seven block fork, and that's when the emergency alert message went out.
  435. So, April 2013, Bitcoin had an oh moment.
  436. Because this isn't supposed to happen.
  437. So, what had happened? This is a really interesting study in the mechanics of the network.
  438. That day, or actually about a week before, a new version of Bitcoin had been released.
  439. This new version of Bitcoin used a new database for storage of the blocks.
  440. Instead of using Berkeley DB, it used Google's LevelDB to improve efficiency, indexing, and various other characteristics.
  441. Now, databases are not part of the consensus mechanism.
  442. Only they are.
  443. Because there's a difference between the implied consensus rules or defined consensus rules in the reference implementation and the runtime consensus that is exhibited by the network dynamically as
  444. a behavioral artifact.
  445. And bugs affect the exhibited runtime consensus.
  446. And all that matters is runtime consensus. So, what happened?
  447. Berkeley DB had a bug. That bug was that it was limited to 1,024 file descriptors.
  448. That bug could not be triggered when everyone was running Berkeley DB.
  449. Because no one could create a block with more than 1,000 transactions. Because if they did, it would crash their machine, and they would never propagate it.
  450. But, when version 0.8 came out, and machines were now mining on LevelDB, one of those machines was able to create a block with 1,200 transactions. That block could not be consumed by any node
  451. running Berkeley DB. They would start processing the transactions to validate them. They would open file descriptors.
  452. They would process the first 1,024 transactions, and then they would attempt to validate transaction 1,025, choke on it, crash, and restart.
  453. They would restart, join the network, ask it what the latest block is, receive the exact same block, start validating, 1,025 transactions later, choke, reboot, ask for a block, validate it,
  454. choke, crash, reboot.
  455. Problem is, half the network had updated to LevelDB, half the network was on Berkeley DB. The network suffered a complete bifurcation, almost perfectly 50 50% balanced, and
  456. one side could not move forward.
  457. They couldn't move to the next block.
  458. Because every time they got on the network, they would try to validate the same block.
  459. So, one side mines another block. This one chokes. And another block. This one
  460. The April 2013 event resulted in a 26 block fork, which should not happen during the life of the universe.
  461. This was a perfect example of runtime consensus being different than explicit consensus in the rules.
  462. And it was caused by a bug.
  463. It led to an emergency overnight uh summit, let's call it optimistically a summit.
  464. That's when everyone is screaming on IRC and running around as if their hair is on fire.
  465. And by that morning, this happened around midnight in the US. By that morning, the mining operators had all gotten on board. They did some emergency upgrades, downgrades, patches, etc. And
  466. by running code that anticipated this mistake, they were able, after 26 blocks, to shift all of the hashing power back to the first fork, create a 27 block
  467. longer chain that then invalidated the 26 block chain that had gotten in front, wiped out all of those transactions, reloads them on the other side, and the network continued. What's really
  468. fascinating about this example is that if you made a transaction in the network, it got delayed by 26 blocks.
  469. But, it got processed eventually.
  470. Not a single transaction was dropped.
  471. There were a couple of double spends.
  472. People spent transactions on both sides of the fork, and they did this as a proof of concept, and then they refunded the merchants for their lost money.
  473. Um, and this was one of the events that gives us an opportunity to study the consensus mechanism.
  474. On July 4th, 2015, 5 days ago, we had a six-block fork event.
  475. The six-block fork event was caused by the introduction of a new standard for processing consensus rules called BIP 66, Bitcoin Improvement Proposal 66. BIP 66 has been in planning for more than a
  476. year.
  477. BIP 66 requires that, um, after a certain point, all transactions have elliptic curve digital signature algorithm signatures that are encoded in
  478. a very strict way.
  479. Previously, anything that S OpenSSL accepted as a valid signature was a valid signature. The problem with that is OpenSSL has bugs, and this leads to another phenomenon called transaction
  480. malleability.
  481. So, in order to fix that, a proposal was introduced about a year ago to require that all signatures are strictly encoded in a specific way. It narrowed the range of possibilities in signatures,
  482. tightening the consensus rules, which means that some transactions that were previously valid would now be invalid.
  483. This is a soft fork event, meaning it's backwards-compatible.
  484. This proposal was put to a vote, meaning that it uses the blockchain mechanism to do an automatic upgrade.
  485. Every miner puts a version number in the block.
  486. So, they say, "This is version two."
  487. If a miner was supportive of BIP 66 strict encoding of signatures, they signal this to the network by making all of their blocks version three blocks.
  488. And then, they count.
  489. They look at the blocks that are coming in, and they count. Of the last 1,000 blocks that we've seen on the network, approximately 10 days of blocks, what percentage are version three?
  490. Once the percentage goes about above 75%, BIP 66 is in effect, meaning that everybody should create transactions with strict signature encoding, because
  491. we're about to make a major transition in the network.
  492. This is the grace period. Everybody should switch over to BIP 66 at that point. It's been voted in by the network.
  493. Once 95% of the previous thousand blocks, or 950 blocks, are all version three, this is a transition. And now,
  494. not only is BIP 66 encoding required, but non-BIP 66 encoded, non-strictly encoded, old consensus rules transactions are now considered
  495. invalid.
  496. Meaning that every node should not only produce correctly signed transactions, they should reject incorrectly signed transactions after that threshold. That threshold was reached on the morning of July 4th.
  497. In the afternoon of July 4th, we discovered something interesting.
  498. Miners who received blocks were cheating.
  499. What they were doing is they were building the next block without validating all of the transactions. Why?
  500. Because it takes time to validate transactions, and this is a race.
  501. So, because they weren't validating transactions and proceeding to mine the next block, when someone who was on the minority, the 5% who had not yet upgraded to BIP
  502. 66, created a transaction that was invalid and mined it into a block, that block was accepted.
  503. 75% of the miners started mining the next block without validating it, and then the rest of the network validated it, found the invalid transaction, and rejected that block.
  504. And the network progressed one block.
  505. And part of the network kept rejecting that block.
  506. And so, you had a fork emerge. It lasted six blocks.
  507. The miners who were taking the shortcut lost $50,000 in Bitcoin reward over these blocks, in cumulative power that they consumed.
  508. So, they basically were building blocks, they were doing the proof of work, and those blocks were rejected by consensus, because they did not conform to the new BIP 66 standard. So, because they were taking a shortcut, because they were not
  509. validating to consensus rules, they found themselves on the wrong side of consensus.
  510. And in Bitcoin, you can have opinions, you can believe in big blocks, you can vote for small blocks, you can vote for BIP 66, you can vote against BIP 66. The one thing you can't go is you can't go
  511. against consensus. You go against consensus, you're burning electricity for nothing, and you will pay for that.
  512. And that is the basic game theory of consensus.
  513. On July 5th, we had a three-block fork.
  514. On July 6th, we had a four-block fork.
  515. On July 7th, we had another three-block fork. BIP 66 is still causing instability in the Bitcoin network.
  516. But, over the next, uh, couple of weeks, we expect things will get upgraded, and we will see stability, and the network will converge on strict encoding of signatures. In the
  517. meantime, what's interesting about this scenario is that while this is happening in the network, the network is self-healing.
  518. So, when these forks happen, they get resolved by eventual convergence, and as soon as they get resolved, all of the transactions get properly sequenced, and the network continues.
  519. This is a extremely resilient mechanism for a massively decentralized system.
  520. All right, any questions?
  521. So, with 51% attacks, um, theoretically, you could go back and change like block two, right?
  522. Uh, no. No.
  523. Theoretically, you could. The protocol allows it. Yeah.
  524. You would have to not only sustain 51% hash rate, Yeah.
  525. you would then have to do, um, 366,000 blocks worth of proof of work in 10 minutes. Okay.
  526. So, more likely, you can change one or two blocks in the most recent history.
  527. Yeah.
  528. Maybe three. But, the encoding mechanisms that you're saying are different versions that don't come into that, like that percent of theoretically No, because every node should be able to fully validate from the genesis block
  529. up, no matter what you present to it based on the same rules that were in existence at the time. If you present a completely valid alternate history with sufficient proof of work to a Bitcoin node, it should be able to validate it
  530. all the way to the present from the genesis block. In fact, every node, when it starts, only knows the genesis block.
  531. The first thing it has to do is synchro- synchronize with the network, and it does that by independently and painstakingly verifying everything from genesis block to today. It reconstructs
  532. the entire chain independently. Every node does this. It takes four to five days.
  533. Thank you. The blockchain is about 40 gig at the moment, I think, depending on whether you're indexing all of the transactions or not.
  534. Um, and it's it's growing fast. So, the actual synchronization takes quite a bit of bandwidth and quite a bit of time.
  535. Okay, questions?
  536. Yes. There are many variations of Bitcoins like, uh, Dash and Doge and all this. Do they use the same mechanics as Bitcoin? Not all. Uh, so, the vast majority of altcoins operate
  537. using what we would call Nakamoto consensus.
  538. Nakamoto consensus being, uh, longest chain proof of work as determined by usually a SHA-256 algorithm. Some use a SHA-3 algorithm, or a script algorithm,
  539. or different forms of hashing algorithms, but they still implement Nakamoto consensus in terms of longest chain proof of work. But, there are altcoins that use other forms of consensus, modified consensus with, uh,
  540. taking into consideration orphan childs, for example, which is ghost, what I described before. We have some experimental implementations of that.
  541. Um, there are consensus mechanisms that, instead of proof of work, are based on proof of stake, or delegated proof of stake. Um, and we're seeing all kinds of new consensus algorithms being dreamt up. How many of those can scale
  542. to a global level of security that is resistant to global attacks? So far, one.
  543. Bitcoin.
  544. But, that doesn't mean another one can't scale. What's difficult, however, is that if you try to scale a consensus algorithm today, you have to reach scale before you are attacked at scale. You
  545. have to build an industrial infrastructure of hashing or mining or or a user adoption base or an economic base that is big enough to resist attack before you are attacked.
  546. Bitcoin did this by everybody ignoring it for a couple of years because they didn't think it was important. And by the time everybody noticed and thought, "Okay, maybe this is important and worth attacking,"
  547. it was already strong enough that it couldn't be attacked. And then, the strength of the network has outpaced the adoption and demand and attacks to make it extremely resilient to
  548. attack. The problem is you can't do that again because if you actually have a really innovative um consensus algorithm and people think that's going to be valuable, and they think it's going to be valuable enough to join the consensus
  549. algorithm and mine for it, they're also going to think it's valuable enough to attack. And there's no flying under the radar anymore.
  550. This is not just an algorithm. This is now a completely new scientific discipline. Consensus algorithms will be entire computer science curricula
  551. in the future. This is a completely new branch of distributed computing. It is extremely important, and it is now 6 years old.
  552. This is the birth of a new scientific discipline, and we've gone from one scientific paper, the Satoshi Nakamoto paper, last year about 140 papers, peer-reviewed academic journal papers
  553. were written on consensus algorithms.
  554. This is now a thriving scientific discipline with dozens and dozens of researchers around the world working on this.
  555. Yes.
  556. Do you worry the consensus is all happening in the way the transactions are moved around, but there's consensus if there's no consensus currently no consensus on the checkpoints that are sent out and the way that the software is um
  557. updated?
  558. Do you Do you worry that the lack of consensus Is that Is that centralized?
  559. And if it is centralized, do you worry about that?
  560. So, consensus works in waves.
  561. And this is an important concept to understand.
  562. There's what I would call process consensus, which is a a process of debate and proposal that happens among the development community. It starts with Bitcoin improvement proposals, discussions on GitHub, Bitcoin Talk, uh
  563. the Bitcoin developers mailing list, and various other places where people suggest changes or um slight modifications to the rule or major modifications to the rules.
  564. That discussion, the the reason for that discussion is to enable smooth software transitions in runtime consensus. So, what you do is you gather, debate, and try to reach
  565. uh process consensus, which means that you have enough people in the development community agreeing with you.
  566. You then do a lot of testing in order to validate the software. You provide a reference implementation that implements the change. You demonstrate that reference implementation on the testnet, which is a parallel Bitcoin
  567. blockchain. Uh you run a battery of tests.
  568. The other developers poke holes in it, find bugs, suggest improvements, and at some point you reach consensus.
  569. Then, that is implemented in the Bitcoin Core reference implementation. Now, you've reached reference consensus, which means that it is introduced as a release in the software.
  570. In order to do that, you have to get a broader set of consensus. Now, that software is released.
  571. In order for that software to actually go into the network, people have to upgrade. So, now you have to have consensus among the constituencies. And people think that miners are the only constituency, but there are actually
  572. five consensus constituencies in Bitcoin.
  573. The software developers who are making the reference implementation, the miners who are implementing the runtime consensus for mining blocks, but also the exchanges.
  574. Each exchange that exchanges Bitcoin into other forms of currencies is running nodes that validates transactions, and they choose which version of the software they're running.
  575. The wallets.
  576. Each wallet company or wallet software out there creates transactions that must be validated by consensus rules, and if they're doing centralized wallet processing, they're also running nodes
  577. that must validate transactions based on consensus rules. And finally, merchants and merchant processing, the economic engine of Bitcoin.
  578. Merchants, either directly or through processes, are running nodes to validate transactions, and they're doing the strictest validation possible because they're the ones who give out a plasma TV for this mythical magic internet
  579. money.
  580. And so, if they don't validate the transaction correctly, they're out one TV and don't have Bitcoin to show for it.
  581. Now, what happens if the miners go off on their own and the merchants, exchanges, and wallets choose a different version?
  582. Well, the miners create Bitcoin.
  583. And they mine it. And 100 transactions later, they try to spend that Bitcoin.
  584. Only, they can't spend the Bitcoin because they can't buy anything it cuz the merchants are on a different chain and therefore their transaction never happened according to the merchants.
  585. They They can't convert it into currency to pay for their electricity because the exchanges are on a different chain and therefore the transaction never happened according to them. And by the way, all this time they've been mining empty
  586. blocks because the wallets are on a different chain and are producing transactions based on different consensus rules.
  587. It's not so easy to shift consensus in Bitcoin. In fact, what we're seeing over time is that it's getting harder and harder to modify consensus rules.
  588. This is a process that we see in distributed systems and protocols. Um I call it ossification. I don't know if that's an industry standard term, but the idea is that after a while, as the protocol gets embedded in more software
  589. systems, more developers learn how to use it, it gets embedded in hardware, it gets embedded in systems that are not updated often enough or maintained often enough, um then it becomes harder and harder to change. A great example of
  590. that is IPv4. IPv4 got so embedded that we've now spent almost 20 years trying to upgrade it to IPv6, and it is resisting its own successor.
  591. It's becoming incredibly difficult to upgrade IPv4. And the reason for that is because you have it embedded in fridge s and light switches and wireless access points and things that don't have interfaces and can't be
  592. upgraded or don't have enough memory and can't be upgraded.
  593. IPv4 became ossified.
  594. The best protocol doesn't win.
  595. The protocol that's good enough and achieves network scale first wins. Uh so, the consensus rules of Bitcoin today um are likely to be able to uh absorb change for a couple more years at the
  596. core protocol level.
  597. After that, most of the innovation has to move to protocol layers above, just like most of the innovation on the internet moved from IP to TCP to HTTP and to other protocols above HTTP um
  598. because each of the layers below gradually became ossified and could not be changed dramatically. You can't go and change TCP/IP today. Simply impossible.
  599. All right.
  600. Uh let me take one more question and then we're going to wrap cuz we're running late.
  601. Yes.
  602. How many transactions can you actually get done in 10 minutes?
  603. So, how many transactions can you get done in 10 minutes?
  604. Um that is a capacity limitation, which is artificially constrained by the maximum size of a block. A block today, it can be a maximum size of 1 MB.
  605. Uh with a maximum size of 1 MB, it can fit a few thousand transactions, depending on the size of each transaction, which is variable. Uh the average processing capacity is between
  606. three transactions per second to seven transactions per second with the current constraints.
  607. These are artificial constraints. So, there's a big debate going on in Bitcoin at the moment as to how and when to raise the capacity limit. For the time being, uh blocks are coming in full about 60 to 75% of the time, meaning
  608. that there's still excess capacity to fill with low fee transactions, um and most transactions, the vast majority, get confirmed within the next available block on a best effort basis.
  609. Occasionally, when the network is under stress, uh it may take two or three blocks for a transaction to be processed. Transactions don't have an expiration date. As long as the network knows about them, they will be eventually confirmed. They are valid
  610. forever.
  611. And so, therefore, you can keep retransmitting a transaction until there's sufficient capacity in the system to absorb it. It's fairly resilient in that way. Uh the proposals at the moment are to increase the block size capacity by January 2016 to 8 MB,
  612. an eightfold increase, followed by an increase uh twice over every 4 years.
  613. So, 8 16 32 every 4 years, and to keep increasing the size. In 2032, that gets us to a 20 GB block, um which if we keep approximately the same size of
  614. transaction means 20,000 time increase in the capacity of transactions. So, you're looking at approximately 100,000 transactions per second. 100,000 transactions per second is the global
  615. capacity of the Visa network.
  616. So, depending on whether you need to do all of the transactions on the blockchain because there's a big argument that you can actually do a lot of the transactions off the blockchain.
  617. You don't need to put every transaction on the blockchain. There are many circumstances where you can do incremental transactions between two parties. This technology is called payment channels and then do eventual
  618. settlement of the net difference between all of the summer transactions as a single transaction on the blockchain.
  619. What that does is it takes the trust capability of the network and it provides it as a as an attribute to a layer above that it can leverage it but without flooding the blockchain with transactions. So, there's the base
  620. amount of transactions you can actually record on the blockchain, but each one of those could represent hundreds of transactions that happen off blockchain in between two parties. So, the actual
  621. capacity may be a lot higher.
  622. It's a bit like in monetary terms we talk about M0, which is the base amount of physical currency that is in existence.
  623. Right? And the amount of cash that exists in the economy is less than 3% of the total amount of money in the economy. But, because that cash gets used again and again and again it actually enables for a lot more
  624. economic activity velocity for each unit of currency. In blockchain you can think of the base transaction rate as the capacity of the base mechanism, but with overlay networks you can
  625. magnify that and increase the velocity of each transaction. Does that answer your question?
  626. So, essentially you're not expecting to sell a thousand plasma TVs in each each block.
  627. That that would be dealt with by some higher protocol.
  628. Well, at the moment you could if you wanted to, just about.
  629. But, if you have more I'm thinking in terms of of um You have to you have to um predict is Bitcoin the currency with
  630. which you buy aircraft carriers or is Bitcoin the currency with which everyone two three billion people buy a cup of coffee every single day.
  631. Right? And then the secondary question is if Bitcoin is the currency with which billions of people buy a cup of coffee every day, do all of those transactions happen on the core blockchain, which means that we need to massively increase
  632. capacity, or do many of them happen on overlay networks with eventual settlement? Which still preserves the decentralized nature. It still preserves the transactional trust in the thing, but it doesn't flood the blockchain. And
  633. there's competing schools of thought on this. So, we necessarily must scale up capacity and the question is not whether we will use technique A, B, or C, but more how
  634. quickly can we use A and B and C in parallel to increase capacity. We're seeing overlay networks and block size increases and optimization of block propagation and pruning of transactions
  635. off the blockchain to reduce the footprint on disk and optimizations on validation and processing. All of these things are happening at the same time.
  636. It's a bit of a philosophical issue at the moment. We don't know where Bitcoin is going as a transaction processing environment yet.
  637. So, your suggestion is that it won't be the the whole thing. It will be a supporting layer for other things.
  638. Um Not necessarily. I think that's more likely, but it could very well scale to to support hundreds of thousands of transactions per second.
  639. Because one of the other things that is the context in which all of this is happening, of course, is Moore's law.
  640. And so, if bandwidth and storage and compute capacity continue to increase at Moore's law then in the next 20 years as Bitcoin reaches mainstream adoption you
  641. could actually support billions of users with quadrillions of transactions.
  642. You just have to start moving a lot more data on a lot beefier computers.
  643. And so, we don't know exactly where it's going.
  644. We'll see.
  645. It's one of the this is a software engineering problem.
  646. This is why it's exciting.
  647. Hopefully that research will be done here at UCL. Thank you so much for coming here.