1 00:00:00,500 --> 00:00:02,740 The following content is provided under a Creative 2 00:00:02,740 --> 00:00:04,160 Commons license. 3 00:00:04,160 --> 00:00:06,370 Your support will help MIT OpenCourseWare 4 00:00:06,370 --> 00:00:10,460 continue to offer high-quality educational resources for free. 5 00:00:10,460 --> 00:00:13,000 To make a donation or to view additional materials 6 00:00:13,000 --> 00:00:16,960 from hundreds of MIT courses, visit MIT OpenCourseWare 7 00:00:16,960 --> 00:00:18,322 at ocw.mit.edu. 8 00:00:21,970 --> 00:00:26,780 TADGE DRYJA: OK, so today I will talk about mostly fees, which 9 00:00:26,780 --> 00:00:29,390 is an interesting and somewhat contentious 10 00:00:29,390 --> 00:00:32,740 issue in Bitcoin and all these other systems. 11 00:00:32,740 --> 00:00:36,290 So schedule for today, problem set 3 description, 12 00:00:36,290 --> 00:00:39,980 we'll talk about fees, these unknowable acronyms-- 13 00:00:39,980 --> 00:00:43,082 Child Pays for Parent, Replaced By Fee-- 14 00:00:43,082 --> 00:00:45,290 and then talk a little bit about long-term incentives 15 00:00:45,290 --> 00:00:48,020 in Bitcoin, and how that relates to fees. 16 00:00:48,020 --> 00:00:51,500 OK, so the problem set 3 is to grab UTXOs. 17 00:00:51,500 --> 00:00:52,850 Hopefully it's fun. 18 00:00:52,850 --> 00:00:55,490 You're going to be making transactions 19 00:00:55,490 --> 00:00:58,340 on the real Bitcoin test network. 20 00:00:58,340 --> 00:01:00,680 So one of the parts of it that hopefully is not too hard 21 00:01:00,680 --> 00:01:06,080 is downloading and install Bitcoin D. So I'll put a link. 22 00:01:06,080 --> 00:01:09,860 The current, most up-to-date version is 0.16.0. 23 00:01:09,860 --> 00:01:11,600 I believe the next version will just 24 00:01:11,600 --> 00:01:15,650 be called 17, because a lot of the developers are like, 25 00:01:15,650 --> 00:01:18,350 this is annoying, it's always starting with a zero, 26 00:01:18,350 --> 00:01:20,487 it's like 0.1, 0.2, 0.3. 27 00:01:20,487 --> 00:01:22,070 And they're like, well, at some point, 28 00:01:22,070 --> 00:01:23,120 should we get to version 1? 29 00:01:23,120 --> 00:01:24,140 And they're like, well, everyone's 30 00:01:24,140 --> 00:01:26,210 going to think version 1 means it's better. 31 00:01:26,210 --> 00:01:31,420 Let's just call the next version 17 instead of 0.17. 32 00:01:31,420 --> 00:01:35,180 So download that, and then sync up to testnet. 33 00:01:35,180 --> 00:01:36,710 If you just run it by default, it 34 00:01:36,710 --> 00:01:39,140 will sync up to the main network, which will download 35 00:01:39,140 --> 00:01:41,500 something like 170 gigabytes. 36 00:01:41,500 --> 00:01:42,982 You don't want that. 37 00:01:42,982 --> 00:01:45,440 And the homework assignment cannot be completed on the main 38 00:01:45,440 --> 00:01:47,570 network. 39 00:01:47,570 --> 00:01:48,650 There's no free money-- 40 00:01:48,650 --> 00:01:50,692 I haven't put any free money on the main network. 41 00:01:52,882 --> 00:01:54,590 However, on the test network, it'll work. 42 00:01:54,590 --> 00:01:58,640 And it's about 11 gigabytes of download. 43 00:01:58,640 --> 00:02:00,920 So I think most people, on your laptop, 44 00:02:00,920 --> 00:02:02,180 probably have 11 gigs free. 45 00:02:02,180 --> 00:02:04,410 It's doable. 46 00:02:04,410 --> 00:02:06,900 And it's kind of fun to see how it works. 47 00:02:06,900 --> 00:02:08,990 So if you don't have access to 11 gigs, 48 00:02:08,990 --> 00:02:11,450 you can probably get an Athena node to do it. 49 00:02:11,450 --> 00:02:12,440 It's not too big. 50 00:02:12,440 --> 00:02:14,900 You can run a tiny little node with not much RAM, not 51 00:02:14,900 --> 00:02:16,520 much space, and it'll work. 52 00:02:16,520 --> 00:02:18,380 You can also sync up on a Raspberry Pi. 53 00:02:18,380 --> 00:02:19,910 It just takes a little longer. 54 00:02:19,910 --> 00:02:22,580 So I don't think it'll be too hard to do. 55 00:02:22,580 --> 00:02:24,463 You can probably get around-- 56 00:02:24,463 --> 00:02:25,880 sort of the goal of the assignment 57 00:02:25,880 --> 00:02:30,350 is to check out the actual Bitcoin D and Bitcoin CLI. 58 00:02:30,350 --> 00:02:32,090 You can use a block explorer if you want. 59 00:02:32,090 --> 00:02:33,632 I'm not going to say that's cheating, 60 00:02:33,632 --> 00:02:34,760 but it's also not as fun. 61 00:02:34,760 --> 00:02:37,760 So the block explorers websites will 62 00:02:37,760 --> 00:02:39,923 help you find a lot of things, because they 63 00:02:39,923 --> 00:02:41,840 have different databases and different indexes 64 00:02:41,840 --> 00:02:43,615 so you can sort of search through things. 65 00:02:43,615 --> 00:02:45,240 It's more fun if you write it yourself. 66 00:02:45,240 --> 00:02:46,860 But if you try this, 67 00:02:46,860 --> 00:02:48,860 OK, that works too. 68 00:02:48,860 --> 00:02:51,900 Yeah, so hopefully you get familiar with the Bitcoin CLI. 69 00:02:51,900 --> 00:02:56,070 If you want to do your own scripting with Bitcoin, 70 00:02:56,070 --> 00:02:57,390 you can use anything you want. 71 00:02:57,390 --> 00:03:01,080 So Bitcoin CLI is a command-line utility 72 00:03:01,080 --> 00:03:05,190 that will let you interact with the Bitcoin node. 73 00:03:05,190 --> 00:03:07,250 So for example-- is this readable? 74 00:03:07,250 --> 00:03:09,750 Kind of, right? 75 00:03:09,750 --> 00:03:13,260 So if I want to get peer info. 76 00:03:13,260 --> 00:03:15,210 I want to see-- this is a computer down 77 00:03:15,210 --> 00:03:17,520 on the first floor, running Bitcoin Mainnet, 78 00:03:17,520 --> 00:03:19,920 I want to see, OK, who's connected to me? 79 00:03:19,920 --> 00:03:21,090 And then it'll tell me. 80 00:03:21,090 --> 00:03:24,840 It returns JSON, and it tells me all about the people 81 00:03:24,840 --> 00:03:25,930 I'm connected to. 82 00:03:25,930 --> 00:03:31,080 If I want to say, get wallet info, it'll tell me 83 00:03:31,080 --> 00:03:34,270 I don't have any money-- 84 00:03:34,270 --> 00:03:36,400 things like that. 85 00:03:36,400 --> 00:03:37,690 And then there's, like, Help. 86 00:03:37,690 --> 00:03:42,250 It's weird and it's not super well documented. 87 00:03:42,250 --> 00:03:44,140 It's fairly well documented in this stuff. 88 00:03:44,140 --> 00:03:48,340 There's also tons of undocumented hidden RPC calls 89 00:03:48,340 --> 00:03:52,895 that are deprecated, or new, or programmers put in 90 00:03:52,895 --> 00:03:54,520 and they don't want people to use them. 91 00:03:54,520 --> 00:03:56,690 They only want to use them for themselves. 92 00:03:56,690 --> 00:03:59,560 So it's kind of a mess, but it's fun 93 00:03:59,560 --> 00:04:02,680 to see exactly how this software works. 94 00:04:02,680 --> 00:04:06,090 So hopefully you can try that out. 95 00:04:06,090 --> 00:04:08,590 And I will add more UTXOs to grab in the next few days. 96 00:04:08,590 --> 00:04:09,840 So that might be fun. 97 00:04:09,840 --> 00:04:13,445 You could, if you wanted to be a jerk, just steal all the money, 98 00:04:13,445 --> 00:04:14,820 and then no one else could do it. 99 00:04:14,820 --> 00:04:16,200 But please don't do that. 100 00:04:16,200 --> 00:04:19,500 I mean, this is not as adversarial a setting 101 00:04:19,500 --> 00:04:20,578 as actual Bitcoin. 102 00:04:20,578 --> 00:04:22,370 If someone does it, I'll be like, OK, fine, 103 00:04:22,370 --> 00:04:25,190 and I'll just like reseed the place. 104 00:04:25,190 --> 00:04:27,440 So hopefully we don't have too many trolls 105 00:04:27,440 --> 00:04:29,190 trying to prevent everyone from having fun 106 00:04:29,190 --> 00:04:30,780 with this assignment. 107 00:04:30,780 --> 00:04:33,690 That said, there is at-- aspect some of them are-- 108 00:04:33,690 --> 00:04:36,210 the one I put in the assignment last night, 109 00:04:36,210 --> 00:04:39,210 there's five outputs that you can grab. 110 00:04:39,210 --> 00:04:41,820 One of the sort of hints-- there's only five outputs. 111 00:04:41,820 --> 00:04:45,150 So the first five people to grab it get the coins. 112 00:04:45,150 --> 00:04:49,220 So there is a little bit of timing stuff there. 113 00:04:49,220 --> 00:04:49,970 Any questions? 114 00:04:49,970 --> 00:04:50,470 Cool? 115 00:04:53,990 --> 00:04:56,160 Yeah, so if you have questions about it, 116 00:04:56,160 --> 00:04:59,720 office hours tomorrow, also IRC, stuff like that. 117 00:04:59,720 --> 00:05:01,830 OK, so today's main topic-- 118 00:05:01,830 --> 00:05:03,970 transaction fees. 119 00:05:03,970 --> 00:05:08,220 So we described earlier that the transaction fee is just 120 00:05:08,220 --> 00:05:11,070 the difference between the sum of the input amounts and output 121 00:05:11,070 --> 00:05:13,350 amounts. 122 00:05:13,350 --> 00:05:15,120 What's interesting is it's implicit. 123 00:05:15,120 --> 00:05:17,880 So if you actually look at a transaction, 124 00:05:17,880 --> 00:05:20,790 you can't tell what the fees are. 125 00:05:20,790 --> 00:05:22,350 You have to look at its ancestors 126 00:05:22,350 --> 00:05:24,840 to tell what the fees are. 127 00:05:24,840 --> 00:05:27,830 So for example, if you want to go through here and-- oh, 128 00:05:27,830 --> 00:05:30,750 how am I going to do this? 129 00:05:30,750 --> 00:05:32,630 Jeez. 130 00:05:32,630 --> 00:05:35,970 If I want to say, OK, what's the most current block? 131 00:05:35,970 --> 00:05:39,350 getblockchaininfo. 132 00:05:39,350 --> 00:05:42,840 OK, so the most current block is this. 133 00:05:42,840 --> 00:05:46,550 And then I can say, OK, getblock-- 134 00:05:46,550 --> 00:05:47,610 can I just say getblock? 135 00:05:47,610 --> 00:05:50,120 Yeah, I want to get that block. 136 00:05:50,120 --> 00:05:53,230 OK, there's all the transactions in this block. 137 00:05:53,230 --> 00:05:55,300 I can do getblock verbose true, and it'll give me 138 00:05:55,300 --> 00:05:56,530 all the transaction data. 139 00:05:56,530 --> 00:05:59,260 But instead, I can just pick one of these transactions 140 00:05:59,260 --> 00:06:04,430 and say getrawtransaction, get that thing. 141 00:06:04,430 --> 00:06:06,790 Oh, here's another weird thing. 142 00:06:06,790 --> 00:06:08,590 So it'll just give you hex, which 143 00:06:08,590 --> 00:06:13,180 is not very useful, unless you somehow can read hexadecimal. 144 00:06:13,180 --> 00:06:19,381 And then in the actual thing, it says, like, examples. 145 00:06:19,381 --> 00:06:20,260 Wait, true? 146 00:06:20,260 --> 00:06:21,120 Did they change it? 147 00:06:21,120 --> 00:06:23,340 You used to have to do 1 at the end. 148 00:06:23,340 --> 00:06:24,050 Yeah. 149 00:06:24,050 --> 00:06:24,910 But true works too? 150 00:06:27,888 --> 00:06:29,430 It used to not work if you said true, 151 00:06:29,430 --> 00:06:31,645 and you had to put the number 1 instead of true. 152 00:06:31,645 --> 00:06:33,270 There is a lot of weird bugs in Bitcoin 153 00:06:33,270 --> 00:06:35,120 that have been there for years, and I 154 00:06:35,120 --> 00:06:36,570 guess they fixed that one. 155 00:06:36,570 --> 00:06:39,480 The most egregious is probably the multisig bug, 156 00:06:39,480 --> 00:06:42,000 where when you're spending from a multisig output, 157 00:06:42,000 --> 00:06:44,770 you have to push a zero-byte onto the stack first, 158 00:06:44,770 --> 00:06:46,480 or else it doesn't work. 159 00:06:46,480 --> 00:06:48,160 It was just a bug Satoshi had. 160 00:06:48,160 --> 00:06:50,320 And now it's consensus critical. 161 00:06:50,320 --> 00:06:52,990 And people joke about it, like, oh, we also 162 00:06:52,990 --> 00:06:54,670 have to put a zero-byte in whatever new 163 00:06:54,670 --> 00:06:58,920 RPC we create, because there's just, like, bugs. 164 00:06:58,920 --> 00:07:02,950 Anyway, so for example, this transaction that I just brought 165 00:07:02,950 --> 00:07:10,010 up, this is how it'll look. 166 00:07:10,010 --> 00:07:14,198 Here's the TXID, it's 370 bytes, it's 167 00:07:14,198 --> 00:07:16,490 got this lock time, which-- ooh, I should mention that. 168 00:07:16,490 --> 00:07:19,820 I'm guessing this transaction was created by Bitcoin Core 169 00:07:19,820 --> 00:07:23,110 Wallet, not a different wallet. 170 00:07:23,110 --> 00:07:24,520 That's a hint. 171 00:07:24,520 --> 00:07:27,580 It's got one input-- 172 00:07:27,580 --> 00:07:28,520 no, two inputs. 173 00:07:28,520 --> 00:07:32,710 OK, so inputs are specified-- this TXID input, 174 00:07:32,710 --> 00:07:35,050 this TXID input-- 175 00:07:35,050 --> 00:07:41,980 two inputs and one output of value, 0004500. 176 00:07:41,980 --> 00:07:44,370 We can't tell what the fee is from this. 177 00:07:44,370 --> 00:07:45,770 No, sorry, two outputs. 178 00:07:45,770 --> 00:07:46,970 Here are the two outputs. 179 00:07:46,970 --> 00:07:49,177 So we can tell these two outputs, however, 180 00:07:49,177 --> 00:07:50,510 we don't know what the fees are. 181 00:07:50,510 --> 00:07:51,885 We know the total output amounts, 182 00:07:51,885 --> 00:07:54,860 but the input amounts are not encoded 183 00:07:54,860 --> 00:07:56,240 in the transaction itself. 184 00:07:56,240 --> 00:07:57,650 In order to figure that out, we'd 185 00:07:57,650 --> 00:08:03,380 have to go to this transaction and see what vout 0's output 186 00:08:03,380 --> 00:08:06,770 amount is, which we can do. 187 00:08:06,770 --> 00:08:12,710 And it's 0052-- you know, so we can add it up that way, 188 00:08:12,710 --> 00:08:18,650 but it's not written directly, which is a little weird. 189 00:08:18,650 --> 00:08:21,020 And the idea of the fee is, whoever mines 190 00:08:21,020 --> 00:08:25,460 that block that includes that transaction gets the fee. 191 00:08:25,460 --> 00:08:29,840 So the sum of all the inputs and outputs within a block 192 00:08:29,840 --> 00:08:34,610 do add up, modulo the new coins that are created. 193 00:08:34,610 --> 00:08:37,688 But long-term, when there's no coins being created, 194 00:08:37,688 --> 00:08:39,480 when they've all been created, you can say, 195 00:08:39,480 --> 00:08:41,299 OK, we can look at a block, add up 196 00:08:41,299 --> 00:08:44,660 all the inputs spent in all the transactions in the block, 197 00:08:44,660 --> 00:08:47,030 add up all the outputs created in all the transactions 198 00:08:47,030 --> 00:08:50,090 in the block, and those should equal. 199 00:08:50,090 --> 00:08:51,110 Otherwise, it's invalid. 200 00:08:51,110 --> 00:08:52,640 Well, they don't have to equal. 201 00:08:52,640 --> 00:08:54,890 You're always allowed to destroy coins. 202 00:08:54,890 --> 00:08:57,200 So if the miner says, hey, there's 203 00:08:57,200 --> 00:08:58,970 all these fees that can be paid to me, 204 00:08:58,970 --> 00:09:02,030 and I just don't grab them, you can do that. 205 00:09:02,030 --> 00:09:07,160 So it's a less-than-or-equals operator that-- it's the check. 206 00:09:07,160 --> 00:09:10,910 And people have destroyed coins, usually inadvertently. 207 00:09:10,910 --> 00:09:13,190 There was one in January where there 208 00:09:13,190 --> 00:09:16,820 was a block that just had a zero output for the miner reward, 209 00:09:16,820 --> 00:09:22,060 so all whatever, 13, 14 coins were just destroyed. 210 00:09:22,060 --> 00:09:24,220 Yeah, it seemed like a bug. 211 00:09:24,220 --> 00:09:27,320 So that's how fees work. 212 00:09:27,320 --> 00:09:29,320 What's interesting is, you don't know who you're 213 00:09:29,320 --> 00:09:32,170 paying when you create the fee. 214 00:09:32,170 --> 00:09:34,060 You sign sort of, OK, here's my transaction, 215 00:09:34,060 --> 00:09:38,110 I sign it off, whoever confirms this transaction gets $5 216 00:09:38,110 --> 00:09:39,085 or whatever. 217 00:09:39,085 --> 00:09:40,210 And you throw it out there. 218 00:09:40,210 --> 00:09:42,790 So it's kind of interesting. 219 00:09:42,790 --> 00:09:43,800 There could be legal-- 220 00:09:43,800 --> 00:09:45,967 I've heard there's legal questions, like, well, what 221 00:09:45,967 --> 00:09:48,520 if one of the miners is in Iran, now 222 00:09:48,520 --> 00:09:51,320 you're paying someone in Iran, are you in trouble for that? 223 00:09:51,320 --> 00:09:52,570 You don't know. 224 00:09:52,570 --> 00:09:54,642 You can't tell who going to mine it beforehand. 225 00:09:57,650 --> 00:10:00,290 And generally, we talk about fee rates, or sort 226 00:10:00,290 --> 00:10:04,030 of a specific fee-per-byte. 227 00:10:04,030 --> 00:10:07,690 And it's expressed in Satoshis per byte, and one Satoshi 228 00:10:07,690 --> 00:10:10,930 being the minimum possible bitcoin 229 00:10:10,930 --> 00:10:17,410 amount, which is 1, 2, 3, 4, 1, 2, 3 zeros, so seven years. 230 00:10:17,410 --> 00:10:21,487 There's eight digits in bitcoin. 231 00:10:21,487 --> 00:10:22,570 And you usually keep that. 232 00:10:22,570 --> 00:10:26,220 So you pad it out. 233 00:10:26,220 --> 00:10:31,170 So even in something where it's 0.0134, 234 00:10:31,170 --> 00:10:33,480 they put the extra four zeros. 235 00:10:33,480 --> 00:10:38,280 In the actual code, this is just a 64-bit signed integer, 236 00:10:38,280 --> 00:10:40,740 and there is no decimal point. 237 00:10:40,740 --> 00:10:44,447 So it's sort of a UI thing to put a decimal point in so 238 00:10:44,447 --> 00:10:46,530 that people can think of, oh, that's two bitcoins, 239 00:10:46,530 --> 00:10:47,940 or that's half a bitcoin. 240 00:10:47,940 --> 00:10:50,910 But really, the code only deals with the Satoshis, 241 00:10:50,910 --> 00:10:54,520 and the decimal point is purely UI layer, 242 00:10:54,520 --> 00:10:56,095 which can be confusing sometimes, 243 00:10:56,095 --> 00:10:57,720 when you're dealing with JSON, and when 244 00:10:57,720 --> 00:10:59,850 you're dealing with different programs, 245 00:10:59,850 --> 00:11:01,140 tossing numbers around. 246 00:11:01,140 --> 00:11:03,810 You can get a factor of 100 million off, sometimes. 247 00:11:03,810 --> 00:11:08,400 It's a big enough factor that, usually, it's pretty obvious. 248 00:11:08,400 --> 00:11:11,420 So from a miner's point of view, they 249 00:11:11,420 --> 00:11:17,170 want to prioritize, based on the TX size and the fee rate 250 00:11:17,170 --> 00:11:18,730 because space is limited. 251 00:11:18,730 --> 00:11:20,920 So one of the other rules that's probably 252 00:11:20,920 --> 00:11:23,440 one of the most controversial and argued-about rules 253 00:11:23,440 --> 00:11:27,070 in Bitcoin was a 1-megabyte block size limit. 254 00:11:27,070 --> 00:11:29,320 So the idea is, OK, you can put all these transactions 255 00:11:29,320 --> 00:11:31,558 in the block, but the total block, when serialized, 256 00:11:31,558 --> 00:11:33,100 including the headers and everything, 257 00:11:33,100 --> 00:11:36,270 needs to be 1 million bytes or less, 258 00:11:36,270 --> 00:11:39,560 which is now not quite true because there's 259 00:11:39,560 --> 00:11:40,970 ways around that. 260 00:11:40,970 --> 00:11:45,220 But there's still a hard limit of 4 megabytes today. 261 00:11:45,220 --> 00:11:47,950 What's also interesting is it's totally unrelated to the amount 262 00:11:47,950 --> 00:11:50,290 of coins being transferred. 263 00:11:50,290 --> 00:11:52,270 So in that sense, the fee is flat. 264 00:11:52,270 --> 00:11:55,360 Whether you're sending 100 Bitcoins, or one Bitcoin, 265 00:11:55,360 --> 00:11:57,830 or a millionth of a Bitcoin. 266 00:11:57,830 --> 00:12:01,210 The miner doesn't really care. 267 00:12:01,210 --> 00:12:02,890 It's just based on space. 268 00:12:02,890 --> 00:12:06,580 You're paying for your data usage of the network, 269 00:12:06,580 --> 00:12:09,970 and your actual sort of monetary value transferring 270 00:12:09,970 --> 00:12:11,410 is unrelated to that. 271 00:12:11,410 --> 00:12:14,860 To some extent, later on, you might think, well, 272 00:12:14,860 --> 00:12:18,250 miners might try to charge people sending more money 273 00:12:18,250 --> 00:12:22,590 more because they're more able to pay. 274 00:12:22,590 --> 00:12:25,230 But so far, we haven't seen anything like that. 275 00:12:25,230 --> 00:12:27,000 It's mostly just the miners looking at, 276 00:12:27,000 --> 00:12:30,240 I've got a megabyte of size to parcel out to people, 277 00:12:30,240 --> 00:12:33,820 I'm going to try to pack that in is at as high a rate as I can. 278 00:12:33,820 --> 00:12:36,480 And whether someone's paying a little bit or a lot-- 279 00:12:36,480 --> 00:12:38,550 whether someone is moving a little bit or a lot, 280 00:12:38,550 --> 00:12:40,390 the miners don't care. 281 00:12:40,390 --> 00:12:41,920 Any questions about these things? 282 00:12:41,920 --> 00:12:42,420 Yeah. 283 00:12:42,420 --> 00:12:44,628 AUDIENCE: I have a question about actually the miners 284 00:12:44,628 --> 00:12:45,610 getting the fees. 285 00:12:45,610 --> 00:12:46,745 So how does that-- 286 00:12:46,745 --> 00:12:49,400 because that's not part of the Coinbase transaction. 287 00:12:49,400 --> 00:12:50,980 TADGE DRYJA: It is, it is. 288 00:12:50,980 --> 00:12:52,520 So if we look-- 289 00:12:52,520 --> 00:12:54,390 how am I going to do this? 290 00:12:54,390 --> 00:12:56,640 AUDIENCE: You could look into the Coinbase transaction 291 00:12:56,640 --> 00:13:00,110 in the block and find out what the fees would be. 292 00:13:00,110 --> 00:13:03,900 TADGE DRYJA: Well, if you assume that the block is valid. 293 00:13:03,900 --> 00:13:06,028 So OK, the first transaction is always 294 00:13:06,028 --> 00:13:07,070 the Coinbase transaction. 295 00:13:07,070 --> 00:13:08,300 That's little. 296 00:13:08,300 --> 00:13:10,730 So I'm going to do getrawtransaction, 297 00:13:10,730 --> 00:13:11,990 get this one. 298 00:13:14,510 --> 00:13:16,940 And yeah, it says, Coinbase. 299 00:13:16,940 --> 00:13:20,990 So Coinbase's arbitrary data, you've got a sequence number, 300 00:13:20,990 --> 00:13:24,160 there is no witness here-- 301 00:13:24,160 --> 00:13:28,352 or is-- OK, anyway. 302 00:13:28,352 --> 00:13:29,310 Yeah, there is witness. 303 00:13:29,310 --> 00:13:31,917 OK, so this block is-- 304 00:13:31,917 --> 00:13:33,750 well, two blocks have come out since I first 305 00:13:33,750 --> 00:13:36,520 looked at it, because there's now two confirmations. 306 00:13:39,740 --> 00:13:41,460 This is SegWit-related, which I think 307 00:13:41,460 --> 00:13:43,310 I'm going to talk about Monday. 308 00:13:43,310 --> 00:13:45,500 So that's sort of this weird opportune thing. 309 00:13:45,500 --> 00:13:48,590 This is the actual Coinbase payout 310 00:13:48,590 --> 00:13:54,260 that the miner is getting, and it's 12.79. 311 00:13:54,260 --> 00:14:01,430 So he got almost 0.4 extra coins in fees, which is what, 312 00:14:01,430 --> 00:14:03,890 like $4,000, pretty good. 313 00:14:03,890 --> 00:14:07,720 It was super high a few months ago. 314 00:14:07,720 --> 00:14:10,880 So it all gets aggregated. 315 00:14:10,880 --> 00:14:12,530 12.5 comes out of nowhere. 316 00:14:12,530 --> 00:14:14,900 12.5 is the new coins being generated. 317 00:14:14,900 --> 00:14:20,122 And then the 0.398 is the sum of all the fees in that block. 318 00:14:20,122 --> 00:14:23,060 AUDIENCE: I guess you don't know [INAUDIBLE] 319 00:14:23,060 --> 00:14:25,560 TADGE DRYJA: Well, you have to look at all the transactions. 320 00:14:25,560 --> 00:14:27,270 So if you look at a transaction, it 321 00:14:27,270 --> 00:14:29,063 doesn't say in the transaction itself. 322 00:14:29,063 --> 00:14:30,480 You have to look at a transaction, 323 00:14:30,480 --> 00:14:34,200 look up its inputs, see the sum of all the inputs, 324 00:14:34,200 --> 00:14:35,880 and then subtract and say, OK, I can 325 00:14:35,880 --> 00:14:37,548 calculate the fee for this transaction, 326 00:14:37,548 --> 00:14:39,840 calculate the fee for all these different transactions, 327 00:14:39,840 --> 00:14:42,250 add it all up, it should equal-- 328 00:14:42,250 --> 00:14:47,980 and it does exactly equal 0.398 da da da da. 329 00:14:47,980 --> 00:14:51,690 So for the computer, it's pretty quick. 330 00:14:51,690 --> 00:14:53,610 But yeah, it is a little bit weird accounting 331 00:14:53,610 --> 00:14:56,730 to try to add it all up yourself. 332 00:14:56,730 --> 00:15:00,960 Any other questions about fee stuff, about this? 333 00:15:00,960 --> 00:15:01,473 Yes. 334 00:15:01,473 --> 00:15:03,390 AUDIENCE: Do miners choose what blocks to mine 335 00:15:03,390 --> 00:15:05,016 based on their [INAUDIBLE]? 336 00:15:07,770 --> 00:15:10,920 TADGE DRYJA: Yes, but I'm not sure I'd put it that way. 337 00:15:10,920 --> 00:15:13,440 The miners construct the block to mine. 338 00:15:13,440 --> 00:15:16,240 So in the case of-- 339 00:15:16,240 --> 00:15:21,340 here, getblock head dash 30, I don't want to show all of the-- 340 00:15:21,340 --> 00:15:25,820 but this is, OK, the miner mined this block. 341 00:15:25,820 --> 00:15:30,550 Here's the size, weight, height, version, vertical route. 342 00:15:30,550 --> 00:15:32,530 All these transactions that get included 343 00:15:32,530 --> 00:15:34,960 are produced by the miner. 344 00:15:34,960 --> 00:15:38,620 So the miner sort of aggregates the transactions themselves, 345 00:15:38,620 --> 00:15:40,120 and then decides to mine. 346 00:15:40,120 --> 00:15:43,980 So I think I talk about that in the next-- 347 00:15:43,980 --> 00:15:45,320 wait, do I say that? 348 00:15:45,320 --> 00:15:46,640 Yeah, OK. 349 00:15:46,640 --> 00:15:48,390 I'll talk about that in the next slide. 350 00:15:48,390 --> 00:15:52,590 So basically the fee rate is set by the transaction signer. 351 00:15:52,590 --> 00:15:54,460 When you're creating a transaction-- 352 00:15:54,460 --> 00:15:59,700 OK, I want to sign one Bitcoin, I will spend 500 Satoshis, 353 00:15:59,700 --> 00:16:02,040 my transaction is about 250 bytes, OK, 354 00:16:02,040 --> 00:16:04,610 that's a two-Satoshis-per-byte fee rate. 355 00:16:07,470 --> 00:16:09,323 You choose your fee rate, sign-- 356 00:16:09,323 --> 00:16:11,490 the way you increment and decrement your fee rate is 357 00:16:11,490 --> 00:16:13,860 to say, OK, I've got some change output, 358 00:16:13,860 --> 00:16:16,050 I'm going to increase or decrease the change output 359 00:16:16,050 --> 00:16:16,740 amount. 360 00:16:16,740 --> 00:16:19,020 If someone's saying, hey, pay me one coin, 361 00:16:19,020 --> 00:16:21,420 I can't really change their amount 362 00:16:21,420 --> 00:16:23,870 and say, like, oh, sorry man, there was a high fee, 363 00:16:23,870 --> 00:16:26,300 you didn't get a bitcoin. 364 00:16:26,300 --> 00:16:29,850 And that's sort of a cultural-- that's not a software thing. 365 00:16:29,850 --> 00:16:33,060 If someone says, pay me a coin, you need to pay the coin. 366 00:16:33,060 --> 00:16:36,240 It's generally the sender who's covering the fee. 367 00:16:36,240 --> 00:16:39,270 Which is different than in credit cards, right? 368 00:16:39,270 --> 00:16:42,630 In credit cards, it says $10, I swipe my card, 369 00:16:42,630 --> 00:16:45,150 I get charged $10, and the merchant 370 00:16:45,150 --> 00:16:47,407 is the one absorbing the fee. 371 00:16:47,407 --> 00:16:48,990 And I don't even know what the fee is. 372 00:16:48,990 --> 00:16:51,750 There's actually contractual law that I'm not 373 00:16:51,750 --> 00:16:54,360 allowed to hear what the fee is, the merchant can't tell me, 374 00:16:54,360 --> 00:16:55,710 things like that. 375 00:16:55,710 --> 00:16:58,320 But in general, in Bitcoin, this fee is set by the sender. 376 00:17:01,043 --> 00:17:03,210 The transactions, however, are chosen by the miners. 377 00:17:03,210 --> 00:17:06,349 So the idea is, you create your transaction, set your fee, 378 00:17:06,349 --> 00:17:09,319 throw it out there, everyone sort of broadcasts 379 00:17:09,319 --> 00:17:10,849 it to everyone else. 380 00:17:10,849 --> 00:17:13,940 And the miner then looks at all these fees, 381 00:17:13,940 --> 00:17:17,480 looks at all these transactions, and chooses the best ones. 382 00:17:17,480 --> 00:17:18,950 It's essentially an auction process 383 00:17:18,950 --> 00:17:21,950 where you're bidding for us for space in a future block that 384 00:17:21,950 --> 00:17:24,460 has not yet been created. 385 00:17:24,460 --> 00:17:28,890 So the simplest miner-side algorithm is, take the mempool, 386 00:17:28,890 --> 00:17:32,190 sort the mempool transactions by their fee rate, 387 00:17:32,190 --> 00:17:36,330 choose the top megabyte, put them all in order, 388 00:17:36,330 --> 00:17:39,330 compute a merkle route from all those transaction IDs, 389 00:17:39,330 --> 00:17:40,920 and then mine it. 390 00:17:40,920 --> 00:17:45,160 So the-- yeah, I explained the merkle route stuff, right? 391 00:17:45,160 --> 00:17:49,500 So you're going to pick a couple thousand-- 392 00:17:49,500 --> 00:17:53,440 5,000, maybe-- transactions, sort them by fee rate, 393 00:17:53,440 --> 00:17:56,910 put them all in a row, hash it a bunch of times, 394 00:17:56,910 --> 00:17:59,642 and then just that 80-byte header you keep mining. 395 00:17:59,642 --> 00:18:00,850 However, this keeps changing. 396 00:18:00,850 --> 00:18:03,060 This mempool changes every second. 397 00:18:03,060 --> 00:18:06,503 There's new transactions coming up multiple times a second. 398 00:18:06,503 --> 00:18:08,670 And so you're going to re-compute that every second, 399 00:18:08,670 --> 00:18:11,760 probably, and say, oh, this new transaction came out, 400 00:18:11,760 --> 00:18:14,460 oh, the fee's really low, ignore it, 401 00:18:14,460 --> 00:18:16,980 that doesn't meet my threshold. 402 00:18:16,980 --> 00:18:19,020 Versus, new transaction comes out, oh, it's 403 00:18:19,020 --> 00:18:22,980 got a really high fee rate, OK, put it in near the top, 404 00:18:22,980 --> 00:18:26,445 and push out one or two transactions at the bottom. 405 00:18:26,445 --> 00:18:29,070 And now I'm mining a block that will have slightly higher fees. 406 00:18:29,070 --> 00:18:31,470 So this is sort of a real-time process, where 407 00:18:31,470 --> 00:18:33,450 this is constantly changing. 408 00:18:33,450 --> 00:18:35,640 The mining is even faster, so you're 409 00:18:35,640 --> 00:18:38,610 going to mine trillions and trillions of attempts 410 00:18:38,610 --> 00:18:41,018 for each specific merkle route. 411 00:18:41,018 --> 00:18:43,560 But the merkle routes are also going to change multiple times 412 00:18:43,560 --> 00:18:44,900 a second. 413 00:18:44,900 --> 00:18:48,480 The nonce is going to change a gazillion times a second. 414 00:18:48,480 --> 00:18:48,980 Yes. 415 00:18:48,980 --> 00:18:50,688 AUDIENCE: How do you know that you're not 416 00:18:50,688 --> 00:18:53,295 mining a stale transaction? 417 00:18:53,295 --> 00:18:55,170 TADGE DRYJA: So you know it's in the mempool, 418 00:18:55,170 --> 00:18:56,730 you know it hasn't been-- 419 00:18:56,730 --> 00:18:58,260 well, you don't know, you're pretty 420 00:18:58,260 --> 00:19:02,760 sure that it has not been confirmed in a block already. 421 00:19:02,760 --> 00:19:04,807 But it may be the case that someone just came out 422 00:19:04,807 --> 00:19:07,140 with a block a few seconds ago, and you haven't seen it, 423 00:19:07,140 --> 00:19:11,620 and then you are mining a stale transaction. 424 00:19:11,620 --> 00:19:13,670 The thing is, whether the transaction is stale 425 00:19:13,670 --> 00:19:19,450 or not, even if you mine a block and it's 426 00:19:19,450 --> 00:19:21,670 got a completely different set of transactions 427 00:19:21,670 --> 00:19:25,930 than the block you were unaware of, you still lose out. 428 00:19:25,930 --> 00:19:29,020 Because you're pointing-- so OK, this comes out, 429 00:19:29,020 --> 00:19:32,200 but you're not aware of it yet, and you mine this. 430 00:19:32,200 --> 00:19:36,780 Even if they have a completely disjoint set of transactions, 431 00:19:36,780 --> 00:19:38,780 it doesn't matter because they're still pointing 432 00:19:38,780 --> 00:19:40,490 to the same parent block. 433 00:19:40,490 --> 00:19:44,060 So you still, now, have two blocks of the same height. 434 00:19:44,060 --> 00:19:45,530 You might win. 435 00:19:45,530 --> 00:19:49,580 If this happens, hey, maybe this one gets built upon. 436 00:19:49,580 --> 00:19:54,170 Generally, miners pick the first seen block to build off of. 437 00:19:54,170 --> 00:19:57,800 But you could change that. 438 00:19:57,800 --> 00:19:59,882 And you can't really verify that that's the case. 439 00:19:59,882 --> 00:20:01,340 So yeah, it is possible that you're 440 00:20:01,340 --> 00:20:02,960 mining transactions that have already 441 00:20:02,960 --> 00:20:05,010 been included in the block that you're not aware. 442 00:20:05,010 --> 00:20:05,510 Yes. 443 00:20:05,510 --> 00:20:07,843 AUDIENCE: Because blocks are changing all the time based 444 00:20:07,843 --> 00:20:10,190 on the transactions you want to put in it, 445 00:20:10,190 --> 00:20:12,856 are you kind of mining different blocks at the same time? 446 00:20:12,856 --> 00:20:15,800 So the first one, you try-- have started mining, 447 00:20:15,800 --> 00:20:17,302 do you keep mining that one or no? 448 00:20:17,302 --> 00:20:18,260 TADGE DRYJA: You could. 449 00:20:18,260 --> 00:20:22,580 So in practice, probably yes, but on a very small timescale. 450 00:20:22,580 --> 00:20:27,250 So what you'll have is we'll get block template, you'll have-- 451 00:20:27,250 --> 00:20:28,840 it's like network latency. 452 00:20:28,840 --> 00:20:31,960 So you'll have, let's say, a bunch of different warehouses 453 00:20:31,960 --> 00:20:34,660 that all have thousands and thousands of these mining 454 00:20:34,660 --> 00:20:35,560 chips. 455 00:20:35,560 --> 00:20:37,390 And they will connect in, and they'll 456 00:20:37,390 --> 00:20:42,070 pull every second or so, and get the current transaction 457 00:20:42,070 --> 00:20:43,270 list to mine. 458 00:20:43,270 --> 00:20:44,950 And that'll get updated every second. 459 00:20:44,950 --> 00:20:49,870 And so there may be sort of lags between different warehouses, 460 00:20:49,870 --> 00:20:52,420 between different machines, that are mining slightly 461 00:20:52,420 --> 00:20:54,500 different sets of transactions. 462 00:20:54,500 --> 00:20:56,500 But generally, they're going to be synchronized. 463 00:20:56,500 --> 00:20:58,090 Over the same time scale of a few seconds, 464 00:20:58,090 --> 00:20:59,632 they're all going to be synchronized. 465 00:21:02,768 --> 00:21:04,560 They're going to be updated pretty quickly. 466 00:21:04,560 --> 00:21:06,603 Because every time a new transaction comes in, 467 00:21:06,603 --> 00:21:08,520 that's potentially more fees that you can get. 468 00:21:08,520 --> 00:21:11,280 So you want to push that out and update it. 469 00:21:11,280 --> 00:21:14,100 Let's say a transaction comes in that's got a nice $5.00 fee, 470 00:21:14,100 --> 00:21:17,010 and you can push out some $4.00 fee transactions, 471 00:21:17,010 --> 00:21:18,240 that's an extra buck. 472 00:21:18,240 --> 00:21:21,060 And if you don't get it in time, and mine a block anyway, 473 00:21:21,060 --> 00:21:25,230 hey, you still mined a buck, but that $5 fee transaction now 474 00:21:25,230 --> 00:21:28,140 goes to the next person mining the block. 475 00:21:28,140 --> 00:21:32,610 So you want to minimize your latency so that you get things 476 00:21:32,610 --> 00:21:33,900 as quickly as possible. 477 00:21:33,900 --> 00:21:37,320 But there will be some skew. 478 00:21:37,320 --> 00:21:37,960 Yes. 479 00:21:37,960 --> 00:21:39,360 AUDIENCE: How does mining stale transactions 480 00:21:39,360 --> 00:21:41,340 affect the block order and block transaction fees? 481 00:21:41,340 --> 00:21:42,570 TADGE DRYJA: Sorry, mining what transactions? 482 00:21:42,570 --> 00:21:44,040 AUDIENCE: Stale transactions. 483 00:21:44,040 --> 00:21:45,660 TADGE DRYJA: If you have-- 484 00:21:45,660 --> 00:21:47,020 wait, wait. 485 00:21:47,020 --> 00:21:47,640 OK, wait. 486 00:21:47,640 --> 00:21:49,365 Stale transactions? 487 00:21:49,365 --> 00:21:51,240 A transaction that's already been in a block? 488 00:21:51,240 --> 00:21:51,660 AUDIENCE: Yeah. 489 00:21:51,660 --> 00:21:53,702 TADGE DRYJA: It just invalidates the whole thing. 490 00:21:53,702 --> 00:21:55,530 If you have if you have a transaction here 491 00:21:55,530 --> 00:21:58,380 that was already confirmed here, this block is invalid, 492 00:21:58,380 --> 00:21:59,550 and no one will-- 493 00:21:59,550 --> 00:22:01,400 they'll just drop it. 494 00:22:01,400 --> 00:22:06,900 So stale transaction isn't really a term. 495 00:22:06,900 --> 00:22:08,910 It's a stale block. 496 00:22:08,910 --> 00:22:11,250 This is a stale block because, well, someone made it, 497 00:22:11,250 --> 00:22:15,330 but it got orphaned out, and no one's using it. 498 00:22:15,330 --> 00:22:18,140 AUDIENCE: So the answer is, there's no reward for that, 499 00:22:18,140 --> 00:22:19,428 right? 500 00:22:19,428 --> 00:22:20,220 TADGE DRYJA: Worse. 501 00:22:20,220 --> 00:22:21,270 You lose all your-- 502 00:22:21,270 --> 00:22:23,350 you lose everything. 503 00:22:23,350 --> 00:22:26,370 So if there's transaction A in here, 504 00:22:26,370 --> 00:22:29,520 and you try to include transaction A in here, 505 00:22:29,520 --> 00:22:31,200 the block itself is invalid, even 506 00:22:31,200 --> 00:22:32,760 if it has valid proof of work. 507 00:22:32,760 --> 00:22:36,600 So you lose everything. 508 00:22:36,600 --> 00:22:39,180 The thing is, in practice, it's not a problem. 509 00:22:39,180 --> 00:22:43,110 Because you're pointing to this block, 510 00:22:43,110 --> 00:22:45,187 so you must have already seen it. 511 00:22:45,187 --> 00:22:47,520 So it's really easy to just say, well, don't include any 512 00:22:47,520 --> 00:22:51,040 of the transactions in here. 513 00:22:51,040 --> 00:22:53,180 OK, wait, sometimes it's a little complicated. 514 00:22:53,180 --> 00:22:56,580 Sometimes you see this block, and then 515 00:22:56,580 --> 00:22:59,220 you immediately want to start mining the block on top of it. 516 00:22:59,220 --> 00:23:03,270 But it's a fraction of a second, and you haven't actually 517 00:23:03,270 --> 00:23:04,488 validated it. 518 00:23:04,488 --> 00:23:06,030 And you don't even know what's in it. 519 00:23:06,030 --> 00:23:09,030 Maybe you only have the 80-byte header. 520 00:23:09,030 --> 00:23:12,870 So one optimization which is sort of bad in a way 521 00:23:12,870 --> 00:23:16,290 but optimal for the miners is build a block 522 00:23:16,290 --> 00:23:17,893 that's empty on top of it. 523 00:23:17,893 --> 00:23:20,310 You haven't even seen what transactions are in this block. 524 00:23:20,310 --> 00:23:21,870 You don't even know if it's valid. 525 00:23:21,870 --> 00:23:24,507 But it's probably valid, because most blocks are. 526 00:23:24,507 --> 00:23:27,090 And so what you do is you build on top of it, you point to it, 527 00:23:27,090 --> 00:23:29,298 but since you don't know what transactions are in it, 528 00:23:29,298 --> 00:23:31,830 the safest thing is just to include no transactions in your 529 00:23:31,830 --> 00:23:33,900 so there's no overlap. 530 00:23:33,900 --> 00:23:36,840 And you only do this for a fraction of a second 531 00:23:36,840 --> 00:23:40,050 until you've figured out the Transaction List here 532 00:23:40,050 --> 00:23:41,550 and subtracted all the-- 533 00:23:41,550 --> 00:23:45,150 removed all those from your set. 534 00:23:45,150 --> 00:23:49,710 But it saves you maybe 1/10 of a second, 1/20, whatever it is. 535 00:23:49,710 --> 00:23:53,010 Which, over time, statistically, you 536 00:23:53,010 --> 00:23:55,530 could be mining in that 1/10 of a second. 537 00:23:55,530 --> 00:23:57,030 You don't you want your chips to not 538 00:23:57,030 --> 00:24:00,480 be doing anything productive for those fractions of a second. 539 00:24:00,480 --> 00:24:02,470 So that does happen. 540 00:24:02,470 --> 00:24:06,270 That is not software that's in the normal Bitcoin D, 541 00:24:06,270 --> 00:24:09,210 but miners have written their own software to do that. 542 00:24:09,210 --> 00:24:12,120 And so you will occasionally see completely empty blocks 543 00:24:12,120 --> 00:24:14,010 with just a Coinbase transaction. 544 00:24:14,010 --> 00:24:17,850 And they're almost always very soon after the previous block, 545 00:24:17,850 --> 00:24:20,160 where you see one that comes out at 10:30 546 00:24:20,160 --> 00:24:24,690 and 27 seconds, 10:30 and 29 seconds, and it's empty. 547 00:24:24,690 --> 00:24:28,980 So that does happen, and that can work. 548 00:24:28,980 --> 00:24:31,710 Although what was it, two years ago 549 00:24:31,710 --> 00:24:35,210 that happened, where a miner mined 550 00:24:35,210 --> 00:24:37,230 a blocked that was invalid. 551 00:24:37,230 --> 00:24:39,810 Another miner mined a block here, 552 00:24:39,810 --> 00:24:42,032 very quickly, that was empty. 553 00:24:42,032 --> 00:24:44,240 And then a bunch of miners started building off of it 554 00:24:44,240 --> 00:24:46,140 because they're like, well, this one looks valid, 555 00:24:46,140 --> 00:24:47,390 there's no transactions in it. 556 00:24:47,390 --> 00:24:49,610 And they mined like six or seven blocks in a row, 557 00:24:49,610 --> 00:24:53,300 and the whole thing was just invalid. 558 00:24:53,300 --> 00:24:57,290 Because they figured, the stuff I'm building off of must be OK. 559 00:24:57,290 --> 00:24:59,630 So they lost some money there. 560 00:24:59,630 --> 00:25:02,770 This makes sense, right? 561 00:25:02,770 --> 00:25:05,610 Sort the mempool by fee rate, choose the top megabyte, 562 00:25:05,610 --> 00:25:07,140 compute a merkle route, mine. 563 00:25:07,140 --> 00:25:10,070 Why is it not this simple? 564 00:25:10,070 --> 00:25:12,990 And I mean on an algorithmic way. 565 00:25:12,990 --> 00:25:15,970 If you're just like, yeah, sort, choose fee rate, 566 00:25:15,970 --> 00:25:18,480 sort, quick-sort or whatever, that's 567 00:25:18,480 --> 00:25:20,910 super quick, and then mine. 568 00:25:20,910 --> 00:25:24,600 Why is it actually, complexity-wise, not-- 569 00:25:24,600 --> 00:25:26,940 what is it, n log n for quick-sort? 570 00:25:26,940 --> 00:25:29,662 It's definitely not n log n for the optimal. 571 00:25:29,662 --> 00:25:32,120 Although, wait, quick-sort is worst-case scenario n-squared 572 00:25:32,120 --> 00:25:33,470 [INAUDIBLE] right? 573 00:25:33,470 --> 00:25:35,150 No, it's way worse than n-squared. 574 00:25:35,150 --> 00:25:38,280 Anyway, any guesses onto why the algorithmic complexity 575 00:25:38,280 --> 00:25:41,123 is actually quite a bit worse? 576 00:25:41,123 --> 00:25:44,350 AUDIENCE: Is it because the example keeps on changing? 577 00:25:44,350 --> 00:25:46,100 TADGE DRYJA: No, I'm saying, even at any-- 578 00:25:46,100 --> 00:25:48,190 yeah, that changes it over time. 579 00:25:48,190 --> 00:25:51,020 But at any one state, let's say, here's a mempool, 580 00:25:51,020 --> 00:25:57,135 find the optimal transaction set to put into your block. 581 00:25:57,135 --> 00:25:58,970 AUDIENCE: Because Bitcoin is slow to search, 582 00:25:58,970 --> 00:26:03,100 so you have to go into each transaction and find the fee? 583 00:26:03,100 --> 00:26:06,650 TADGE DRYJA: Yeah, but that's still n log n, right? 584 00:26:06,650 --> 00:26:08,870 Yeah, just because the look-up is slower, 585 00:26:08,870 --> 00:26:10,886 that doesn't change the O. 586 00:26:10,886 --> 00:26:12,886 AUDIENCE: The problem is [INAUDIBLE] because you 587 00:26:12,886 --> 00:26:14,690 have to find [INAUDIBLE]. 588 00:26:14,690 --> 00:26:17,100 TADGE DRYJA: Yeah, so there's dependencies. 589 00:26:17,100 --> 00:26:20,130 So the thing is, there may be a transaction-- you can't just 590 00:26:20,130 --> 00:26:22,642 take all these transactions independently and sort them. 591 00:26:22,642 --> 00:26:24,600 There may be a transaction with a very high fee 592 00:26:24,600 --> 00:26:28,020 rate which depends on a transaction with a very low fee 593 00:26:28,020 --> 00:26:29,280 rate. 594 00:26:29,280 --> 00:26:31,620 And so you know it's spending an output that hasn't yet 595 00:26:31,620 --> 00:26:32,680 been created. 596 00:26:32,680 --> 00:26:34,560 So now it becomes-- 597 00:26:34,560 --> 00:26:35,640 it's NP-hard. 598 00:26:35,640 --> 00:26:38,730 In practice, the heuristics are fine. 599 00:26:38,730 --> 00:26:41,850 But it is pretty ugly in that you're 600 00:26:41,850 --> 00:26:44,853 like, well, this transaction has a very low fee, 601 00:26:44,853 --> 00:26:46,020 I'm not going to include it. 602 00:26:46,020 --> 00:26:48,720 This transaction that depends on it has a high fee rate. 603 00:26:48,720 --> 00:26:52,140 Now I have to take the sort of mean of the two fee rates, 604 00:26:52,140 --> 00:26:54,540 and keep computing those things. 605 00:26:54,540 --> 00:26:55,980 So it can get quite complex. 606 00:26:55,980 --> 00:26:57,482 In practice, it's usually OK. 607 00:26:57,482 --> 00:26:59,190 You have some heuristics in the code that 608 00:26:59,190 --> 00:27:00,790 sort of don't deal with that. 609 00:27:00,790 --> 00:27:04,050 Also, I think you have max-- 610 00:27:04,050 --> 00:27:06,870 there's no hard rule, but the algorithms that mine usually 611 00:27:06,870 --> 00:27:11,790 have a max depth of like three or four transactions, 612 00:27:11,790 --> 00:27:14,130 where they say, look, if there's a chain of like four 613 00:27:14,130 --> 00:27:16,500 dependent transactions, I'm not going 614 00:27:16,500 --> 00:27:18,690 to keep going down that path. 615 00:27:18,690 --> 00:27:21,270 Because you could potentially have enormous chains, 616 00:27:21,270 --> 00:27:24,610 where you have 100 transactions, each depending on another. 617 00:27:24,610 --> 00:27:27,090 And then the one at the very end has a very high fee rate, 618 00:27:27,090 --> 00:27:29,090 and you're going to have to go through all this. 619 00:27:29,090 --> 00:27:31,260 So they limit their search to like four or something 620 00:27:31,260 --> 00:27:32,630 like that. 621 00:27:32,630 --> 00:27:33,550 Oh, sorry. 622 00:27:33,550 --> 00:27:37,140 Yeah, so the TX dependencies make it kind of hard. 623 00:27:37,140 --> 00:27:39,970 Cheap transaction which allows an expensive transaction 624 00:27:39,970 --> 00:27:44,380 to be confirmed, we call this Child Pays for Parent, 625 00:27:44,380 --> 00:27:45,890 in that you've got this-- 626 00:27:45,890 --> 00:27:47,950 in a graph, you've a child transaction, 627 00:27:47,950 --> 00:27:50,200 and it's essentially paying for the parent transaction 628 00:27:50,200 --> 00:27:53,020 by having a higher fee. 629 00:27:53,020 --> 00:27:56,475 There is no Parent Pays for Child, 630 00:27:56,475 --> 00:27:58,600 in that if you've got a transaction with a high fee 631 00:27:58,600 --> 00:28:01,390 rate, and then a descendant transaction with a low fee 632 00:28:01,390 --> 00:28:03,460 rate, you just take the parent and you ignore 633 00:28:03,460 --> 00:28:06,670 the child and someone else in a later block 634 00:28:06,670 --> 00:28:08,810 can grab that child transaction. 635 00:28:08,810 --> 00:28:10,695 However, the dependency graph is, 636 00:28:10,695 --> 00:28:12,070 no, if you want in on this child, 637 00:28:12,070 --> 00:28:14,300 the parent has to be confirmed first. 638 00:28:14,300 --> 00:28:17,740 It actually has to be confirmed earlier in the list of TXIDs 639 00:28:17,740 --> 00:28:18,730 in the block. 640 00:28:18,730 --> 00:28:22,730 So it's not-- so like in this, when you look at a block, 641 00:28:22,730 --> 00:28:24,820 the transactions are sequenced. 642 00:28:24,820 --> 00:28:28,480 And this transaction can spend that transaction. 643 00:28:28,480 --> 00:28:32,200 But you need to be able to go in through linearly. 644 00:28:32,200 --> 00:28:34,750 Update your UTXO set at every row here, 645 00:28:34,750 --> 00:28:36,283 and it should be consistent. 646 00:28:36,283 --> 00:28:37,450 AUDIENCE: I have a question. 647 00:28:37,450 --> 00:28:38,158 TADGE DRYJA: Yes. 648 00:28:38,158 --> 00:28:41,820 AUDIENCE: You mentioned LVIV, those are [INAUDIBLE] terms. 649 00:28:41,820 --> 00:28:43,330 You mentioned a threshold earlier. 650 00:28:43,330 --> 00:28:45,430 How is that threshold determined? 651 00:28:45,430 --> 00:28:49,817 TADGE DRYJA: Oh, OK, so there isn't really a threshold. 652 00:28:49,817 --> 00:28:52,150 It's just at any point, you're looking, and you're like, 653 00:28:52,150 --> 00:28:57,460 well, my minimum fee here is 30 Satoshis per byte. 654 00:28:57,460 --> 00:29:00,610 Given the block I'm trying to mine, what's my lowest fee? 655 00:29:00,610 --> 00:29:01,780 OK, 30 Satoshis per byte. 656 00:29:01,780 --> 00:29:03,280 So if I see one with less than that, 657 00:29:03,280 --> 00:29:06,387 I know right away I can ignore it. 658 00:29:06,387 --> 00:29:07,970 But yeah, it keeps changing every time 659 00:29:07,970 --> 00:29:10,940 a new transaction comes in that displaces an old one, now 660 00:29:10,940 --> 00:29:12,448 your minimum fee changes. 661 00:29:12,448 --> 00:29:14,240 So that's just sort of an easy way to look. 662 00:29:14,240 --> 00:29:18,740 There is also a relay threshold which I believe most nodes now 663 00:29:18,740 --> 00:29:22,400 have at one Satoshi per byte, where if you're not mining 664 00:29:22,400 --> 00:29:24,920 and someone gives you a transaction which is less than 665 00:29:24,920 --> 00:29:28,910 one-Satoshi-per-byte fee rate, you will ignore it and not pass 666 00:29:28,910 --> 00:29:30,470 it on to your peers. 667 00:29:30,470 --> 00:29:33,250 That's sort of an anti-spam kind of thing. 668 00:29:33,250 --> 00:29:34,760 And it may be too high. 669 00:29:34,760 --> 00:29:36,470 It's also not a consensus rule, and you 670 00:29:36,470 --> 00:29:39,620 can set it to whatever you want in your config file. 671 00:29:39,620 --> 00:29:41,600 And nodes won't get mad at you. 672 00:29:41,600 --> 00:29:44,120 They won't ban you if you send something low. 673 00:29:44,120 --> 00:29:45,830 So that's sort of from the miner's side. 674 00:29:45,830 --> 00:29:48,050 From the miner's point of view, you 675 00:29:48,050 --> 00:29:51,140 keep seeing all these transactions, you sort them, 676 00:29:51,140 --> 00:29:54,410 you have to deal with the sort of descendent transactions. 677 00:29:54,410 --> 00:29:56,820 But you try to get a good block, try to mine it. 678 00:29:56,820 --> 00:29:58,820 And you don't really care what people are doing, 679 00:29:58,820 --> 00:30:00,362 you just want to make a lot of money. 680 00:30:00,362 --> 00:30:02,870 You just want to maximize for fees. 681 00:30:02,870 --> 00:30:05,450 From the person transacting, on their side, 682 00:30:05,450 --> 00:30:06,722 you want to minimize fees. 683 00:30:06,722 --> 00:30:08,180 You don't want to pay these miners. 684 00:30:08,180 --> 00:30:09,620 They already make gazillions of dollars 685 00:30:09,620 --> 00:30:11,287 anyway from all the new bitcoins they're 686 00:30:11,287 --> 00:30:13,310 generating-- bunch of jerks. 687 00:30:13,310 --> 00:30:16,750 So you set your fee to one Satoshi per byte. 688 00:30:16,750 --> 00:30:20,110 So you know it'll be relayed, you sign it, and you broadcast. 689 00:30:20,110 --> 00:30:21,710 Easy, right? 690 00:30:21,710 --> 00:30:22,940 So what's the problem here? 691 00:30:26,050 --> 00:30:26,550 Nobody-- 692 00:30:26,550 --> 00:30:27,690 AUDIENCE: [INAUDIBLE] 693 00:30:27,690 --> 00:30:30,030 TADGE DRYJA: Doesn't confirm, all the miners ignore it. 694 00:30:30,030 --> 00:30:32,670 This is actually a huge-- 695 00:30:32,670 --> 00:30:34,740 well, OK, no, probably the biggest sort 696 00:30:34,740 --> 00:30:37,110 of UI problem in Bitcoin is that people 697 00:30:37,110 --> 00:30:39,030 have, for years and years, lost all 698 00:30:39,030 --> 00:30:41,820 of their coins due to theft, or loss, or whatever. 699 00:30:41,820 --> 00:30:42,690 That's the big one. 700 00:30:42,690 --> 00:30:46,140 But other than that, this is the biggest UI problem. 701 00:30:46,140 --> 00:30:48,440 This is the biggest problem in Bitcoin for users. 702 00:30:48,440 --> 00:30:52,260 I made a transaction, it hasn't confirmed, what the heck? 703 00:30:52,260 --> 00:30:56,790 And I sort of had, on Reddit, BTC fees, WTF. 704 00:30:56,790 --> 00:30:57,830 [CHUCKLING] 705 00:30:57,830 --> 00:31:00,300 Like, why are BTC fees so high? 706 00:31:00,300 --> 00:31:03,150 There's constant people complaining, what the heck, 707 00:31:03,150 --> 00:31:03,960 why-- 708 00:31:03,960 --> 00:31:05,520 are you kidding me? 709 00:31:05,520 --> 00:31:06,730 Trezor says $50 in fees. 710 00:31:06,730 --> 00:31:08,010 Am I missing something? 711 00:31:08,010 --> 00:31:09,990 People get mad. 712 00:31:09,990 --> 00:31:13,050 And then there's also, I made a transaction last week, 713 00:31:13,050 --> 00:31:15,300 it hasn't confirmed. 714 00:31:15,300 --> 00:31:16,290 Bitcoin doesn't work. 715 00:31:16,290 --> 00:31:17,070 Bitcoin sucks. 716 00:31:17,070 --> 00:31:18,720 I hate this thing. 717 00:31:18,720 --> 00:31:23,750 So huge UI problem, really poor user experience. 718 00:31:23,750 --> 00:31:26,280 A lot of it is, also, the software is bad. 719 00:31:26,280 --> 00:31:28,850 Wallets-- OK, a couple of years ago, 720 00:31:28,850 --> 00:31:31,070 wallets would always just set a zero fee. 721 00:31:31,070 --> 00:31:33,890 There weren't fees in 2012. 722 00:31:33,890 --> 00:31:35,120 You just didn't pay any-- 723 00:31:35,120 --> 00:31:37,820 2013, right? 724 00:31:37,820 --> 00:31:38,840 I never paid fees. 725 00:31:38,840 --> 00:31:40,430 It was awesome. 726 00:31:40,430 --> 00:31:42,830 Because there was this block-size limit of one 727 00:31:42,830 --> 00:31:43,730 megabyte. 728 00:31:43,730 --> 00:31:46,970 But no one was ever running up against that limit. 729 00:31:46,970 --> 00:31:49,230 The miners would just say, look, I'm not even 730 00:31:49,230 --> 00:31:53,230 going to sort anything because there's 731 00:31:53,230 --> 00:31:56,000 200 kilobytes worth of transactions in the mempool. 732 00:31:56,000 --> 00:31:58,622 I just mine all of them, whether the fees are zero, 733 00:31:58,622 --> 00:32:00,830 whether the fees are one Satoshi, whatever-- whatever 734 00:32:00,830 --> 00:32:02,450 I can get, just mine it all. 735 00:32:02,450 --> 00:32:04,730 Now you've got this constrained space, 736 00:32:04,730 --> 00:32:06,290 and so you're optimizing-- 737 00:32:06,290 --> 00:32:07,070 the miner is. 738 00:32:07,070 --> 00:32:08,480 But years ago, you weren't. 739 00:32:08,480 --> 00:32:11,420 And so the wallets, a lot of times, 740 00:32:11,420 --> 00:32:14,590 they would either have zero fee, completely, 741 00:32:14,590 --> 00:32:17,240 a fixed fee per transaction, which 742 00:32:17,240 --> 00:32:18,860 is also really suboptimal-- they just 743 00:32:18,860 --> 00:32:21,560 say, OK, I'll pay 100 hundreds Satoshi per transaction. 744 00:32:21,560 --> 00:32:24,710 Some transactions have a lot of inputs, are much bigger, 745 00:32:24,710 --> 00:32:27,320 so that's a highly variable fee rate which 746 00:32:27,320 --> 00:32:28,442 the user can't control. 747 00:32:28,442 --> 00:32:30,650 Or they'd have a fixed fee rate, where they just say, 748 00:32:30,650 --> 00:32:32,980 I'm going to set five Satoshis per byte, 749 00:32:32,980 --> 00:32:34,700 and that's the fee rate in this wallet, 750 00:32:34,700 --> 00:32:37,100 and you don't allow the user to change it at all. 751 00:32:37,100 --> 00:32:38,360 That's also really suboptimal. 752 00:32:38,360 --> 00:32:40,880 Once the fee market starts changing 753 00:32:40,880 --> 00:32:44,690 and people start paying more, this wallet software 754 00:32:44,690 --> 00:32:45,680 will not work. 755 00:32:45,680 --> 00:32:48,440 Or you can have the user choose a fee rate, which seems great, 756 00:32:48,440 --> 00:32:51,080 but users are like, I don't know. 757 00:32:51,080 --> 00:32:53,760 You're using Bitcoin, what fee rate do you want, 758 00:32:53,760 --> 00:32:57,120 10 Satoshis per byte, 20, 40, 70? 759 00:32:57,120 --> 00:32:58,040 What's a Satoshi? 760 00:32:58,040 --> 00:33:00,020 What's a byte? 761 00:33:00,020 --> 00:33:02,600 This is not a great problem to hand off to the user. 762 00:33:02,600 --> 00:33:05,217 How do I even determine this? 763 00:33:05,217 --> 00:33:07,550 There are sites, and the sites aren't very good, either. 764 00:33:07,550 --> 00:33:13,310 Where was it-- yeah, here is what used to be 21.co, 765 00:33:13,310 --> 00:33:14,840 with all the Raspberry Pi guys. 766 00:33:14,840 --> 00:33:20,150 And then this is their fee rate thing, 767 00:33:20,150 --> 00:33:22,730 which is a really hard-to-understand chart. 768 00:33:22,730 --> 00:33:25,380 What does this mean, unconfirmed transactions, transactions 769 00:33:25,380 --> 00:33:26,210 today? 770 00:33:26,210 --> 00:33:27,310 What are these numbers? 771 00:33:27,310 --> 00:33:29,140 I still don't really understand this site. 772 00:33:29,140 --> 00:33:32,120 And at the bottom it says, fastest and cheapest 773 00:33:32,120 --> 00:33:34,430 transaction fee is 50 Satoshis per byte, 774 00:33:34,430 --> 00:33:36,650 shown in green at the top. 775 00:33:36,650 --> 00:33:40,670 So I guess this, or this. 776 00:33:40,670 --> 00:33:43,430 Thing is, huge overestimate. 777 00:33:43,430 --> 00:33:47,630 I think one Satoshi per byte is probably OK today-- 778 00:33:47,630 --> 00:33:50,400 maybe five. 779 00:33:50,400 --> 00:33:52,680 This is a better site-- also complex-- 780 00:33:52,680 --> 00:33:54,960 where you can say, OK, well, here's 781 00:33:54,960 --> 00:33:58,720 the mempool size in megabytes, sorted by fee rate. 782 00:33:58,720 --> 00:34:01,140 And you can see that, well, at 8 o'clock, 783 00:34:01,140 --> 00:34:03,600 mempool was basically empty. 784 00:34:03,600 --> 00:34:05,280 At 8 o'clock, you could have paid zero 785 00:34:05,280 --> 00:34:07,260 and it would have gotten through, 786 00:34:07,260 --> 00:34:08,699 but people are paying more now. 787 00:34:08,699 --> 00:34:11,580 And it's also kind of crazy to see that some people are paying 788 00:34:11,580 --> 00:34:16,080 200 Satoshis per byte, even though, generally, 789 00:34:16,080 --> 00:34:18,570 over the course of a few hours, zero Satoshis per byte 790 00:34:18,570 --> 00:34:19,830 will also confirm. 791 00:34:19,830 --> 00:34:21,780 Are they really time-sensitive? 792 00:34:21,780 --> 00:34:22,530 Probably not. 793 00:34:22,530 --> 00:34:24,330 Probably, their software is crummy, 794 00:34:24,330 --> 00:34:28,870 and their software just estimates 200. 795 00:34:28,870 --> 00:34:33,979 So it's easy to make fun of people 796 00:34:33,979 --> 00:34:35,710 and be like, these guys are idiots. 797 00:34:35,710 --> 00:34:38,530 It's actually not that easy to estimate what fee you should 798 00:34:38,530 --> 00:34:41,500 issue a transaction with. 799 00:34:41,500 --> 00:34:46,060 It's also sort of asymmetric in that a lot of exchanges, 800 00:34:46,060 --> 00:34:49,870 someone says, I want to withdraw my 10 bitcoins. 801 00:34:49,870 --> 00:34:52,750 I traded, this is a lot of money, withdraw, click. 802 00:34:52,750 --> 00:34:54,340 It doesn't confirm for six hours. 803 00:34:54,340 --> 00:34:56,560 The customer gets super mad and starts 804 00:34:56,560 --> 00:35:00,707 calling customer support. 805 00:35:00,707 --> 00:35:02,290 Whereas if the exchange is like, look, 806 00:35:02,290 --> 00:35:04,332 we're just going to issue all of our transactions 807 00:35:04,332 --> 00:35:06,190 with 200 Satoshis per byte, they always 808 00:35:06,190 --> 00:35:07,630 go through the next block. 809 00:35:07,630 --> 00:35:08,680 Yeah, we lose money. 810 00:35:08,680 --> 00:35:11,470 But maybe we get the customer to pay for it. 811 00:35:11,470 --> 00:35:11,970 Yeah. 812 00:35:11,970 --> 00:35:12,724 AUDIENCE: Do you think it could be 813 00:35:12,724 --> 00:35:15,530 people using maybe percentage of their transactions, 814 00:35:15,530 --> 00:35:18,183 which obviously doesn't make any sense, but-- 815 00:35:18,183 --> 00:35:19,600 TADGE DRYJA: I don't think there's 816 00:35:19,600 --> 00:35:20,480 any software that does that 817 00:35:20,480 --> 00:35:21,094 AUDIENCE: --finance firm, and that's 818 00:35:21,094 --> 00:35:22,662 just what they're used to. 819 00:35:22,662 --> 00:35:24,870 That's how they're used to paying fees, [INAUDIBLE].. 820 00:35:24,870 --> 00:35:26,735 I don't think so. 821 00:35:26,735 --> 00:35:29,110 TADGE DRYJA: I've never seen any software that does that. 822 00:35:29,110 --> 00:35:31,060 I've seen some software that does really dumb stuff 823 00:35:31,060 --> 00:35:31,907 with regard to fees. 824 00:35:31,907 --> 00:35:32,740 I haven't seen that. 825 00:35:32,740 --> 00:35:34,900 That would be a new thing. 826 00:35:34,900 --> 00:35:37,420 So I don't think so, but maybe. 827 00:35:37,420 --> 00:35:40,430 AUDIENCE: I presume that it's the exchanges or wallet, 828 00:35:40,430 --> 00:35:43,568 companies just feel like their customers are happy are happier 829 00:35:43,568 --> 00:35:45,110 and they're charging their customers. 830 00:35:45,110 --> 00:35:47,272 It's just passing through the cost to customers. 831 00:35:47,272 --> 00:35:48,730 But a quick question-- why not just 832 00:35:48,730 --> 00:35:55,130 do an algorithm that takes the last six to 10 blocks, 833 00:35:55,130 --> 00:35:59,815 maybe time-weights it, and do an algorithm base, so 834 00:35:59,815 --> 00:36:02,760 an actual experience in the marketplace? 835 00:36:02,760 --> 00:36:06,280 TADGE DRYJA: Yeah, that is what the current Bitcoin D 836 00:36:06,280 --> 00:36:08,140 algorithm does. 837 00:36:08,140 --> 00:36:10,173 Even that can be off sometimes. 838 00:36:10,173 --> 00:36:11,590 And it allows sort of a estimate-- 839 00:36:11,590 --> 00:36:13,310 OK, how quickly do you need this? 840 00:36:13,310 --> 00:36:14,730 Do you need this in the next hour, 841 00:36:14,730 --> 00:36:18,220 do you need it in the next six hours, the next half hour? 842 00:36:18,220 --> 00:36:20,230 So yeah, the one in Bitcoin D is better. 843 00:36:20,230 --> 00:36:26,230 But it's not-- it's easy to say, oh, this should be easy. 844 00:36:26,230 --> 00:36:29,710 The thing is, it's a weird market. 845 00:36:29,710 --> 00:36:32,563 You're bidding for something that you don't quite know-- 846 00:36:32,563 --> 00:36:34,480 and you don't know what other participants are 847 00:36:34,480 --> 00:36:35,188 going to pile in. 848 00:36:35,188 --> 00:36:38,850 Sometimes-- so something like this, oh, a block 849 00:36:38,850 --> 00:36:40,640 didn't come out for half an hour, 850 00:36:40,640 --> 00:36:44,750 and a bunch of other people came and submitted higher bids 851 00:36:44,750 --> 00:36:46,040 after you. 852 00:36:46,040 --> 00:36:48,590 And so now you got out-- in practice, well, yeah, 853 00:36:48,590 --> 00:36:51,610 someone who submitted a bid here, a transaction here, 854 00:36:51,610 --> 00:36:53,720 a block came out there, and-- 855 00:36:53,720 --> 00:36:57,140 let's zoom in for an example. 856 00:36:57,140 --> 00:36:58,260 Well, that's too low. 857 00:36:58,260 --> 00:37:02,150 But I submitted something here. 858 00:37:02,150 --> 00:37:03,230 I think it will get in. 859 00:37:03,230 --> 00:37:05,147 But then all these other people came after me, 860 00:37:05,147 --> 00:37:06,890 and then the block didn't confirm mine. 861 00:37:06,890 --> 00:37:09,830 It did later, another few minutes later. 862 00:37:09,830 --> 00:37:12,380 But it's hard-- there's never any determinism in how 863 00:37:12,380 --> 00:37:13,200 it's going to work. 864 00:37:13,200 --> 00:37:13,600 Yes. 865 00:37:13,600 --> 00:37:15,142 AUDIENCE: So if fees are always lower 866 00:37:15,142 --> 00:37:18,060 around 8:00 AM or 4:00 AM, why not just pool transactions 867 00:37:18,060 --> 00:37:19,040 for around that time? 868 00:37:19,040 --> 00:37:20,623 TADGE DRYJA: They're not, because it's 869 00:37:20,623 --> 00:37:22,460 all over the world. 870 00:37:22,460 --> 00:37:25,010 They do tend to be lower on the weekends. 871 00:37:25,010 --> 00:37:28,020 People don't make as many transactions on the weekends. 872 00:37:28,020 --> 00:37:30,760 And so, yes, sometimes people will say, 873 00:37:30,760 --> 00:37:32,540 hey, I've got these transactions. 874 00:37:32,540 --> 00:37:35,270 In practice, if you say, I don't care how long it takes, 875 00:37:35,270 --> 00:37:37,300 just set a low fee and wait. 876 00:37:37,300 --> 00:37:41,085 And it will stay in the mempool for weeks. 877 00:37:41,085 --> 00:37:43,460 So there have been people who said, I made a transaction, 878 00:37:43,460 --> 00:37:46,733 I put a super-low fee, it confirmed a month later. 879 00:37:46,733 --> 00:37:47,650 The thing is, if you-- 880 00:37:47,650 --> 00:37:52,520 I should go, yeah, this is something of a tangent. 881 00:37:52,520 --> 00:37:57,200 But if you look over six months, it's really highly variable. 882 00:37:57,200 --> 00:38:00,350 It used to be sort of nothing, and then-- 883 00:38:00,350 --> 00:38:03,460 part of it is the-- 884 00:38:03,460 --> 00:38:06,330 it looks most dramatic here, because you're sorting by-- 885 00:38:06,330 --> 00:38:09,180 this shows the fee rate. 886 00:38:09,180 --> 00:38:11,008 It's like nothing. 887 00:38:11,008 --> 00:38:12,300 You don't have to deal with it. 888 00:38:12,300 --> 00:38:13,805 And then like, whoa, OK. 889 00:38:13,805 --> 00:38:15,180 And people were complaining, hey, 890 00:38:15,180 --> 00:38:16,770 it's days where nothing confirmed. 891 00:38:16,770 --> 00:38:20,310 Here it was weeks, months, like all of December and January. 892 00:38:20,310 --> 00:38:23,280 And it was correlated with everyone 893 00:38:23,280 --> 00:38:25,560 in the media, everyone wanting to buy bitcoins, 894 00:38:25,560 --> 00:38:28,420 the price skyrocketed. 895 00:38:28,420 --> 00:38:30,120 So it's very sort of peaky. 896 00:38:30,120 --> 00:38:32,040 And then I think interest has died down a bit, 897 00:38:32,040 --> 00:38:34,980 and the fees have gone down with it. 898 00:38:34,980 --> 00:38:38,050 So this is a hard problem to deal with. 899 00:38:38,050 --> 00:38:40,230 And it wasn't something people were dealing 900 00:38:40,230 --> 00:38:43,433 with until a few months ago. 901 00:38:43,433 --> 00:38:45,600 Most of the time, you could get by with just setting 902 00:38:45,600 --> 00:38:48,480 a low fixed fee or something, and it would work. 903 00:38:48,480 --> 00:38:50,760 But now we're really seeing the fee market develop. 904 00:38:50,760 --> 00:38:55,840 Also, people disagreed that this should even be a thing. 905 00:38:55,840 --> 00:38:59,220 So there's Bitcoin Cash, there's all these forks, 906 00:38:59,220 --> 00:39:03,550 the idea of, if you start hitting the block-size limit, 907 00:39:03,550 --> 00:39:05,618 increase the limit. 908 00:39:05,618 --> 00:39:06,910 Why should we have to pay fees? 909 00:39:06,910 --> 00:39:09,760 The miners are already getting plenty of money to mine with, 910 00:39:09,760 --> 00:39:12,220 we should just have as much transactions that we want. 911 00:39:12,220 --> 00:39:14,920 So there's people that say that. 912 00:39:14,920 --> 00:39:15,480 Yes. 913 00:39:15,480 --> 00:39:17,980 AUDIENCE: Sorry, if you're not getting them confirmed, 914 00:39:17,980 --> 00:39:21,020 you could just issue another transaction with higher fees. 915 00:39:21,020 --> 00:39:23,103 TADGE DRYJA: That's what I'm going to get to next. 916 00:39:26,340 --> 00:39:28,230 So not always. 917 00:39:28,230 --> 00:39:30,510 So one, your software might not do that. 918 00:39:30,510 --> 00:39:33,410 Most software in the last few years 919 00:39:33,410 --> 00:39:36,210 just said, look, once the transaction is sent, 920 00:39:36,210 --> 00:39:37,270 it's stuck. 921 00:39:37,270 --> 00:39:39,960 It's just like, yeah, I sent it, waiting for it to confirm. 922 00:39:39,960 --> 00:39:42,000 And you have to actually code something 923 00:39:42,000 --> 00:39:44,310 to deal with changing the transaction ID, 924 00:39:44,310 --> 00:39:45,780 invalidating the old one. 925 00:39:45,780 --> 00:39:48,390 That's some software. 926 00:39:48,390 --> 00:39:51,360 So one way a wallet could deal with this is to say, 927 00:39:51,360 --> 00:39:53,040 OK, well I'll do Child Pays for Parent. 928 00:39:53,040 --> 00:39:54,630 This is actually a little bit easier, software-wise, 929 00:39:54,630 --> 00:39:56,547 because you don't have to invalidate anything. 930 00:39:56,547 --> 00:39:59,088 You could just say, I'm going to send a transaction, spending 931 00:39:59,088 --> 00:40:01,170 one of those new outputs that's not confirmed, 932 00:40:01,170 --> 00:40:02,220 with a very high fee. 933 00:40:02,220 --> 00:40:04,220 Now, the average of the two will be high enough, 934 00:40:04,220 --> 00:40:05,370 maybe it will get in. 935 00:40:05,370 --> 00:40:08,880 You can also do this when you're on the receiving end. 936 00:40:08,880 --> 00:40:13,430 So if someone sent you a coin, but they sent that transaction 937 00:40:13,430 --> 00:40:14,520 with a low fee. 938 00:40:14,520 --> 00:40:16,800 And maybe you can't contact them anymore, 939 00:40:16,800 --> 00:40:19,050 maybe they're unresponsive or they don't care. 940 00:40:19,050 --> 00:40:21,690 And you're like, well, I really need this money, 941 00:40:21,690 --> 00:40:25,050 I want it confirmed, I can then respend 942 00:40:25,050 --> 00:40:27,660 that output with a high fee to confirm both of them. 943 00:40:27,660 --> 00:40:31,140 It's kind of annoying, but possible. 944 00:40:31,140 --> 00:40:33,330 Downsides of this-- 945 00:40:33,330 --> 00:40:35,610 Child Pays for Parent is very inefficient. 946 00:40:35,610 --> 00:40:37,520 You're making an extra transaction. 947 00:40:37,520 --> 00:40:39,895 And it's exacerbating the problem you're trying to solve. 948 00:40:39,895 --> 00:40:42,062 The whole problem is, there's too many transactions, 949 00:40:42,062 --> 00:40:43,260 there's not enough space. 950 00:40:43,260 --> 00:40:47,820 And you're increasing your priority in the queue 951 00:40:47,820 --> 00:40:49,540 by wasting even more space. 952 00:40:49,540 --> 00:40:53,460 So if everyone does Child Pays for Parent, it's really bad. 953 00:40:53,460 --> 00:40:55,050 Now every transaction is going to take 954 00:40:55,050 --> 00:40:57,780 two or three transactions. 955 00:40:57,780 --> 00:41:00,030 And the dependency graphs are kind of complex. 956 00:41:00,030 --> 00:41:02,160 You can have-- 957 00:41:02,160 --> 00:41:03,780 I don't remember exactly how. 958 00:41:03,780 --> 00:41:08,600 There are certain cases where Child Pays for Parent 959 00:41:08,600 --> 00:41:12,130 lowers the priority of a transaction. 960 00:41:12,130 --> 00:41:13,130 I didn't understand how. 961 00:41:13,130 --> 00:41:15,770 But someone explained it to me, and I'm like, oh, shoot, 962 00:41:15,770 --> 00:41:17,570 that's bad. 963 00:41:17,570 --> 00:41:20,120 Where someone else spending an output can-- 964 00:41:20,120 --> 00:41:22,430 if there's a whole branch of tons of different outputs 965 00:41:22,430 --> 00:41:24,530 and tons of different Child Pay for Parent, 966 00:41:24,530 --> 00:41:26,060 there are certain parts where, OK, 967 00:41:26,060 --> 00:41:28,940 if someone makes a low fee transaction, that can actually 968 00:41:28,940 --> 00:41:31,590 lower the priority of the parents. 969 00:41:31,590 --> 00:41:32,940 I don't remember. 970 00:41:32,940 --> 00:41:35,070 Anyway, so it's kind of a mess, it's complex, 971 00:41:35,070 --> 00:41:37,370 and it's also just very inefficient. 972 00:41:37,370 --> 00:41:41,280 OK, so another way which seems obvious, why don't I 973 00:41:41,280 --> 00:41:42,340 just double-spend it? 974 00:41:42,340 --> 00:41:44,160 I made a transaction with a low fee, 975 00:41:44,160 --> 00:41:45,810 why doesn't my wallet just say, look, 976 00:41:45,810 --> 00:41:47,727 I'm going to replace that transaction with one 977 00:41:47,727 --> 00:41:49,140 with a higher fee? 978 00:41:49,140 --> 00:41:53,370 And I just decrease the change output amount. 979 00:41:53,370 --> 00:41:55,675 That's simple, right? 980 00:41:55,675 --> 00:41:58,050 [CHUCKLING] 981 00:41:58,050 --> 00:42:00,280 Another problem-- the default relay behavior 982 00:42:00,280 --> 00:42:02,020 is to ignore double-spends. 983 00:42:02,020 --> 00:42:06,580 And this is not just a default that's for fun. 984 00:42:06,580 --> 00:42:09,160 This is actually-- there's good reasons for it. 985 00:42:09,160 --> 00:42:13,480 So if you see a transaction spending output A, output B, 986 00:42:13,480 --> 00:42:14,980 and then you see another transaction 987 00:42:14,980 --> 00:42:18,010 over the wire, spending one of those outputs 988 00:42:18,010 --> 00:42:21,550 that you've already seen, you will ignore it. 989 00:42:21,550 --> 00:42:24,327 You won't ban-- won't get mad at the person who sent it to you, 990 00:42:24,327 --> 00:42:25,410 but you'll just ignore it. 991 00:42:25,410 --> 00:42:26,080 Because you're like, no, I already 992 00:42:26,080 --> 00:42:28,000 saw a conflicting transaction. 993 00:42:28,000 --> 00:42:30,798 So the default is, first thing you see 994 00:42:30,798 --> 00:42:31,840 is the thing you go with. 995 00:42:34,200 --> 00:42:35,700 This is not a consensus rule, right, 996 00:42:35,700 --> 00:42:37,410 because we're not dealing with anything that's in the blocks 997 00:42:37,410 --> 00:42:38,070 yet. 998 00:42:38,070 --> 00:42:41,178 But any ideas of why this is an important rule to have? 999 00:42:44,670 --> 00:42:46,650 What are some attacks that you could perform? 1000 00:42:46,650 --> 00:42:49,590 If you just said, yeah, anything-- 1001 00:42:49,590 --> 00:42:52,560 I'm not going to stick with the first-seen transaction. 1002 00:42:52,560 --> 00:42:54,662 I will update anytime I see a new one. 1003 00:42:54,662 --> 00:42:55,620 I'll just go with the-- 1004 00:42:55,620 --> 00:42:57,600 I'll go with the last-seen transaction instead 1005 00:42:57,600 --> 00:42:58,830 of first-seen transaction. 1006 00:42:58,830 --> 00:43:03,412 What would be an attack that would be enabled by that? 1007 00:43:03,412 --> 00:43:04,120 Any ideas? 1008 00:43:06,645 --> 00:43:08,610 You got to think adversarially. 1009 00:43:08,610 --> 00:43:10,310 I'm trying to bring down Bitcoin. 1010 00:43:10,310 --> 00:43:14,150 If you change your code to last seen instead of first seen, 1011 00:43:14,150 --> 00:43:17,220 how do I bring down the network? 1012 00:43:17,220 --> 00:43:19,500 AUDIENCE: [INAUDIBLE] 1013 00:43:19,500 --> 00:43:22,990 TADGE DRYJA: Right, yeah, I just keep spending the same outputs, 1014 00:43:22,990 --> 00:43:24,750 100 times a second. 1015 00:43:24,750 --> 00:43:27,853 And they all have the same fee rate. 1016 00:43:27,853 --> 00:43:29,520 I can just keep doing that indefinitely, 1017 00:43:29,520 --> 00:43:31,755 and I just keep flooding the network. 1018 00:43:31,755 --> 00:43:34,380 And everyone's like, oh, here's this new one, oh, here's this-- 1019 00:43:34,380 --> 00:43:35,920 total mess. 1020 00:43:35,920 --> 00:43:38,500 However, there is a way to prevent that kind of flooding 1021 00:43:38,500 --> 00:43:40,900 attack, or at least significantly mitigate 1022 00:43:40,900 --> 00:43:44,620 it, which is, OK, we'll relay conflicting transactions, 1023 00:43:44,620 --> 00:43:47,260 but we require an increase in the fee. 1024 00:43:47,260 --> 00:43:51,010 And the required increase is equal to our minimum relay fee 1025 00:43:51,010 --> 00:43:52,930 of one Satoshi per byte. 1026 00:43:52,930 --> 00:43:54,970 So every time I could say, OK, I'm 1027 00:43:54,970 --> 00:43:58,990 going to replace it because it has a higher fee. 1028 00:43:58,990 --> 00:44:01,300 So now it's sort of constantly incrementing. 1029 00:44:01,300 --> 00:44:03,220 You can't keep doing that indefinitely. 1030 00:44:03,220 --> 00:44:05,613 Every time you want to send a transaction out 1031 00:44:05,613 --> 00:44:07,780 to the network and use everyone's network resources, 1032 00:44:07,780 --> 00:44:11,970 you are sort of potentially paying something for it. 1033 00:44:11,970 --> 00:44:15,240 Yeah, you will continue to ignore transactions 1034 00:44:15,240 --> 00:44:17,950 with same or lower fee. 1035 00:44:17,950 --> 00:44:18,980 Oh, I did the why. 1036 00:44:18,980 --> 00:44:20,373 Yeah, the why happened there. 1037 00:44:20,373 --> 00:44:22,790 Anyway, yeah, the DDoS attack is make lots of transactions 1038 00:44:22,790 --> 00:44:24,390 with the same fee, clog the network. 1039 00:44:24,390 --> 00:44:27,560 OK, so this seems simple, right? 1040 00:44:27,560 --> 00:44:28,658 We have replace by fee. 1041 00:44:28,658 --> 00:44:30,200 If you have a higher transaction fee, 1042 00:44:30,200 --> 00:44:31,790 you replace the transactions, wallets 1043 00:44:31,790 --> 00:44:32,870 implement it, no problem. 1044 00:44:36,360 --> 00:44:39,960 Well, people don't like it. 1045 00:44:39,960 --> 00:44:42,870 People said, no, we don't like replace by fee. 1046 00:44:42,870 --> 00:44:45,532 This was a controversy around 2015, 1047 00:44:45,532 --> 00:44:47,490 when a bunch of the developers were like, yeah, 1048 00:44:47,490 --> 00:44:49,530 this seems reasonable, let's put it in. 1049 00:44:49,530 --> 00:44:51,360 People said, no, this hurts the security 1050 00:44:51,360 --> 00:44:53,100 of unconfirmed transactions. 1051 00:44:53,100 --> 00:44:55,320 And to some extent, they do have a point, right? 1052 00:44:55,320 --> 00:44:57,840 If every node on the network says 1053 00:44:57,840 --> 00:45:00,280 I'm going with my first-seen transaction, 1054 00:45:00,280 --> 00:45:03,480 if there's a conflicting transaction later, I ignore it. 1055 00:45:03,480 --> 00:45:05,580 That means it's hard to double-spend, 1056 00:45:05,580 --> 00:45:08,790 even before it gets into a block. 1057 00:45:08,790 --> 00:45:11,560 You spend-- you say, OK, I'm going to send money to Alice, 1058 00:45:11,560 --> 00:45:12,765 and here's my change output. 1059 00:45:12,765 --> 00:45:14,140 And then you replace it with, I'm 1060 00:45:14,140 --> 00:45:17,860 going to send money to Bob instead, and my change output. 1061 00:45:17,860 --> 00:45:20,440 You can potentially make it appear that someone's 1062 00:45:20,440 --> 00:45:23,050 going to get paid-- it still says unconfirmed, 1063 00:45:23,050 --> 00:45:25,210 but they say, yeah, you sent me a transaction, 1064 00:45:25,210 --> 00:45:27,040 it'll get confirmed soon, and then 1065 00:45:27,040 --> 00:45:30,130 switch it out and try to make it so that you pay it 1066 00:45:30,130 --> 00:45:32,940 back to yourself instead. 1067 00:45:32,940 --> 00:45:35,615 When everyone on the network ignores those new transactions, 1068 00:45:35,615 --> 00:45:36,240 it gets harder. 1069 00:45:36,240 --> 00:45:39,100 You'd have to contact a miner directly and say, 1070 00:45:39,100 --> 00:45:41,200 hey, I have this transaction on the network, 1071 00:45:41,200 --> 00:45:46,020 here's a conflicting one, please include it in your next block, 1072 00:45:46,020 --> 00:45:48,120 to double-spend, to defraud this person. 1073 00:45:50,850 --> 00:45:53,723 The thing is, in practice, it's not that hard to do this. 1074 00:45:53,723 --> 00:45:55,390 And so a lot of the developers are like, 1075 00:45:55,390 --> 00:45:57,610 look, unconfirmed transactions really 1076 00:45:57,610 --> 00:45:59,470 have no security with them. 1077 00:45:59,470 --> 00:46:01,510 And yeah, it might seem like we're 1078 00:46:01,510 --> 00:46:04,330 reducing the security here, but you really should not 1079 00:46:04,330 --> 00:46:05,765 depend on unconfirmed at all. 1080 00:46:05,765 --> 00:46:06,890 It's not in the blockchain. 1081 00:46:06,890 --> 00:46:07,932 There's no proof of work. 1082 00:46:07,932 --> 00:46:10,360 The whole point of the system is to put the proof of work 1083 00:46:10,360 --> 00:46:12,160 to really get consensus. 1084 00:46:12,160 --> 00:46:14,810 And you cannot rely on network-level consensus, 1085 00:46:14,810 --> 00:46:17,300 because there isn't any. 1086 00:46:17,300 --> 00:46:19,390 And yeah, so to some extent, replace 1087 00:46:19,390 --> 00:46:21,700 by fee does make the double-spends easier to do. 1088 00:46:21,700 --> 00:46:23,470 That's the point. 1089 00:46:23,470 --> 00:46:26,050 But the thing is, it's not secure anyway. 1090 00:46:26,050 --> 00:46:30,560 So anyway, it's also a UI issue-- 1091 00:46:30,560 --> 00:46:32,960 should you even show unconfirmed transactions? 1092 00:46:32,960 --> 00:46:36,310 Almost all of the wallets do, even the SPV ones. 1093 00:46:36,310 --> 00:46:39,293 And the SPV ones have no idea if it's even valid 1094 00:46:39,293 --> 00:46:41,210 or has a valid signature since they can't even 1095 00:46:41,210 --> 00:46:42,470 check signatures. 1096 00:46:42,470 --> 00:46:45,418 Unconfirmed transactions are not meaningless. 1097 00:46:45,418 --> 00:46:47,960 If you see it on the network, and you're running a full node, 1098 00:46:47,960 --> 00:46:49,460 you see, yes, this is a transaction 1099 00:46:49,460 --> 00:46:51,710 that could be confirmed. 1100 00:46:51,710 --> 00:46:53,870 They've provided a valid signature. 1101 00:46:53,870 --> 00:46:55,340 Any miner can put this in. 1102 00:46:55,340 --> 00:46:56,860 There's no conflicts. 1103 00:46:56,860 --> 00:46:57,830 This can work. 1104 00:46:57,830 --> 00:47:00,320 If you're SPV and you see an unconfirmed transaction, 1105 00:47:00,320 --> 00:47:02,863 you have no idea, because you don't even 1106 00:47:02,863 --> 00:47:05,030 know if it's spending outputs that exist because you 1107 00:47:05,030 --> 00:47:06,560 don't have a UTXO set. 1108 00:47:06,560 --> 00:47:07,940 You can't verify the signatures. 1109 00:47:07,940 --> 00:47:10,860 You don't even know what the keys are supposed to be. 1110 00:47:10,860 --> 00:47:15,200 But most SPV wallets still show unconfirmed transactions 1111 00:47:15,200 --> 00:47:16,550 because users want it. 1112 00:47:16,550 --> 00:47:17,690 They want to know. 1113 00:47:17,690 --> 00:47:20,360 And it's like, sometimes they'll put it in, like, red text, 1114 00:47:20,360 --> 00:47:22,568 like, hey, it's unconfirmed, or put a little question 1115 00:47:22,568 --> 00:47:24,360 mark next to it. 1116 00:47:24,360 --> 00:47:27,240 I would rather just not show it at all. 1117 00:47:27,240 --> 00:47:31,070 I think it gives a misleading sense to users. 1118 00:47:31,070 --> 00:47:32,540 But this is an issue, right? 1119 00:47:32,540 --> 00:47:36,350 Users are like, I want to know if the sender has actually 1120 00:47:36,350 --> 00:47:37,470 signed and sent. 1121 00:47:37,470 --> 00:47:39,470 And then yeah, afterwards, it gets in the block. 1122 00:47:39,470 --> 00:47:41,137 Yeah, now it's confirmed, now it's safe. 1123 00:47:41,137 --> 00:47:43,010 But I want to know. 1124 00:47:43,010 --> 00:47:46,300 So SPV can sometimes connect multiple nodes and ask. 1125 00:47:46,300 --> 00:47:47,750 But this is a controversial thing 1126 00:47:47,750 --> 00:47:50,390 that people have argued about. 1127 00:47:50,390 --> 00:47:53,990 My personal opinion is that security 1128 00:47:53,990 --> 00:47:56,930 is more important than UI and usability in this case, 1129 00:47:56,930 --> 00:48:00,530 and you really should not rely on anything that 1130 00:48:00,530 --> 00:48:02,330 has unconfirmed transactions. 1131 00:48:02,330 --> 00:48:05,540 And also, the RBF-- the Replace By Fee policy 1132 00:48:05,540 --> 00:48:10,010 is not a network consensus-level rule. 1133 00:48:10,010 --> 00:48:12,410 You don't know what policy people have. 1134 00:48:12,410 --> 00:48:15,375 If people are running-- if nodes are running "I just 1135 00:48:15,375 --> 00:48:17,000 stick with the first-seen transaction," 1136 00:48:17,000 --> 00:48:18,860 or "I replace with incrementing fees," 1137 00:48:18,860 --> 00:48:21,880 or "I replace no matter what," or who knows, 1138 00:48:21,880 --> 00:48:26,420 "I'll go with three or four updates and then I'll ignore." 1139 00:48:26,420 --> 00:48:29,200 You just don't know what people are doing. 1140 00:48:29,200 --> 00:48:31,020 So the compromise that's currently 1141 00:48:31,020 --> 00:48:35,970 in the Bitcoin software is called opt-in replace by fee. 1142 00:48:35,970 --> 00:48:40,740 You flag a transaction by changing the sequence number 1143 00:48:40,740 --> 00:48:45,120 in the input to not be FFFFF. 1144 00:48:45,120 --> 00:48:48,210 And then you indicate, hey, I'm flagging my transaction 1145 00:48:48,210 --> 00:48:51,990 as this can be replaced with an increasing fee. 1146 00:48:51,990 --> 00:48:53,490 It's kind of ugly in my opinion. 1147 00:48:53,490 --> 00:48:53,990 It's 1148 00:48:53,990 --> 00:48:58,200 Like-- it's not really opt-in. 1149 00:48:58,200 --> 00:48:59,520 You can't even opt out. 1150 00:48:59,520 --> 00:49:03,510 It's weird to say to people, oh, yeah, you opt into RBF. 1151 00:49:03,510 --> 00:49:05,670 Because there's no way to prevent it. 1152 00:49:05,670 --> 00:49:07,140 You can always contact the miners, 1153 00:49:07,140 --> 00:49:08,580 or anyone can just run it. 1154 00:49:08,580 --> 00:49:10,553 And there's code out there that's 1155 00:49:10,553 --> 00:49:11,970 a couple of lines different that's 1156 00:49:11,970 --> 00:49:14,700 like, here's the full RBF version of Bitcoin, 1157 00:49:14,700 --> 00:49:17,130 where it'll just ignore this flag 1158 00:49:17,130 --> 00:49:19,440 and treat everything the same. 1159 00:49:19,440 --> 00:49:23,220 But we do now have the option-- so if you run a wallet, 1160 00:49:23,220 --> 00:49:25,140 and I believe that the Bitcoin Core 1161 00:49:25,140 --> 00:49:28,110 Wallet, with the new version last week 1162 00:49:28,110 --> 00:49:31,680 or last month, now, by default, flags every transaction as 1163 00:49:31,680 --> 00:49:35,190 replace by fee, so that you can then bump the fee later on. 1164 00:49:40,730 --> 00:49:44,150 And this is a much better way to deal with fees. 1165 00:49:44,150 --> 00:49:45,440 Because then you're not stuck. 1166 00:49:45,440 --> 00:49:47,360 And then, to some extent, you don't even 1167 00:49:47,360 --> 00:49:49,250 need to look at the mempool and what 1168 00:49:49,250 --> 00:49:51,020 fees everyone else is paying. 1169 00:49:51,020 --> 00:49:55,090 You can just say, well, I can also time-lock transactions, 1170 00:49:55,090 --> 00:49:57,830 and I can say, OK, well, at the current block, 1171 00:49:57,830 --> 00:49:59,630 I'll pay one Satoshi per byte. 1172 00:49:59,630 --> 00:50:01,640 I'll also send out a transaction where 1173 00:50:01,640 --> 00:50:03,170 it's not valid until the next block, 1174 00:50:03,170 --> 00:50:04,730 and I pay two Satoshis per byte. 1175 00:50:04,730 --> 00:50:07,022 And then the block after that, I'll pay four, and block 1176 00:50:07,022 --> 00:50:10,310 after that, I'll pay eight, or whatever sort of fee schedule 1177 00:50:10,310 --> 00:50:11,210 you want. 1178 00:50:11,210 --> 00:50:13,760 And then the miners now have the option to look 1179 00:50:13,760 --> 00:50:16,790 and say, well, two Satoshis per byte is too little, 1180 00:50:16,790 --> 00:50:17,963 I'm not going to take it. 1181 00:50:17,963 --> 00:50:19,130 But then a block comes out-- 1182 00:50:19,130 --> 00:50:20,030 OK, now it's four. 1183 00:50:20,030 --> 00:50:22,724 OK, I'll take that one. 1184 00:50:22,724 --> 00:50:25,720 And so that's a really nice sort of fire-and-forget 1185 00:50:25,720 --> 00:50:28,960 from the user's wallet, where I don't even 1186 00:50:28,960 --> 00:50:30,670 know what fee I should pay, well, look, 1187 00:50:30,670 --> 00:50:32,470 I'll just keep incrementing it. 1188 00:50:32,470 --> 00:50:35,470 And hopefully it confirms soon at a low rate. 1189 00:50:35,470 --> 00:50:38,350 As it takes longer and longer, my rate goes up, 1190 00:50:38,350 --> 00:50:39,620 and eventually I'll get it in. 1191 00:50:39,620 --> 00:50:40,120 Yeah. 1192 00:50:40,120 --> 00:50:43,200 AUDIENCE: Are there any limits to how many times you do that? 1193 00:50:43,200 --> 00:50:44,200 TADGE DRYJA: Not really. 1194 00:50:44,200 --> 00:50:46,680 OK, so one limit is you cannot actually broadcast 1195 00:50:46,680 --> 00:50:51,890 the transaction that is valid in a future block. 1196 00:50:51,890 --> 00:50:53,192 The network will ignore it. 1197 00:50:53,192 --> 00:50:55,150 It's a similar reason, denial of service thing, 1198 00:50:55,150 --> 00:50:57,980 where, hey, here's a transaction that's valid next week. 1199 00:50:57,980 --> 00:51:00,850 Well, why'd you tell it to me today? 1200 00:51:00,850 --> 00:51:03,310 So you'd have to be online to do that. 1201 00:51:03,310 --> 00:51:05,950 But your wallet can do it automatically. 1202 00:51:05,950 --> 00:51:09,240 It can just do it in the background. 1203 00:51:09,240 --> 00:51:11,000 And in practice, I don't know any wallets 1204 00:51:11,000 --> 00:51:13,310 that do that right now. 1205 00:51:13,310 --> 00:51:16,280 The Core Wallet will allow you to in the UI. 1206 00:51:16,280 --> 00:51:18,200 You sort of right-click and you say, bump-- 1207 00:51:18,200 --> 00:51:21,340 increase fee, and then it will rebroadcast with an increased 1208 00:51:21,340 --> 00:51:22,900 fee. 1209 00:51:22,900 --> 00:51:29,110 OK, so yeah, it's a kind of a mess, but it's getting there. 1210 00:51:29,110 --> 00:51:31,300 We're getting better at this. 1211 00:51:31,300 --> 00:51:35,230 Any questions before we have a break? 1212 00:51:35,230 --> 00:51:35,730 Yes. 1213 00:51:35,730 --> 00:51:38,350 AUDIENCE: So the one [INAUDIBLE] they'd 1214 00:51:38,350 --> 00:51:40,842 pay [INAUDIBLE] their own confirmation of transaction. 1215 00:51:40,842 --> 00:51:42,800 TADGE DRYJA: Well, eventually they will, right? 1216 00:51:42,800 --> 00:51:43,980 AUDIENCE: [INAUDIBLE] 1217 00:51:43,980 --> 00:51:45,630 TADGE DRYJA: Will they eventually? 1218 00:51:45,630 --> 00:51:47,297 AUDIENCE: Once it gets the confirmation, 1219 00:51:47,297 --> 00:51:49,460 but normally they accept transactions 1220 00:51:49,460 --> 00:51:50,460 without confirmation. 1221 00:51:50,460 --> 00:51:51,835 TADGE DRYJA: That's silly anyway. 1222 00:51:51,835 --> 00:51:52,790 AUDIENCE: [INAUDIBLE] 1223 00:51:52,790 --> 00:51:56,880 TADGE DRYJA: OK, well yeah, so some sites 1224 00:51:56,880 --> 00:52:01,200 will accept zero-conf without RBF, but not with. 1225 00:52:01,200 --> 00:52:03,210 My thinking is they shouldn't be accepting 1226 00:52:03,210 --> 00:52:06,630 zero-confirmation transactions, regardless. 1227 00:52:06,630 --> 00:52:08,190 So whatever. 1228 00:52:08,190 --> 00:52:09,990 But yeah, and people-- 1229 00:52:09,990 --> 00:52:12,630 there was a thing, Peter Todd stole $10 1230 00:52:12,630 --> 00:52:15,060 from Coinbase a couple years ago because he 1231 00:52:15,060 --> 00:52:16,230 was trying to prove a point. 1232 00:52:16,230 --> 00:52:20,070 It's so easy to double-spend before it's in a block. 1233 00:52:20,070 --> 00:52:21,810 And all these different sites are saying, 1234 00:52:21,810 --> 00:52:24,143 oh, yeah, here's a transaction that's not confirmed yet, 1235 00:52:24,143 --> 00:52:25,620 but it will be soon. 1236 00:52:25,620 --> 00:52:28,653 And then they dispense with the product. 1237 00:52:28,653 --> 00:52:30,570 And then I remember Peter Todd was like, look, 1238 00:52:30,570 --> 00:52:34,120 I just got $10 from you on Steam or whatever, 1239 00:52:34,120 --> 00:52:35,070 do you want it back? 1240 00:52:35,070 --> 00:52:36,600 And they didn't reply. 1241 00:52:36,600 --> 00:52:38,220 Because it's really not that hard to 1242 00:52:38,220 --> 00:52:40,020 double-spend before it's in a block. 1243 00:52:40,020 --> 00:52:42,103 The whole point of the blockchain, all the mining, 1244 00:52:42,103 --> 00:52:44,310 is to prevent the double-spend. 1245 00:52:44,310 --> 00:52:47,096 OK, so the last part is going to be about-- 1246 00:52:47,096 --> 00:52:48,920 AUDIENCE: [INAUDIBLE] 1247 00:52:48,920 --> 00:52:50,810 TADGE DRYJA: Oh yeah, I already said this. 1248 00:52:50,810 --> 00:52:53,330 One thing, though, is further research is needed. 1249 00:52:53,330 --> 00:52:56,390 This has all been changing in the last year. 1250 00:52:56,390 --> 00:52:58,495 If you had this talk a year ago, it would sort of 1251 00:52:58,495 --> 00:53:00,620 be like, yeah, I guess you could do replace by fee, 1252 00:53:00,620 --> 00:53:02,480 I guess fees could work this way. 1253 00:53:02,480 --> 00:53:07,640 But we had never really had this sustained, long fee ramp-up. 1254 00:53:07,640 --> 00:53:08,770 This hadn't happened. 1255 00:53:08,770 --> 00:53:09,770 This had never happened. 1256 00:53:09,770 --> 00:53:12,620 There had been cases where sometimes blocks had been full, 1257 00:53:12,620 --> 00:53:15,380 but we'd never seen this ramp-up. 1258 00:53:15,380 --> 00:53:17,420 It's also really interesting how inelastic 1259 00:53:17,420 --> 00:53:22,310 it was, in that people started paying 1260 00:53:22,310 --> 00:53:27,950 thousands of Satoshis per byte, $20, $30 a transaction. 1261 00:53:27,950 --> 00:53:30,230 And people got mad about it, but what was interesting 1262 00:53:30,230 --> 00:53:31,880 is people were paying. 1263 00:53:31,880 --> 00:53:35,780 If everyone refuses to pay these rates, the rates go down. 1264 00:53:35,780 --> 00:53:38,870 But someone's paying that much. 1265 00:53:38,870 --> 00:53:41,180 But a lot of it is exchanges and stuff. 1266 00:53:41,180 --> 00:53:45,680 OK, yeah, problems-- exchanges overpay. 1267 00:53:45,680 --> 00:53:47,600 Bitcoin D Wallets overpays. 1268 00:53:47,600 --> 00:53:49,250 Nobody cared for seven years. 1269 00:53:49,250 --> 00:53:52,003 It's sort of like it's also, efficiency-wise, 1270 00:53:52,003 --> 00:53:53,420 in terms of your transaction size, 1271 00:53:53,420 --> 00:53:56,810 it kind of reminds me of 2008 when everyone was driving 1272 00:53:56,810 --> 00:53:58,790 Hummers, and then gas goes to like $4.00, 1273 00:53:58,790 --> 00:54:01,820 and then everyone gets a Prius. 1274 00:54:01,820 --> 00:54:03,980 That's happening now, where it's like, OK, 1275 00:54:03,980 --> 00:54:05,600 let's batch our transactions. 1276 00:54:05,600 --> 00:54:09,290 Let's use compressed pub keys. 1277 00:54:09,290 --> 00:54:11,390 There's all sorts of techniques to reduce 1278 00:54:11,390 --> 00:54:14,180 the size of your transactions so more 1279 00:54:14,180 --> 00:54:19,460 can fit in the block which are now still being implemented. 1280 00:54:19,460 --> 00:54:20,720 It's sort of after the fact. 1281 00:54:20,720 --> 00:54:24,980 It takes this, hey, you're spending thousands of dollars 1282 00:54:24,980 --> 00:54:28,702 a day on this to really kick people into action to write it. 1283 00:54:28,702 --> 00:54:30,410 I remember looking into December, though, 1284 00:54:30,410 --> 00:54:33,350 at Coinbase's transactions and being like, 1285 00:54:33,350 --> 00:54:35,930 you should hire-- you guys are probably losing $1 million 1286 00:54:35,930 --> 00:54:37,340 a day. 1287 00:54:37,340 --> 00:54:38,960 I could fix this for you. 1288 00:54:38,960 --> 00:54:40,780 You should-- no? 1289 00:54:40,780 --> 00:54:41,465 OK. 1290 00:54:41,465 --> 00:54:42,950 [CHUCKLING] 1291 00:54:42,950 --> 00:54:44,600 But it's sort of frustrating to see. 1292 00:54:44,600 --> 00:54:46,898 And probably, their system is a huge mess 1293 00:54:46,898 --> 00:54:49,440 from so many different layers and things on top of each other 1294 00:54:49,440 --> 00:54:50,357 that it's hard to fix. 1295 00:54:50,357 --> 00:54:53,270 But looking at-- 1296 00:54:53,270 --> 00:54:54,740 Gemini also is an exchange. 1297 00:54:54,740 --> 00:54:56,180 They use uncompressed pub keys. 1298 00:54:56,180 --> 00:54:59,600 So the pub keys are 65 bytes instead of 33. 1299 00:54:59,600 --> 00:55:01,340 There's no advantage there. 1300 00:55:01,340 --> 00:55:03,480 It's just an extra 32 bytes. 1301 00:55:03,480 --> 00:55:06,160 Which they've probably spent, I don't know, a couple hundred K 1302 00:55:06,160 --> 00:55:08,900 on just that weird aspect of their software. 1303 00:55:08,900 --> 00:55:10,960 I don't know if they're aware of this, even. 1304 00:55:10,960 --> 00:55:12,170 You might want to be like, hey, guys, 1305 00:55:12,170 --> 00:55:13,462 you're spending too much money. 1306 00:55:13,462 --> 00:55:15,920 Because look, your transactions are an extra 32 bytes 1307 00:55:15,920 --> 00:55:18,530 per input because of this. 1308 00:55:18,530 --> 00:55:21,800 But yeah, it's interesting to see. 1309 00:55:21,800 --> 00:55:23,360 I've also paid. 1310 00:55:23,360 --> 00:55:25,190 I used to not pay. 1311 00:55:25,190 --> 00:55:27,860 Oh, one thing that used to be the case, transactions 1312 00:55:27,860 --> 00:55:31,550 had priority, which was based on the age 1313 00:55:31,550 --> 00:55:35,100 of the outputs multiplied by the amount of the outputs. 1314 00:55:35,100 --> 00:55:39,010 That was a thing until two years ago. 1315 00:55:39,010 --> 00:55:41,280 And it was great because it meant if you were rich, 1316 00:55:41,280 --> 00:55:42,260 you didn't pay fees. 1317 00:55:42,260 --> 00:55:43,020 [CHUCKLING] 1318 00:55:43,020 --> 00:55:44,790 So if you had a bunch of bitcoin, 1319 00:55:44,790 --> 00:55:49,290 it was kind of a maybe not-so-great social idea 1320 00:55:49,290 --> 00:55:53,160 that, hey, if you have an output that's got 100 coins in it, 1321 00:55:53,160 --> 00:55:58,840 you can make a zero-fee transaction. 1322 00:55:58,840 --> 00:56:00,910 It actually worked from a theoretical perspective 1323 00:56:00,910 --> 00:56:02,770 because it prevented spam. 1324 00:56:02,770 --> 00:56:05,590 Because the idea is, if you have 100 coins, OK, 1325 00:56:05,590 --> 00:56:10,198 you can spend that every day or something, with no fee. 1326 00:56:10,198 --> 00:56:11,740 If you have only one coin, maybe have 1327 00:56:11,740 --> 00:56:14,470 to wait 100 days to be able to spend it with no fee. 1328 00:56:14,470 --> 00:56:16,840 So there's this sort of priority, age-based, 1329 00:56:16,840 --> 00:56:20,710 to limit the velocity of these payments 1330 00:56:20,710 --> 00:56:22,870 based on how big they are. 1331 00:56:22,870 --> 00:56:24,640 They got rid of that because it made 1332 00:56:24,640 --> 00:56:27,220 sense from a network level, "let's protect 1333 00:56:27,220 --> 00:56:29,410 the network from spam" idea. 1334 00:56:29,410 --> 00:56:31,240 It did not make any sense for the miners 1335 00:56:31,240 --> 00:56:33,850 to prioritize these transactions. 1336 00:56:33,850 --> 00:56:36,497 I'm a miner, who cares if you have a bunch of old outputs 1337 00:56:36,497 --> 00:56:38,080 that you haven't spent in a long time. 1338 00:56:38,080 --> 00:56:40,990 It does nothing for me. 1339 00:56:40,990 --> 00:56:42,490 It does help the network in general. 1340 00:56:42,490 --> 00:56:43,960 But so I was a little disappointed, 1341 00:56:43,960 --> 00:56:45,700 because I don't have a ton of coins, 1342 00:56:45,700 --> 00:56:48,587 but they're all really old, so I could get away 1343 00:56:48,587 --> 00:56:49,420 without paying fees. 1344 00:56:52,990 --> 00:56:56,890 Long term though, this is sort of an interesting thing 1345 00:56:56,890 --> 00:56:58,780 to look at. 1346 00:56:58,780 --> 00:57:00,180 I'm not sure that's-- 1347 00:57:00,180 --> 00:57:01,870 oh, shoot, is that number right? 1348 00:57:01,870 --> 00:57:02,912 Wait, James, do you know? 1349 00:57:02,912 --> 00:57:03,990 Is it 210,000? 1350 00:57:03,990 --> 00:57:05,370 I think it is. 1351 00:57:05,370 --> 00:57:06,990 That number might be wrong. 1352 00:57:06,990 --> 00:57:09,765 I made a mental note to confirm it. 1353 00:57:09,765 --> 00:57:10,740 I think it's right. 1354 00:57:10,740 --> 00:57:14,250 Anyway, the mining reward drops in half, every four years, 1355 00:57:14,250 --> 00:57:16,590 approximately. 1356 00:57:16,590 --> 00:57:18,300 And eventually all the coins are mined. 1357 00:57:18,300 --> 00:57:20,640 So it's dropped in half twice. 1358 00:57:20,640 --> 00:57:22,560 First it was 50 coins a block, then 25, 1359 00:57:22,560 --> 00:57:24,260 and now it's 12 and 1/2. 1360 00:57:24,260 --> 00:57:28,410 In two years it's going to be 6.25 or something. 1361 00:57:28,410 --> 00:57:31,950 So eventually all the coins are gone, you mined them all. 1362 00:57:31,950 --> 00:57:33,200 That takes 100 years. 1363 00:57:33,200 --> 00:57:35,100 So everyone's like, I'll be dead-- 1364 00:57:35,100 --> 00:57:37,260 I'll be gone, you'll be gone. 1365 00:57:37,260 --> 00:57:40,980 But actually the rewards become negligible a lot sooner 1366 00:57:40,980 --> 00:57:42,240 than you think. 1367 00:57:42,240 --> 00:57:45,750 In 20 years, there's way less than a coin 1368 00:57:45,750 --> 00:57:48,180 in rewards, because it keeps getting chopped 1369 00:57:48,180 --> 00:57:49,950 in half every four years. 1370 00:57:49,950 --> 00:57:51,780 so yeah, there's this sort of long tail 1371 00:57:51,780 --> 00:57:55,470 where you've got like 50 years of a couple Satoshis per block. 1372 00:57:55,470 --> 00:57:57,760 But it's negligible, right? 1373 00:57:57,760 --> 00:58:01,060 So the rewards going to near zero actually 1374 00:58:01,060 --> 00:58:03,970 happens definitely within our lifetimes, pretty soon. 1375 00:58:03,970 --> 00:58:05,710 And a lot of people looking at Bitcoin 1376 00:58:05,710 --> 00:58:07,252 are sort of thinking of it long term. 1377 00:58:09,832 --> 00:58:11,290 Bitcoin's only worth a lot of money 1378 00:58:11,290 --> 00:58:12,748 now because people think it's going 1379 00:58:12,748 --> 00:58:14,770 to be worth a lot of money in 20 years, right? 1380 00:58:14,770 --> 00:58:17,050 If everyone knew it was going to collapse in 10 years, 1381 00:58:17,050 --> 00:58:20,280 I think people would lose interest. 1382 00:58:20,280 --> 00:58:23,810 So what are some weird long-term problems? 1383 00:58:23,810 --> 00:58:27,110 OK, well if there's no new coins to mine, why do you mine. 1384 00:58:27,110 --> 00:58:31,880 Well, the title of this piece. 1385 00:58:31,880 --> 00:58:33,980 However, it's not that simple. 1386 00:58:36,790 --> 00:58:39,390 There's a lot of problems with the fees being 1387 00:58:39,390 --> 00:58:43,650 the only incentive, in that TX fees are very variable. 1388 00:58:43,650 --> 00:58:47,910 Without a backlog, the fees tend to go to pretty close to zero. 1389 00:58:47,910 --> 00:58:51,360 And if the fees are zero, there's no reason to mine. 1390 00:58:51,360 --> 00:58:53,530 All the new coins have been generated, 1391 00:58:53,530 --> 00:58:58,410 there's no fees in the mempool, why am I running my-- 1392 00:58:58,410 --> 00:59:00,840 maybe you have a megabyte worth of zero-fee transactions 1393 00:59:00,840 --> 00:59:02,100 in the mempool. 1394 00:59:02,100 --> 00:59:04,800 But as a miner, why am I spending electricity 1395 00:59:04,800 --> 00:59:05,490 to mine this? 1396 00:59:05,490 --> 00:59:06,670 I get nothing. 1397 00:59:06,670 --> 00:59:08,250 So the miners just turn off. 1398 00:59:08,250 --> 00:59:10,170 That would be what they should do. 1399 00:59:10,170 --> 00:59:12,042 And you can see, yeah, it's super variable. 1400 00:59:12,042 --> 00:59:13,750 Maybe miners are like, oh, this is great, 1401 00:59:13,750 --> 00:59:15,000 we're making a ton of money. 1402 00:59:15,000 --> 00:59:17,650 And then here they're like, I guess wrap it up, 1403 00:59:17,650 --> 00:59:21,475 close down the mining facility. 1404 00:59:21,475 --> 00:59:23,725 And that could be a problem, even on much shorter time 1405 00:59:23,725 --> 00:59:27,960 scales, such as the time scale of a single block. 1406 00:59:27,960 --> 00:59:31,110 So for example, here's what you do. 1407 00:59:31,110 --> 00:59:32,208 You're a miner. 1408 00:59:32,208 --> 00:59:33,500 There's no fees in the mempool. 1409 00:59:33,500 --> 00:59:34,410 There's no reward. 1410 00:59:34,410 --> 00:59:35,900 There's no reason to mine, right? 1411 00:59:35,900 --> 00:59:37,640 Turn off your chips, and then turn them 1412 00:59:37,640 --> 00:59:39,485 back on once the mempool starts filling up, 1413 00:59:39,485 --> 00:59:40,610 because it will eventually. 1414 00:59:40,610 --> 00:59:42,650 The idea is, OK, for the next couple of minutes, 1415 00:59:42,650 --> 00:59:45,540 I'm just idling. 1416 00:59:45,540 --> 00:59:48,270 You could do that, or you can be clever 1417 00:59:48,270 --> 00:59:51,310 and say, well, I've got all these chips, 1418 00:59:51,310 --> 00:59:53,967 the opportunity cost, a lot of it is CAPEX. 1419 00:59:53,967 --> 00:59:55,800 A lot of is the capital expense of the chips 1420 00:59:55,800 --> 00:59:57,720 and not the electricity. 1421 00:59:57,720 --> 00:59:59,460 So if I'm just turning off my chips, 1422 00:59:59,460 --> 01:00:00,570 that's a huge loss for me. 1423 01:00:00,570 --> 01:00:01,890 I want to run. 1424 01:00:01,890 --> 01:00:04,140 I don't want to run with an empty mempool, 1425 01:00:04,140 --> 01:00:05,340 because I get nothing. 1426 01:00:05,340 --> 01:00:07,400 What should I do? 1427 01:00:07,400 --> 01:00:08,600 What's a fun attack? 1428 01:00:11,120 --> 01:00:11,680 Yeah. 1429 01:00:11,680 --> 01:00:13,961 AUDIENCE: Could you make a bunch of transactions 1430 01:00:13,961 --> 01:00:15,961 where the fees are high, and the new people will 1431 01:00:15,961 --> 01:00:17,560 leave when the fees are high? 1432 01:00:17,560 --> 01:00:18,727 TADGE DRYJA: Very good idea. 1433 01:00:18,727 --> 01:00:22,870 I'm pretty sure miners are doing that, or were in November. 1434 01:00:22,870 --> 01:00:24,130 That doesn't help you-- 1435 01:00:24,130 --> 01:00:26,290 that helps you sort of medium-term, right? 1436 01:00:26,290 --> 01:00:28,450 In the very short term, where there's 1437 01:00:28,450 --> 01:00:30,212 an empty mempool, what do I do? 1438 01:00:30,212 --> 01:00:31,670 There is another attack you can do. 1439 01:00:31,670 --> 01:00:32,170 Yeah. 1440 01:00:32,170 --> 01:00:34,435 AUDIENCE: You can just mine in empty blocks. 1441 01:00:34,435 --> 01:00:36,310 TADGE DRYJA: Yeah, but I don't get any money. 1442 01:00:36,310 --> 01:00:38,030 You could, but that's not a fun attack. 1443 01:00:38,030 --> 01:00:38,530 Yeah. 1444 01:00:38,530 --> 01:00:41,670 AUDIENCE: You could build up a bunch of non-transactions. 1445 01:00:41,670 --> 01:00:43,600 TADGE DRYJA: Yeah, but I want to get money. 1446 01:00:43,600 --> 01:00:47,200 I want to get paid, there's nothing in the mempool, 1447 01:00:47,200 --> 01:00:48,539 where do I go? 1448 01:00:48,539 --> 01:00:49,039 Yeah. 1449 01:00:49,039 --> 01:00:50,581 AUDIENCE: Output to another currency. 1450 01:00:50,581 --> 01:00:51,940 TADGE DRYJA: OK, so yes. 1451 01:00:51,940 --> 01:00:55,225 So in Bitcoin's case, the algorithm-- 1452 01:00:55,225 --> 01:00:57,100 well now there's Bitcoin Cash, and so there's 1453 01:00:57,100 --> 01:01:00,740 sort of two chains that share a single algorithm. 1454 01:01:00,740 --> 01:01:03,730 And in many alt coins, they share either algorithms 1455 01:01:03,730 --> 01:01:06,700 or they're using a GPU, which can be quickly switched 1456 01:01:06,700 --> 01:01:08,770 between different mining algorithms. 1457 01:01:08,770 --> 01:01:11,420 In Bitcoin's case, though, you're sort of stuck. 1458 01:01:11,420 --> 01:01:14,840 It's a big one, and you're using Sha256. 1459 01:01:14,840 --> 01:01:16,884 So OK, good. 1460 01:01:16,884 --> 01:01:19,128 AUDIENCE: You could mine off the previous-- 1461 01:01:19,128 --> 01:01:20,920 TADGE DRYJA: Yeah, you go back to the past. 1462 01:01:20,920 --> 01:01:23,950 You mine the past transactions. 1463 01:01:23,950 --> 01:01:26,650 OK, someone mined a bunch of transactions here, 1464 01:01:26,650 --> 01:01:28,850 and they got two bitcoins. 1465 01:01:28,850 --> 01:01:31,220 Those are two bitcoins I could've mined. 1466 01:01:31,220 --> 01:01:32,460 [CHUCKLING] 1467 01:01:32,460 --> 01:01:36,140 So that last block at a couple of coins in fees. 1468 01:01:36,140 --> 01:01:37,566 I'm going to remine it. 1469 01:01:37,566 --> 01:01:40,920 I'm not getting anything if I mine-- if I continue the chain 1470 01:01:40,920 --> 01:01:42,810 and make progress, I get no money. 1471 01:01:42,810 --> 01:01:46,170 But if I try to snipe the last guy's mining stuff, 1472 01:01:46,170 --> 01:01:49,200 I might be able to take his money. 1473 01:01:49,200 --> 01:01:51,870 If you find two blocks in a row, which happens, 1474 01:01:51,870 --> 01:01:53,500 you get all the fees. 1475 01:01:53,500 --> 01:01:55,760 So that's sort of an optimal thing to do. 1476 01:01:55,760 --> 01:01:58,080 I've got all this mining power, maybe 1477 01:01:58,080 --> 01:02:01,417 I turn it off because I'm mostly OPEX instead of CAPEX. 1478 01:02:01,417 --> 01:02:03,000 But if I've got all this mining power, 1479 01:02:03,000 --> 01:02:06,090 I'm going to use it no matter what, the optimal thing to do 1480 01:02:06,090 --> 01:02:08,580 is try to take a reorg the blockchain 1481 01:02:08,580 --> 01:02:11,080 and take the last person's fees. 1482 01:02:11,080 --> 01:02:13,930 So for example, instead of sequentially building, 1483 01:02:13,930 --> 01:02:14,680 you fight over it. 1484 01:02:14,680 --> 01:02:16,410 So here's this blockchain. 1485 01:02:16,410 --> 01:02:19,060 OK, Alice got two, Bob got three, Carol got two, 1486 01:02:19,060 --> 01:02:19,780 Dave got one. 1487 01:02:19,780 --> 01:02:22,000 These are fees within the block. 1488 01:02:22,000 --> 01:02:24,440 And now the current mempool, it's zero. 1489 01:02:24,440 --> 01:02:24,940 Dave got it. 1490 01:02:24,940 --> 01:02:26,700 Dave swept it. 1491 01:02:26,700 --> 01:02:28,730 It was sort of declining, sort of going up. 1492 01:02:28,730 --> 01:02:30,670 Dave completely emptied the mempool. 1493 01:02:30,670 --> 01:02:31,870 There's nothing in there. 1494 01:02:31,870 --> 01:02:33,850 And there's no new coins coming out. 1495 01:02:33,850 --> 01:02:37,350 So I'm what, Eve, I'm the attacker. 1496 01:02:37,350 --> 01:02:41,940 Eve is always the bad person, right? 1497 01:02:41,940 --> 01:02:47,090 So what's also even better, I say, OK, I'm going to build-- 1498 01:02:47,090 --> 01:02:49,560 I'm going to try to reorg out Carol. 1499 01:02:49,560 --> 01:02:51,780 I can take all the fees here. 1500 01:02:51,780 --> 01:02:54,360 I can take the two bitcoins here and the one bitcoin here, 1501 01:02:54,360 --> 01:02:56,220 and I can mine it into this block. 1502 01:02:56,220 --> 01:02:57,960 This block is not valid yet, right? 1503 01:02:57,960 --> 01:02:59,010 This is higher. 1504 01:02:59,010 --> 01:03:02,090 But I might build another block here. 1505 01:03:02,090 --> 01:03:03,840 And then I might build another block here. 1506 01:03:03,840 --> 01:03:05,940 And by now there might be some coins. 1507 01:03:05,940 --> 01:03:07,350 So now I get four coins. 1508 01:03:07,350 --> 01:03:09,790 I could have mined here and gotten nothing. 1509 01:03:09,790 --> 01:03:12,820 If this happens and I pull it off, "puh-toom," OK, 1510 01:03:12,820 --> 01:03:15,800 Carol and Dave's coins are now mine. 1511 01:03:15,800 --> 01:03:17,615 So this is a-- 1512 01:03:17,615 --> 01:03:19,910 And to some extent, you might think, well, 1513 01:03:19,910 --> 01:03:21,940 whatever, it's a little messy, but this is not 1514 01:03:21,940 --> 01:03:23,290 the worst thing in the world. 1515 01:03:23,290 --> 01:03:24,520 You still make progress. 1516 01:03:24,520 --> 01:03:26,050 It's actually really bad. 1517 01:03:26,050 --> 01:03:29,740 Because you're now trading this sort of memoryless process 1518 01:03:29,740 --> 01:03:31,930 where everyone's competing on a level playing ground 1519 01:03:31,930 --> 01:03:35,770 where whoever can mine fastest is always going to win here. 1520 01:03:35,770 --> 01:03:40,318 So now if you're a miner that's twice as big as the next guy, 1521 01:03:40,318 --> 01:03:42,610 you're always going to be able to do this-- not always, 1522 01:03:42,610 --> 01:03:43,750 there's still some-- 1523 01:03:43,750 --> 01:03:47,950 but this really reduces the variance 1524 01:03:47,950 --> 01:03:50,590 and really incentivizes the miners to consolidate. 1525 01:03:50,590 --> 01:03:53,470 And you're going to end up with a monopoly 1526 01:03:53,470 --> 01:03:56,598 in this kind of a scenario, because small players will just 1527 01:03:56,598 --> 01:03:57,640 always get a reorged out. 1528 01:04:00,960 --> 01:04:03,072 Yeah, so the question-- is this an attack? 1529 01:04:03,072 --> 01:04:05,280 It seems like they're just trying to get paid, right? 1530 01:04:07,968 --> 01:04:10,010 The whole idea is you're not trusting the miners. 1531 01:04:10,010 --> 01:04:11,900 You're just assuming that they're acting 1532 01:04:11,900 --> 01:04:13,468 in their economic interests. 1533 01:04:13,468 --> 01:04:16,010 To some extent, you could say, well, if they keep doing this, 1534 01:04:16,010 --> 01:04:18,000 they reduce the utility of Bitcoin, 1535 01:04:18,000 --> 01:04:20,180 and so it's bad for their holdings. 1536 01:04:20,180 --> 01:04:25,460 Yeah, maybe, but it looks dangerous, right? 1537 01:04:25,460 --> 01:04:27,920 However, this isn't a problem. 1538 01:04:27,920 --> 01:04:29,930 We don't see this problem today. 1539 01:04:29,930 --> 01:04:32,770 There have actually been several cases where we should have, 1540 01:04:32,770 --> 01:04:34,770 where it would have been optimal for the miners. 1541 01:04:34,770 --> 01:04:37,430 So someone made a fee that was like 1,000-- 1542 01:04:37,430 --> 01:04:39,765 no, it was 400 bitcoins or something. 1543 01:04:39,765 --> 01:04:40,640 They just screwed up. 1544 01:04:40,640 --> 01:04:44,180 They made a transaction, and they 1545 01:04:44,180 --> 01:04:45,680 were spending like 1,000 bitcoins 1546 01:04:45,680 --> 01:04:47,570 and they only sent like 600 out or something. 1547 01:04:47,570 --> 01:04:49,570 So the fee was 400 bitcoins, which is like, 1548 01:04:49,570 --> 01:04:51,650 hey, that's way more than a block. 1549 01:04:51,650 --> 01:04:52,960 That's millions of dollars. 1550 01:04:52,960 --> 01:04:54,710 It wasn't when it was millions of dollars, 1551 01:04:54,710 --> 01:04:56,180 but it's still a ton of money. 1552 01:04:56,180 --> 01:04:58,280 And the miners, if they were rational, 1553 01:04:58,280 --> 01:04:59,742 they should have all just stopped 1554 01:04:59,742 --> 01:05:01,700 and all tried to fight each other over that one 1555 01:05:01,700 --> 01:05:03,890 block and that one transaction, because it's 1556 01:05:03,890 --> 01:05:07,770 so much more valuable than progressing the chain. 1557 01:05:07,770 --> 01:05:09,740 However, they didn't, because they were just 1558 01:05:09,740 --> 01:05:12,470 running their software. 1559 01:05:12,470 --> 01:05:15,070 They weren't anticipating this kind of thing. 1560 01:05:15,070 --> 01:05:17,998 However, if this becomes, long term, the general state 1561 01:05:17,998 --> 01:05:20,040 of the network, they'll definitely anticipate it, 1562 01:05:20,040 --> 01:05:22,470 and they'll write the software to do this. 1563 01:05:22,470 --> 01:05:24,750 So it's not a problem when there's low reward 1564 01:05:24,750 --> 01:05:26,190 variance from block to block. 1565 01:05:26,190 --> 01:05:28,980 If every block-- if the next block coming out 1566 01:05:28,980 --> 01:05:30,875 has about the same fees as the last one, 1567 01:05:30,875 --> 01:05:32,250 then you just keep building on it 1568 01:05:32,250 --> 01:05:35,580 and you're not trying to snipe other people in the past. 1569 01:05:35,580 --> 01:05:37,830 But that means there's going to be a backlog. 1570 01:05:37,830 --> 01:05:40,830 You need this really big mempool with a large backlog 1571 01:05:40,830 --> 01:05:43,380 of transactions to ensure that you 1572 01:05:43,380 --> 01:05:48,640 have low variance in the rewards and to ensure that, long term, 1573 01:05:48,640 --> 01:05:50,750 you've got a stable system. 1574 01:05:50,750 --> 01:05:53,070 So this is tricky. 1575 01:05:53,070 --> 01:05:54,800 This is a hard problem. 1576 01:05:54,800 --> 01:05:57,890 Because you've already got these sort of scalability 1577 01:05:57,890 --> 01:06:00,500 balances in Bitcoin. 1578 01:06:00,500 --> 01:06:04,400 One of them is related to your hardware. 1579 01:06:04,400 --> 01:06:07,460 So if you say, OK, we're going to make the block size really 1580 01:06:07,460 --> 01:06:10,250 small, we're going to make the block size 10 kilobytes, 1581 01:06:10,250 --> 01:06:13,490 so you can only have a few transactions every 10 minutes, 1582 01:06:13,490 --> 01:06:15,530 if it's too small, then very few people 1583 01:06:15,530 --> 01:06:18,620 can actually use Bitcoin. 1584 01:06:18,620 --> 01:06:20,780 There's just not that many transactions a second. 1585 01:06:20,780 --> 01:06:22,697 Most people will have something like Coinbase, 1586 01:06:22,697 --> 01:06:24,740 where someone else holds the coins for them. 1587 01:06:24,740 --> 01:06:25,520 That's no fun. 1588 01:06:25,520 --> 01:06:27,202 The point is to have your own UTXO, 1589 01:06:27,202 --> 01:06:28,910 so really be in control of your own money 1590 01:06:28,910 --> 01:06:31,430 and have your own private keys. 1591 01:06:31,430 --> 01:06:33,710 However, if the blocks are too large, 1592 01:06:33,710 --> 01:06:36,170 then not many people can run it. 1593 01:06:36,170 --> 01:06:38,150 If the blocks are a gigabyte each 1594 01:06:38,150 --> 01:06:42,080 and you've got these petabyte-sized blockchains, 1595 01:06:42,080 --> 01:06:43,190 I can't run that. 1596 01:06:43,190 --> 01:06:45,050 I need a data center. 1597 01:06:45,050 --> 01:06:47,510 And then you can't really verify and validate 1598 01:06:47,510 --> 01:06:50,390 that the system is operating the way you think it will. 1599 01:06:50,390 --> 01:06:52,550 You're just going to have to trust, again, 1600 01:06:52,550 --> 01:06:54,860 some kind of big institution to do it for you. 1601 01:06:54,860 --> 01:06:56,900 So they both sort of turn into the same thing 1602 01:06:56,900 --> 01:06:58,400 when you're at the extremes. 1603 01:06:58,400 --> 01:07:00,903 If it's too small, well, I can't really own my own coins, 1604 01:07:00,903 --> 01:07:02,570 I got to have someone else do it for me. 1605 01:07:02,570 --> 01:07:05,120 If it's too large, I guess I can own my own private keys, 1606 01:07:05,120 --> 01:07:07,537 but I have no idea if they're actually-- 1607 01:07:07,537 --> 01:07:09,620 if there's an actual transaction in the blockchain 1608 01:07:09,620 --> 01:07:12,980 because I can't download it. 1609 01:07:12,980 --> 01:07:15,440 So these are sort of balances based on hardware. 1610 01:07:15,440 --> 01:07:19,160 And we're thinking, well, as computers get more powerful 1611 01:07:19,160 --> 01:07:21,260 and networks get more powerful, we can sort of 1612 01:07:21,260 --> 01:07:24,500 get into the larger side and people will still 1613 01:07:24,500 --> 01:07:25,563 be able to run it. 1614 01:07:25,563 --> 01:07:26,480 And we have seen that. 1615 01:07:26,480 --> 01:07:29,060 So like with SegWit, the block size 1616 01:07:29,060 --> 01:07:30,800 has been increased through software. 1617 01:07:30,800 --> 01:07:33,770 So it now takes a bit more space and more network traffic 1618 01:07:33,770 --> 01:07:36,040 to use. 1619 01:07:36,040 --> 01:07:38,650 However, the long-term fee sniping thing, 1620 01:07:38,650 --> 01:07:40,180 it's not hardware related. 1621 01:07:40,180 --> 01:07:42,460 Even if you had perfect computers that 1622 01:07:42,460 --> 01:07:44,380 were sort of like, oh, this network can send 1623 01:07:44,380 --> 01:07:47,560 any amount of data instantly, we've got unlimited drive 1624 01:07:47,560 --> 01:07:51,160 space, these are computronium-- 1625 01:07:51,160 --> 01:07:55,550 that's a thing, right, the theoretical maximum computer. 1626 01:07:55,550 --> 01:07:57,400 So even if you have this amazing computer 1627 01:07:57,400 --> 01:07:59,920 and the hardware limits are not a limit at all, 1628 01:07:59,920 --> 01:08:03,610 you still have to balance the block size. 1629 01:08:03,610 --> 01:08:06,110 Because if you make your block size too large, 1630 01:08:06,110 --> 01:08:08,225 you're going to have that problem long term, where 1631 01:08:08,225 --> 01:08:10,600 there's no real fee market because there's no competition 1632 01:08:10,600 --> 01:08:12,100 to get into the blocks. 1633 01:08:12,100 --> 01:08:16,600 And so the whole system kinds of halts, and then you've 1634 01:08:16,600 --> 01:08:19,060 got the largest miner just keep winning. 1635 01:08:19,060 --> 01:08:23,220 So this is a mess. 1636 01:08:23,220 --> 01:08:25,752 There's a paper. 1637 01:08:25,752 --> 01:08:26,460 What's it called? 1638 01:08:30,000 --> 01:08:34,183 Like, Bitcoin Is Not Stable Without a Fee or something. 1639 01:08:34,183 --> 01:08:36,175 It's Princeton guys, right? 1640 01:08:45,830 --> 01:08:49,430 "On the Instability of Bitcoin Without the Block Reward." 1641 01:08:49,430 --> 01:08:52,189 And to be fair-- 1642 01:08:52,189 --> 01:08:53,590 yeah, these are Princeton guys. 1643 01:08:53,590 --> 01:08:58,930 To be fair-- and they write about this issue. 1644 01:08:58,930 --> 01:09:02,680 But it's a little weird, because one of their assumptions 1645 01:09:02,680 --> 01:09:04,060 is that-- 1646 01:09:04,060 --> 01:09:05,569 mining strategy simulator. 1647 01:09:05,569 --> 01:09:09,790 Anyway, one of their assumptions is that every miner completely 1648 01:09:09,790 --> 01:09:12,370 wipes out the mempool at every block. 1649 01:09:12,370 --> 01:09:14,500 And it's like, wait, that assumption-- 1650 01:09:14,500 --> 01:09:17,202 given that assumption, yes, you can show that it's unstable 1651 01:09:17,202 --> 01:09:19,660 and there's all these problems, like I was sort of showing. 1652 01:09:19,660 --> 01:09:22,330 But that assumption is a huge assumption. 1653 01:09:22,330 --> 01:09:24,475 And a lot of the people working on Bitcoin 1654 01:09:24,475 --> 01:09:26,350 are like, no, you can't make that assumption. 1655 01:09:26,350 --> 01:09:29,649 Because we're aware that there's these instability problems, 1656 01:09:29,649 --> 01:09:33,760 and the solution, to the extent that it's a solution, is always 1657 01:09:33,760 --> 01:09:35,319 have a backlog. 1658 01:09:35,319 --> 01:09:38,680 There's a really big demand for transactions, 1659 01:09:38,680 --> 01:09:40,240 and there's not enough space, and so 1660 01:09:40,240 --> 01:09:43,450 people have to compete based on their fees. 1661 01:09:43,450 --> 01:09:46,000 In that case, you can have a stable system, long term, 1662 01:09:46,000 --> 01:09:47,109 where the miners get paid. 1663 01:09:47,109 --> 01:09:49,859 But without it, these guys show it. 1664 01:09:49,859 --> 01:09:52,890 And so yeah, it's true, but it's sort of weird 1665 01:09:52,890 --> 01:09:54,600 because one of their assumptions is 1666 01:09:54,600 --> 01:09:59,160 that there are no fees, long term, essentially. 1667 01:09:59,160 --> 01:10:04,950 So yeah, this is a weird issue, and it's also how, timing-wise, 1668 01:10:04,950 --> 01:10:06,600 do we need to worry about this now? 1669 01:10:06,600 --> 01:10:08,937 Maybe we can just punt the problem for a decade 1670 01:10:08,937 --> 01:10:11,520 and try to get lots of adoption, lots of people using Bitcoin, 1671 01:10:11,520 --> 01:10:14,478 and we'll figure it out once it's really well established. 1672 01:10:14,478 --> 01:10:15,520 I don't think that works. 1673 01:10:15,520 --> 01:10:17,770 I think it's harder and harder to change these systems 1674 01:10:17,770 --> 01:10:19,530 as more people use it. 1675 01:10:19,530 --> 01:10:21,300 So maybe we're stuck. 1676 01:10:21,300 --> 01:10:24,120 And it's almost certain that one megabyte or four megabytes 1677 01:10:24,120 --> 01:10:25,900 is not the optimal size. 1678 01:10:25,900 --> 01:10:27,900 We have no idea what the optimal size is, right? 1679 01:10:27,900 --> 01:10:29,700 Long term-- because also, long term, 1680 01:10:29,700 --> 01:10:31,367 how many people are going to using this, 1681 01:10:31,367 --> 01:10:34,330 and for what, and for what kind of transactions? 1682 01:10:34,330 --> 01:10:38,000 So it's definitely an open problem. 1683 01:10:38,000 --> 01:10:42,570 Yeah, so we're sort of at the dawn of the fees. 1684 01:10:42,570 --> 01:10:46,177 A year ago, we didn't have all these things. 1685 01:10:46,177 --> 01:10:48,010 We're starting to understand the fee markets 1686 01:10:48,010 --> 01:10:50,380 and see how it works. 1687 01:10:50,380 --> 01:10:52,210 What's interesting is that the elasticity 1688 01:10:52,210 --> 01:10:54,880 seems like people really want their transactions in when 1689 01:10:54,880 --> 01:10:56,920 they want them in, which I guess can make sense. 1690 01:10:56,920 --> 01:11:00,505 If the price of Bitcoin spikes to $18,000, 1691 01:11:00,505 --> 01:11:03,130 and you're like, I want to sell one, it's going to crash, 1692 01:11:03,130 --> 01:11:05,230 and you're like, yeah, I'll pay $50 to move it, 1693 01:11:05,230 --> 01:11:08,080 to sell to someone, because I'm selling millions of dollars 1694 01:11:08,080 --> 01:11:09,710 worth. 1695 01:11:09,710 --> 01:11:12,530 And so it seems really inelastic. 1696 01:11:12,530 --> 01:11:15,860 You also have people, companies, wasting millions 1697 01:11:15,860 --> 01:11:18,680 of dollars on fees that you can just be like, why'd you do-- 1698 01:11:18,680 --> 01:11:20,780 oh, OK. 1699 01:11:20,780 --> 01:11:23,900 You're wasting on space, wasting on fees. 1700 01:11:23,900 --> 01:11:25,602 It is a fun research area. 1701 01:11:25,602 --> 01:11:26,810 And it's definitely research. 1702 01:11:26,810 --> 01:11:28,490 And so I'm like, yeah, I hope this works. 1703 01:11:28,490 --> 01:11:30,950 We don't really know, long term, if this whole system is stable 1704 01:11:30,950 --> 01:11:31,450 and works. 1705 01:11:33,950 --> 01:11:35,120 I think it can. 1706 01:11:35,120 --> 01:11:40,940 But it's not something to base the global economy on just yet, 1707 01:11:40,940 --> 01:11:44,750 because we're not quite sure it all really works long term, 1708 01:11:44,750 --> 01:11:47,050 but we think it does. 1709 01:11:47,050 --> 01:11:50,347 OK, any questions about this sort of long-range attack 1710 01:11:50,347 --> 01:11:50,847 stuff? 1711 01:11:54,050 --> 01:11:54,730 Yes. 1712 01:11:54,730 --> 01:11:57,385 AUDIENCE: What's the case with a bunch alt coins points 1713 01:11:57,385 --> 01:11:59,900 that don't have full members? 1714 01:11:59,900 --> 01:12:01,150 TADGE DRYJA: Alt coins? 1715 01:12:01,150 --> 01:12:03,100 AUDIENCE: The rest of the cryptocurrency space 1716 01:12:03,100 --> 01:12:05,360 that has sparse mempools. 1717 01:12:05,360 --> 01:12:07,940 TADGE DRYJA: They generally don't have fees, 1718 01:12:07,940 --> 01:12:10,953 or the fees are enforced-- 1719 01:12:10,953 --> 01:12:11,870 you can enforce a fee. 1720 01:12:11,870 --> 01:12:15,800 You can say, hey, the consensus rule of this system is that 1721 01:12:15,800 --> 01:12:21,990 every transaction has to have a 50-Satoshis-per-byte fee. 1722 01:12:21,990 --> 01:12:24,360 There's problems with that, because then you 1723 01:12:24,360 --> 01:12:27,210 can have out-of-band fees where, if you 1724 01:12:27,210 --> 01:12:30,960 try to make it a consensus rule, it doesn't really work. 1725 01:12:30,960 --> 01:12:33,150 It's sort of like price controls, where you can say, 1726 01:12:33,150 --> 01:12:36,600 hey, you have to sell milk for $2 a gallon. 1727 01:12:36,600 --> 01:12:39,030 And it's like, well, that's not what the market says. 1728 01:12:39,030 --> 01:12:40,238 So people can go out of band. 1729 01:12:40,238 --> 01:12:42,197 And then they're saying, OK, the consensus rule 1730 01:12:42,197 --> 01:12:44,940 is I have to pay this fee, but really, how about you give me 1731 01:12:44,940 --> 01:12:46,170 some of it back? 1732 01:12:46,170 --> 01:12:49,170 Or-- so generally the rules they put 1733 01:12:49,170 --> 01:12:50,850 in are minimum fees, which you can 1734 01:12:50,850 --> 01:12:53,730 try to work around that way. 1735 01:12:53,730 --> 01:12:56,615 But in general, most of the other alt coins-- 1736 01:12:56,615 --> 01:12:58,740 with the exception of Ethereum, Ethereum definitely 1737 01:12:58,740 --> 01:12:59,770 has similar issues-- 1738 01:12:59,770 --> 01:13:02,490 but most of the alt coins have a block size 1739 01:13:02,490 --> 01:13:05,190 or a network capacity that exceeds their uses. 1740 01:13:05,190 --> 01:13:07,410 So there isn't really competition 1741 01:13:07,410 --> 01:13:08,990 to get into the next block. 1742 01:13:08,990 --> 01:13:13,350 Ethereum, though, similar to Bitcoin, has-- 1743 01:13:13,350 --> 01:13:17,110 well, I don't-- where did it go? 1744 01:13:17,110 --> 01:13:18,407 This kind of thing. 1745 01:13:18,407 --> 01:13:19,990 I don't know, if you graphed Ethereum, 1746 01:13:19,990 --> 01:13:21,940 it probably wouldn't look quite the same. 1747 01:13:21,940 --> 01:13:24,820 But there are also times in Ethereum 1748 01:13:24,820 --> 01:13:27,530 where the fees skyrocket. 1749 01:13:27,530 --> 01:13:29,360 A lot of times with ICOs, everyone 1750 01:13:29,360 --> 01:13:31,200 wants to get in their bids really quick, 1751 01:13:31,200 --> 01:13:34,130 and so the network will get super congested for a day, 1752 01:13:34,130 --> 01:13:37,190 and no one can use it for anything-- for normal uses. 1753 01:13:37,190 --> 01:13:39,120 So Ethereum also has this problem. 1754 01:13:39,120 --> 01:13:41,570 It's not quite the same in that it's not a block size, 1755 01:13:41,570 --> 01:13:44,080 it's a gas per block kind of thing, 1756 01:13:44,080 --> 01:13:46,220 so how much computation or storage it's using. 1757 01:13:46,220 --> 01:13:50,595 But in practice it's a similar thing. 1758 01:13:50,595 --> 01:13:52,220 So yeah, those are sort of the only two 1759 01:13:52,220 --> 01:13:56,840 that I'm aware of that really have hit this issue so far. 1760 01:13:59,640 --> 01:14:02,870 Any other questions about this, the long term? 1761 01:14:02,870 --> 01:14:04,170 Yes. 1762 01:14:04,170 --> 01:14:06,870 AUDIENCE: Could you comment on blockchains 1763 01:14:06,870 --> 01:14:10,160 that have no transaction fee, particularly blockchains that 1764 01:14:10,160 --> 01:14:11,965 are designed for things like IoT, 1765 01:14:11,965 --> 01:14:15,145 and which pay to be able to handle microtransactions 1766 01:14:15,145 --> 01:14:19,953 and transactions at face value without any fee. 1767 01:14:19,953 --> 01:14:21,870 TADGE DRYJA: Should I take advice from counsel 1768 01:14:21,870 --> 01:14:23,370 before commenting on this? 1769 01:14:23,370 --> 01:14:24,510 [LAUGHTER] 1770 01:14:24,510 --> 01:14:26,292 Yeah, so you could Google-- 1771 01:14:26,292 --> 01:14:27,750 there's one, I don't know if you're 1772 01:14:27,750 --> 01:14:29,375 talking about it specifically-- there's 1773 01:14:29,375 --> 01:14:32,850 one called Iota that we looked at last summer. 1774 01:14:32,850 --> 01:14:35,310 My mom tells me, if you don't have anything nice to say, 1775 01:14:35,310 --> 01:14:36,540 don't say anything. 1776 01:14:36,540 --> 01:14:42,240 But we did say quite a bit in our report. 1777 01:14:42,240 --> 01:14:43,740 That one specifically, I don't think 1778 01:14:43,740 --> 01:14:45,870 it really works that well. 1779 01:14:45,870 --> 01:14:50,800 Actually, they have a fee, they just pretend they don't. 1780 01:14:50,800 --> 01:14:52,050 But they very much have a fee. 1781 01:14:52,050 --> 01:14:53,970 So in Iota's case, they say, you have 1782 01:14:53,970 --> 01:14:55,520 to do work on your transaction. 1783 01:14:55,520 --> 01:14:57,330 You have to mine your transaction. 1784 01:14:57,330 --> 01:14:58,620 And they say that's not a fee. 1785 01:14:58,620 --> 01:15:01,140 Well, OK, it's on a fee you're paying to some other miner, 1786 01:15:01,140 --> 01:15:03,000 but you're still doing work. 1787 01:15:03,000 --> 01:15:04,200 That has a cost. 1788 01:15:04,200 --> 01:15:05,700 You can say it's a cost, not a fee. 1789 01:15:05,700 --> 01:15:06,600 I don't know. 1790 01:15:06,600 --> 01:15:10,050 But it feels like saying, hey, this refrigerator doesn't need 1791 01:15:10,050 --> 01:15:12,900 electricity to run, it's just got a hand crank in the back 1792 01:15:12,900 --> 01:15:14,488 that you have to-- 1793 01:15:14,488 --> 01:15:16,030 yeah, OK, I don't have to plug it in, 1794 01:15:16,030 --> 01:15:19,410 but I still have to do all the work. 1795 01:15:19,410 --> 01:15:23,050 So it's an anti-spam measure which you have to do work on. 1796 01:15:23,050 --> 01:15:25,020 So it's the same new thing. 1797 01:15:25,020 --> 01:15:27,540 But there are some that have no fee whatsoever, 1798 01:15:27,540 --> 01:15:29,850 and they're very susceptible to spamming. 1799 01:15:29,850 --> 01:15:32,670 If there's no fee, what stops me from just sending out 1800 01:15:32,670 --> 01:15:34,230 a bazillion transactions and having 1801 01:15:34,230 --> 01:15:35,850 everyone else store them? 1802 01:15:35,850 --> 01:15:38,610 AUDIENCE: Generally well MANO is one of them 1803 01:15:38,610 --> 01:15:40,560 that claims to be instant no fees, et cetera. 1804 01:15:40,560 --> 01:15:43,050 But what that means is, to get around that, 1805 01:15:43,050 --> 01:15:45,915 they've made it so that you don't need global consensus-- 1806 01:15:45,915 --> 01:15:48,460 until you do need global consensus, at which point 1807 01:15:48,460 --> 01:15:50,410 you do proof of state and [INAUDIBLE].. 1808 01:15:50,410 --> 01:15:52,850 But since there are no fees, it's 1809 01:15:52,850 --> 01:15:56,390 free to just calls for state to happen every round, 1810 01:15:56,390 --> 01:15:59,772 [INAUDIBLE] a bunch of conflicting transactions. 1811 01:15:59,772 --> 01:16:00,480 TADGE DRYJA: Huh. 1812 01:16:00,480 --> 01:16:06,450 Yeah, there's a lot of really smart people, way smarter 1813 01:16:06,450 --> 01:16:08,430 than me, working on these things. 1814 01:16:08,430 --> 01:16:10,080 And it's a hard problem, and they seem 1815 01:16:10,080 --> 01:16:11,288 to think it's a hard problem. 1816 01:16:11,288 --> 01:16:14,520 So I'm very skeptical when someone, especially 1817 01:16:14,520 --> 01:16:16,620 with a financial interest in getting me to believe 1818 01:16:16,620 --> 01:16:17,580 that they've solved this problem, 1819 01:16:17,580 --> 01:16:19,890 says, hey, I've solved the problem, zero fees, 1820 01:16:19,890 --> 01:16:21,180 infinite scalability. 1821 01:16:21,180 --> 01:16:23,810 I'm just very skeptical when I see that. 1822 01:16:23,810 --> 01:16:25,325 Because, OK, what did you do? 1823 01:16:25,325 --> 01:16:26,700 Like, we've been looking at this. 1824 01:16:26,700 --> 01:16:29,520 Maybe there's something there. 1825 01:16:29,520 --> 01:16:33,873 But I haven't seen any really great stuff. 1826 01:16:33,873 --> 01:16:36,540 There's Lightning Network, which I'll talk about in a few weeks, 1827 01:16:36,540 --> 01:16:40,740 and I think that's pretty cool, and I sort of work on that. 1828 01:16:40,740 --> 01:16:43,860 There's other different ways to do this. 1829 01:16:43,860 --> 01:16:47,683 But in general, there's got to be a cost. 1830 01:16:47,683 --> 01:16:48,600 There's no free lunch. 1831 01:16:48,600 --> 01:16:49,890 And you're going to have to-- 1832 01:16:49,890 --> 01:16:52,530 if you're requiring other people to store a lot of data 1833 01:16:52,530 --> 01:16:56,060 and process it, there's got to be some kind of limit there.