WEBVTT 00:00:01.090 --> 00:00:03.460 The following content is provided under a Creative 00:00:03.460 --> 00:00:04.850 Commons license. 00:00:04.850 --> 00:00:07.060 Your support will help MIT OpenCourseWare 00:00:07.060 --> 00:00:11.150 continue to offer high-quality educational resources for free. 00:00:11.150 --> 00:00:13.690 To make a donation, or to view additional materials 00:00:13.690 --> 00:00:17.650 from hundreds of MIT courses, visit MIT OpenCourseWare 00:00:17.650 --> 00:00:18.550 at ocw.mit.edu. 00:00:22.160 --> 00:00:26.150 TADGE DRYJA: Today we're going to talk about wallets and SPV. 00:00:26.150 --> 00:00:28.010 And if you don't know what SPV stands 00:00:28.010 --> 00:00:31.040 for, that will be defined as well, so don't worry. 00:00:31.040 --> 00:00:32.330 First, you get your software. 00:00:32.330 --> 00:00:34.202 That's something of a problem, like how 00:00:34.202 --> 00:00:36.160 do you know you got the right Bitcoin software, 00:00:36.160 --> 00:00:37.520 there can be issues there, but anyway-- 00:00:37.520 --> 00:00:39.200 there are multiple implementations that 00:00:39.200 --> 00:00:41.180 should be consensus compatible. 00:00:41.180 --> 00:00:44.930 I often use BTCD, which is a version written in Go, 00:00:44.930 --> 00:00:49.433 but the main implementation is written in c++. 00:00:49.433 --> 00:00:50.850 So, you get the software, and then 00:00:50.850 --> 00:00:53.100 you somehow connect to peers in the network, 00:00:53.100 --> 00:00:54.960 but there's all these asterisks, which 00:00:54.960 --> 00:00:56.585 mean it's not completely decentralized. 00:00:56.585 --> 00:00:57.720 You have to find where to get it, 00:00:57.720 --> 00:00:59.250 you have to find who to connect to. 00:00:59.250 --> 00:01:01.600 Once you do that, you get all the headers, which 00:01:01.600 --> 00:01:04.267 are 80 bytes each, you verify all the work, 00:01:04.267 --> 00:01:05.850 and then you start getting the blocks, 00:01:05.850 --> 00:01:07.440 looking through the transactions. 00:01:07.440 --> 00:01:10.920 You replay the history of the last nine years of the coin, 00:01:10.920 --> 00:01:12.630 and then you arrive at a UTXO set, 00:01:12.630 --> 00:01:16.360 an unspent transaction output set, 00:01:16.360 --> 00:01:18.660 and it should be the same as everyone else got. 00:01:18.660 --> 00:01:20.910 Everyone else has the same headers, the same work, 00:01:20.910 --> 00:01:22.290 the same transactions. 00:01:22.290 --> 00:01:26.100 They'll get the same set of which coins are encumbered 00:01:26.100 --> 00:01:29.970 by which keys as you do. 00:01:29.970 --> 00:01:32.640 And the idea is it would be very expensive to have 00:01:32.640 --> 00:01:36.490 different UTXO sets because you'd have to do all that work. 00:01:36.490 --> 00:01:39.040 So that's how a node works. 00:01:39.040 --> 00:01:41.040 But what about dealing with actual money? 00:01:41.040 --> 00:01:43.560 So far, we've just looked at here's 00:01:43.560 --> 00:01:45.630 how to get your node running, here's 00:01:45.630 --> 00:01:47.430 how to observe the network and come 00:01:47.430 --> 00:01:49.263 to the same conclusion as everyone else, 00:01:49.263 --> 00:01:51.180 but you probably want to actually do something 00:01:51.180 --> 00:01:51.870 with this. 00:01:51.870 --> 00:01:54.270 You want to pay people or get paid. 00:01:54.270 --> 00:01:57.150 Those are the two fundamental functions 00:01:57.150 --> 00:01:58.980 that this tries to address. 00:01:58.980 --> 00:02:02.610 So the software that manages this feature is called 00:02:02.610 --> 00:02:05.220 a wallet, and it's not necessarily 00:02:05.220 --> 00:02:08.580 the same software as what's connecting to the network, 00:02:08.580 --> 00:02:10.350 downloading, and verifying. 00:02:10.350 --> 00:02:12.968 In the case of Bitcoin Core, it is, 00:02:12.968 --> 00:02:15.510 although many of the programmers of Bitcoin Core wish that it 00:02:15.510 --> 00:02:16.500 weren't. 00:02:16.500 --> 00:02:18.120 And there's sort of a long-term goal 00:02:18.120 --> 00:02:21.600 of, it'd be really great if we could pull these two 00:02:21.600 --> 00:02:24.840 things apart into maybe separate binaries, separate programs, 00:02:24.840 --> 00:02:26.340 something. 00:02:26.340 --> 00:02:29.130 But they're really intertwined, and it's kind of ugly. 00:02:29.130 --> 00:02:31.880 But there are other things that are separate 00:02:31.880 --> 00:02:36.510 OK, so wallet software functionality-- seems simple, 00:02:36.510 --> 00:02:39.360 you send and receive money. 00:02:39.360 --> 00:02:40.400 Simple. 00:02:40.400 --> 00:02:42.900 Of course, you need to receive money before you can send it, 00:02:42.900 --> 00:02:45.760 so let's start with that. 00:02:45.760 --> 00:02:50.100 OK, so we did not talk about receive addresses. 00:02:50.100 --> 00:02:53.250 We did talk about the script, and how it's generally 00:02:53.250 --> 00:02:58.350 used pay to pubkey hash, where you put the hash of your pubkey 00:02:58.350 --> 00:03:00.870 in your output script, and then in your redeem script, 00:03:00.870 --> 00:03:02.580 in your input, you put the pubkey 00:03:02.580 --> 00:03:04.890 itself, which is then checked against the hash, 00:03:04.890 --> 00:03:07.020 and then the signature is verified. 00:03:07.020 --> 00:03:09.390 Most likely, if you've looked at Bitcoin at all, 00:03:09.390 --> 00:03:12.060 you've seen these types of addresses. 00:03:12.060 --> 00:03:15.000 They usually start with 1, they're a bunch of characters 00:03:15.000 --> 00:03:18.270 long, a weird mix of lowercase, uppercase, Latin numbers, 00:03:18.270 --> 00:03:19.530 and letters. 00:03:19.530 --> 00:03:22.560 There is a standard for converting a 20-byte pubkey 00:03:22.560 --> 00:03:24.547 hash into this address. 00:03:24.547 --> 00:03:26.130 So the idea is since almost everything 00:03:26.130 --> 00:03:28.740 is using the same pubkey hash script, 00:03:28.740 --> 00:03:31.110 you can forget about the opcodes, 00:03:31.110 --> 00:03:34.350 like op_dup, op_hash160, op_equalverify 00:03:34.350 --> 00:03:35.850 because they're always the same. 00:03:35.850 --> 00:03:37.767 And so it's this standard, like, OK we're just 00:03:37.767 --> 00:03:39.600 taking that 20-byte hash, and now 00:03:39.600 --> 00:03:41.820 let's convert it to something hopefully somewhat 00:03:41.820 --> 00:03:45.660 human readable and writeable so that people can write it down, 00:03:45.660 --> 00:03:47.130 say it over the phone. 00:03:47.130 --> 00:03:48.960 This is the one Satoshi made. 00:03:48.960 --> 00:03:53.230 It's got 58 characters and then the last 4 bytes, 00:03:53.230 --> 00:03:55.500 which ends up being like 5 or 6 of the letters, 00:03:55.500 --> 00:03:57.660 is sort of a checksum, where you take 00:03:57.660 --> 00:04:01.140 the hash of the first however many letters 00:04:01.140 --> 00:04:03.630 and then that's supposed to like equal to the next one. 00:04:03.630 --> 00:04:06.420 So, hopefully, if you typed something wrong, 00:04:06.420 --> 00:04:08.820 it doesn't change the hash and then 00:04:08.820 --> 00:04:11.220 you send it to the wrong place and then no one has 00:04:11.220 --> 00:04:13.020 a matching key for that. 00:04:13.020 --> 00:04:14.790 There's a newer standard for this 00:04:14.790 --> 00:04:17.790 where all the all the letters are lowercase. 00:04:17.790 --> 00:04:22.320 That's introduced, actually, today in Bitcoin Core. 00:04:22.320 --> 00:04:24.720 Version 0.16 came out, and so there's 00:04:24.720 --> 00:04:26.890 a new standard called Bech32. 00:04:26.890 --> 00:04:28.590 They did some research, and they found 00:04:28.590 --> 00:04:30.720 it was actually much faster to transmit over 00:04:30.720 --> 00:04:33.120 the phone via voice because you didn't 00:04:33.120 --> 00:04:35.640 have to say whether things were uppercase or lowercase, 00:04:35.640 --> 00:04:38.090 which ended up being very annoying for people, 00:04:38.090 --> 00:04:43.190 because, you know, 1 big F, a little f, 1, 2, big E, 4-- 00:04:43.190 --> 00:04:44.160 it's annoying. 00:04:44.160 --> 00:04:47.520 Anyway, the idea is this is just an encoding 00:04:47.520 --> 00:04:49.620 of the 20-byte pubkey hash, so when you type this 00:04:49.620 --> 00:04:52.560 into a program, it reads this, converts it 00:04:52.560 --> 00:04:55.590 into a 20-byte hash, builds the output script. 00:04:55.590 --> 00:04:58.500 OK, so the outputs are all the same. 00:04:58.500 --> 00:05:00.420 So this is sort of like a UI thing. 00:05:00.420 --> 00:05:05.390 The addresses don't really exist at the protocol level. 00:05:05.390 --> 00:05:08.510 Any questions about addresses? 00:05:08.510 --> 00:05:09.480 OK. 00:05:09.480 --> 00:05:10.710 We're not going to put-- 00:05:10.710 --> 00:05:14.790 UI and usability is super important, but not 00:05:14.790 --> 00:05:16.980 the focus yet of what we're doing. 00:05:16.980 --> 00:05:20.130 The idea, in a lot of cases, is you 00:05:20.130 --> 00:05:22.980 want to receive money and know that you received it, 00:05:22.980 --> 00:05:25.800 or somehow interact with people over computers, 00:05:25.800 --> 00:05:29.350 and you could put a bunch of addresses on a server, 00:05:29.350 --> 00:05:31.560 but keep your private keys offline. 00:05:31.560 --> 00:05:34.950 Because if you keep both your public key and your private key 00:05:34.950 --> 00:05:38.640 on the same computer, that's kind of an attractive target 00:05:38.640 --> 00:05:41.190 for someone to break into your system because they say, 00:05:41.190 --> 00:05:45.250 oh, this guy's running Bitcoin and he's accepting payments. 00:05:45.250 --> 00:05:47.250 There might be a bunch of money in this computer 00:05:47.250 --> 00:05:48.130 if I can get into it. 00:05:48.130 --> 00:05:50.220 I can take all the money. 00:05:50.220 --> 00:05:53.880 So one issue that people ran up against pretty early is-- 00:05:53.880 --> 00:05:58.680 well, let's say I generate 10 keys-- 00:05:58.680 --> 00:06:01.202 10 private keys, 10 public keys, 10 addresses. 00:06:01.202 --> 00:06:02.910 I put them on the server, then I run out. 00:06:02.910 --> 00:06:05.760 And I can reuse addresses, but that can hurt privacy 00:06:05.760 --> 00:06:08.670 because people can then see that the same people are 00:06:08.670 --> 00:06:09.840 using these keys. 00:06:09.840 --> 00:06:13.770 So is there any clever way we can generate pubkeys 00:06:13.770 --> 00:06:15.960 without the private key? 00:06:15.960 --> 00:06:20.460 Is there, given all the fun key stuff we've talked about, 00:06:20.460 --> 00:06:25.000 can anyone think of any clever ways to do that? 00:06:28.360 --> 00:06:31.280 OK, well pretty straightforward. 00:06:31.280 --> 00:06:36.320 This is called BIP32, Bitcoin Improvement Proposal 32. 00:06:36.320 --> 00:06:37.878 This is a super-simplified version, 00:06:37.878 --> 00:06:39.670 but this is the basic idea of what they do, 00:06:39.670 --> 00:06:42.030 and they do it much more involved and complicated. 00:06:42.030 --> 00:06:43.980 But basically, you've got your public key P-- 00:06:43.980 --> 00:06:46.850 big P-- and some kind of randomized data-- 00:06:46.850 --> 00:06:52.920 randomizer data, r and your private key is just little p. 00:06:56.030 --> 00:06:58.040 So the idea is you want to send to an address, 00:06:58.040 --> 00:06:59.498 you want to generate a new address. 00:06:59.498 --> 00:07:03.530 Well, it's just your public key plus the hash of r concatenated 00:07:03.530 --> 00:07:07.070 with 1 times G. And if you wanted to make this 2, 3, 00:07:07.070 --> 00:07:08.875 you can make this any number you want. 00:07:08.875 --> 00:07:10.250 And then your private key is just 00:07:10.250 --> 00:07:14.900 going to be that same public key plus the hash of r. 00:07:14.900 --> 00:07:16.550 So you give someone some extra data, 00:07:16.550 --> 00:07:19.130 which they can throw into a hash function. 00:07:19.130 --> 00:07:25.430 Use this as a known private key and you add it 00:07:25.430 --> 00:07:26.400 to your private key. 00:07:26.400 --> 00:07:31.150 So no one just knowing this data can spend from it. 00:07:31.150 --> 00:07:32.900 That's really nice because then the server 00:07:32.900 --> 00:07:34.790 can generate arbitrary numbers. 00:07:34.790 --> 00:07:36.602 Does this make sense? 00:07:36.602 --> 00:07:38.530 AUDIENCE: What's the difference big A and a? 00:07:38.530 --> 00:07:39.405 TADGE DRYJA: Oh, yes. 00:07:39.405 --> 00:07:41.810 So in the last one, big A is a public key. 00:07:41.810 --> 00:07:44.450 It's a point on the curve. 00:07:44.450 --> 00:07:45.710 Little a is the private key. 00:07:45.710 --> 00:07:48.890 I screwed that up. 00:07:48.890 --> 00:07:53.870 That does not have a G. So G is the generator for the group. 00:07:53.870 --> 00:07:57.950 G is how you convert from a private key to a public key. 00:07:57.950 --> 00:08:00.350 You just multiply by G, which is just an arbitrary point. 00:08:00.350 --> 00:08:00.850 Yes. 00:08:00.850 --> 00:08:03.678 AUDIENCE: So your private key doesn't change? 00:08:03.678 --> 00:08:05.970 TADGE DRYJA: So in this case, there's two private keys. 00:08:05.970 --> 00:08:07.710 There's your standard private key 00:08:07.710 --> 00:08:10.920 that you actually just randomly created-- this number p, 00:08:10.920 --> 00:08:14.250 multiply it by G, to get big P. But your private key 00:08:14.250 --> 00:08:17.160 for any particular address does change. 00:08:17.160 --> 00:08:22.660 You're adding the hash of r, 1 or r, 2, r,3. 00:08:22.660 --> 00:08:23.160 Yes? 00:08:23.160 --> 00:08:25.140 AUDIENCE: Assuming the size of r is relatively small 00:08:25.140 --> 00:08:27.090 compared to p because don't you have to keep 00:08:27.090 --> 00:08:28.690 track of the nonce? 00:08:28.690 --> 00:08:31.140 TADGE DRYJA: R should be, like, 32 bytes or something. 00:08:31.140 --> 00:08:32.390 You know, you don't want any-- 00:08:32.390 --> 00:08:33.684 AUDIENCE: Do you have to start with it every time that you 00:08:33.684 --> 00:08:35.340 create a new hash code? 00:08:35.340 --> 00:08:36.960 TADGE DRYJA: You sort of don't. 00:08:36.960 --> 00:08:40.414 What you can do is, you have your server. 00:08:40.414 --> 00:08:41.789 You say, hey, I'm going to accept 00:08:41.789 --> 00:08:44.850 payments for cookies or shoes or whatever I'm selling. 00:08:44.850 --> 00:08:48.210 And then you give the server your public key, P, 00:08:48.210 --> 00:08:51.810 and the randomizer r, and you just say to the server, 00:08:51.810 --> 00:08:56.160 go wild, make whatever number you want here. 00:08:56.160 --> 00:08:58.620 This number should be fairly small, 00:08:58.620 --> 00:09:00.870 let's say less than a billion. 00:09:00.870 --> 00:09:03.480 And then when you want to find how much you've gotten paid, 00:09:03.480 --> 00:09:06.900 well, you can generate a billion private keys here-- 00:09:06.900 --> 00:09:09.540 some reasonable number that the computer can actually do it-- 00:09:09.540 --> 00:09:11.520 and you could just increment this, 00:09:11.520 --> 00:09:13.980 generate a ton of addresses, and look for them 00:09:13.980 --> 00:09:16.500 on the blockchain. 00:09:16.500 --> 00:09:18.780 So does that makes sense at all? 00:09:18.780 --> 00:09:22.490 BIP32 is actually quite a bit more involved and complicated. 00:09:22.490 --> 00:09:25.970 This is the basic idea, but they make trees of it, 00:09:25.970 --> 00:09:29.080 and you can say, oh, well, we can make instead 00:09:29.080 --> 00:09:31.580 of just one level, we can make a whole tree of these things, 00:09:31.580 --> 00:09:33.680 and have different accounts, and make 00:09:33.680 --> 00:09:35.540 a really full-featured system in case people 00:09:35.540 --> 00:09:39.090 want to use this kind of thing. 00:09:39.090 --> 00:09:42.180 So you can put the public key and this random data 00:09:42.180 --> 00:09:43.050 on the server. 00:09:43.050 --> 00:09:46.200 The server can make addresses as needed, really quickly. 00:09:46.200 --> 00:09:49.470 And what's nice is observers can't link these addresses. 00:09:49.470 --> 00:09:51.180 If you're just looking at the blockchain, 00:09:51.180 --> 00:09:57.330 you won't see the difference between a sub 1 and a sub 2, 00:09:57.330 --> 00:09:59.130 if this number and 1 and 2 because it's 00:09:59.130 --> 00:10:01.020 going through this hash function, you never see that. 00:10:01.020 --> 00:10:03.270 To an observer, it looks like all completely different 00:10:03.270 --> 00:10:04.710 addresses. 00:10:04.710 --> 00:10:07.710 And if someone hacks into the server 00:10:07.710 --> 00:10:11.370 and finds this P point, and this r randomizer, well, 00:10:11.370 --> 00:10:13.050 that will allow them to link everything. 00:10:13.050 --> 00:10:14.970 Now they can see-- oh, we can also 00:10:14.970 --> 00:10:16.470 generate all these addresses. 00:10:16.470 --> 00:10:18.540 We can see that it's all the same person. 00:10:18.540 --> 00:10:20.790 But that doesn't let them steal any of the funds. 00:10:20.790 --> 00:10:22.890 So compromising the server with this, well, 00:10:22.890 --> 00:10:25.200 you lose the privacy, but you don't lose your money, 00:10:25.200 --> 00:10:28.420 so that's a pretty good trade. 00:10:28.420 --> 00:10:31.210 Other questions about BIP32? 00:10:31.210 --> 00:10:33.930 So that's one of the features for wallets. 00:10:33.930 --> 00:10:35.920 You've got to do this. 00:10:35.920 --> 00:10:38.540 The basic procedure-- you're going to request a payment. 00:10:38.540 --> 00:10:41.590 And you're going to say, hey, if you want this jacket, send 00:10:41.590 --> 00:10:45.580 one coin to address F8f12E. 00:10:45.580 --> 00:10:48.940 And it's sort of important to note that Bitcoin doesn't solve 00:10:48.940 --> 00:10:52.030 the problem of people paying money and not 00:10:52.030 --> 00:10:53.830 getting what they paid for. 00:10:53.830 --> 00:10:57.532 That's out of the scope of this, although there's 00:10:57.532 --> 00:10:58.990 a lot of people that say it should, 00:10:58.990 --> 00:11:01.270 but know it doesn't do fraud protection. 00:11:01.270 --> 00:11:02.770 It's like, hey, I gave you the coin, 00:11:02.770 --> 00:11:04.020 you didn't give me the jacket. 00:11:04.020 --> 00:11:05.500 Well, Bitcoin worked fine. 00:11:05.500 --> 00:11:06.880 Bitcoin made the coin move. 00:11:06.880 --> 00:11:08.770 That's Bitcoin's job. 00:11:08.770 --> 00:11:11.590 The fact that FedEx never delivered your jacket, 00:11:11.590 --> 00:11:14.590 well, that's FedEx or the retailer 00:11:14.590 --> 00:11:15.970 or all sorts of things like that. 00:11:18.038 --> 00:11:20.080 You know, I don't want to say it's not a problem. 00:11:20.080 --> 00:11:22.080 It certainly is, but it is seen as out of scope. 00:11:22.080 --> 00:11:23.997 It's, like, you know-- this is a money system. 00:11:23.997 --> 00:11:24.740 This is money. 00:11:24.740 --> 00:11:26.490 Your dollar bills don't ensure that you're 00:11:26.490 --> 00:11:27.990 getting what you paid for. 00:11:27.990 --> 00:11:30.180 That said, there's all sorts of things 00:11:30.180 --> 00:11:34.200 that do this kind of thing, and do try to ensure delivery 00:11:34.200 --> 00:11:35.670 versus payment-- 00:11:35.670 --> 00:11:38.460 atomic swaps, HTLCs that we'll talk about later, 00:11:38.460 --> 00:11:40.330 Zero-Knowledge Contingent Proof-- 00:11:40.330 --> 00:11:43.740 all these different things do sort of work on top of Bitcoin 00:11:43.740 --> 00:11:45.295 to try to help these kinds of things. 00:11:45.295 --> 00:11:46.920 In practice, though, if you're actually 00:11:46.920 --> 00:11:49.320 buying a physical jacket that someone's 00:11:49.320 --> 00:11:51.510 going to deliver to you, there's not really 00:11:51.510 --> 00:11:55.050 a good cryptographic proof of jacket delivery. 00:11:55.050 --> 00:12:00.520 So some reputation is involved. 00:12:00.520 --> 00:12:02.270 Then, from the merchant's perspective-- 00:12:02.270 --> 00:12:04.150 so, I sell jackets. 00:12:04.150 --> 00:12:06.520 I want to know if someone paid me. 00:12:06.520 --> 00:12:09.120 I have something on the website, put in your address, 00:12:09.120 --> 00:12:10.990 now pay this address. 00:12:10.990 --> 00:12:12.910 So you add all your pubkey hashes 00:12:12.910 --> 00:12:14.380 to a big list in your software. 00:12:14.380 --> 00:12:17.830 You say, OK, here's all the addresses I've created. 00:12:17.830 --> 00:12:20.380 They're all these 20-byte pubkey hashes. 00:12:20.380 --> 00:12:24.170 I put them in a map or some kind of array or some database, 00:12:24.170 --> 00:12:25.940 whatever. 00:12:25.940 --> 00:12:28.720 And from then on, every transaction I 00:12:28.720 --> 00:12:33.280 see on the network, I also look at the output scripts. 00:12:33.280 --> 00:12:36.460 So before, when I was verifying the blockchain, 00:12:36.460 --> 00:12:38.620 I actually never had to look at the output scripts 00:12:38.620 --> 00:12:42.820 until they got spent. 00:12:42.820 --> 00:12:44.712 So when I was downloading transactions, 00:12:44.712 --> 00:12:46.420 I would look at their signatures and look 00:12:46.420 --> 00:12:51.090 at the old UTXOs in the UTXO set and match them up and verify. 00:12:51.090 --> 00:12:53.980 But where the money got sent in these new transactions, 00:12:53.980 --> 00:12:55.457 I didn't really care. 00:12:55.457 --> 00:12:57.040 It could have been sending it to zero. 00:12:57.040 --> 00:12:59.373 It could have been sending it to some weird address that 00:12:59.373 --> 00:13:01.000 probably was wrong. 00:13:01.000 --> 00:13:03.790 There was no-- and I believe to this day, 00:13:03.790 --> 00:13:07.180 there's still no output validation 00:13:07.180 --> 00:13:10.120 that happens in Bitcoin as a consensus rule 00:13:10.120 --> 00:13:12.177 because it's not important. 00:13:12.177 --> 00:13:13.510 Where are you sending the money? 00:13:13.510 --> 00:13:15.310 Well, wherever you want. 00:13:15.310 --> 00:13:17.740 And are you able to spend it? 00:13:17.740 --> 00:13:18.983 We'll deal with that later. 00:13:18.983 --> 00:13:20.650 If you want to destroy your money, fine. 00:13:20.650 --> 00:13:22.300 I'm not going to look at the output. 00:13:22.300 --> 00:13:24.640 There's no invalid output. 00:13:24.640 --> 00:13:26.320 There can be an invalid input, which-- 00:13:26.320 --> 00:13:29.810 there can be an output which you can never actually use, 00:13:29.810 --> 00:13:31.900 but you're free to send to it. 00:13:31.900 --> 00:13:34.840 So that's sort of one of the rules in Bitcoin. 00:13:34.840 --> 00:13:38.320 However, when we're actually looking 00:13:38.320 --> 00:13:39.880 at our own money with the wallet, 00:13:39.880 --> 00:13:43.280 we do look at the output scripts, mainly to say, hey, 00:13:43.280 --> 00:13:44.890 is this ours? 00:13:44.890 --> 00:13:47.110 Are we getting paid with this transaction? 00:13:47.110 --> 00:13:48.740 So you look at every output script, 00:13:48.740 --> 00:13:51.670 and if you see one that matches, hey, we got paid. 00:13:51.670 --> 00:13:53.920 So you see a transaction, one of the outputs-- 00:13:53.920 --> 00:13:56.000 hey, look, that 20 bytes-- that's me. 00:13:56.000 --> 00:13:56.500 Cool. 00:13:56.500 --> 00:13:59.020 That's one of the addresses that I have, 00:13:59.020 --> 00:14:00.370 let me keep track of this. 00:14:00.370 --> 00:14:03.760 This is now money that's in my wallet. 00:14:03.760 --> 00:14:05.710 So you keep track of the received payments, 00:14:05.710 --> 00:14:08.770 you save them to disk in a similar way to your addresses. 00:14:08.770 --> 00:14:13.030 You use some kind of database or map or something, 00:14:13.030 --> 00:14:14.230 something efficient. 00:14:14.230 --> 00:14:16.600 And then you don't need to save too much information. 00:14:16.600 --> 00:14:19.450 You need to save the outpoint, the txid 00:14:19.450 --> 00:14:21.670 of the transaction, the index. 00:14:21.670 --> 00:14:24.520 You probably want to save how much, your amount, and which 00:14:24.520 --> 00:14:29.242 key it was, so the actual 20-byte pubkey hash. 00:14:29.242 --> 00:14:30.700 You can look through all your keys, 00:14:30.700 --> 00:14:33.340 but it might be nice-- oh, that's my 17th key 00:14:33.340 --> 00:14:36.280 that I've saved in my database or something. 00:14:36.280 --> 00:14:39.610 You may also want to save the height information, when 00:14:39.610 --> 00:14:40.950 it got confirmed. 00:14:40.950 --> 00:14:43.450 So we're not going to talk too much about unconfirmed versus 00:14:43.450 --> 00:14:46.690 confirmed today, but this can be an issue 00:14:46.690 --> 00:14:50.500 if you see a transaction on the network that's not yet 00:14:50.500 --> 00:14:52.410 in a block and it pays you. 00:14:52.410 --> 00:14:55.270 You're like, hey, I got money, but it's not confirmed yet, 00:14:55.270 --> 00:14:58.240 so have I really gotten money? 00:14:58.240 --> 00:15:01.540 I am able to use that output to spend somewhere else, 00:15:01.540 --> 00:15:05.470 but now I've got two change transactions, neither of which 00:15:05.470 --> 00:15:06.660 is confirmed. 00:15:06.660 --> 00:15:08.620 And now the second one can only be 00:15:08.620 --> 00:15:10.930 confirmed if the first one is, so that 00:15:10.930 --> 00:15:13.900 can get ugly kind of quick. 00:15:13.900 --> 00:15:15.670 For simplicity's sake, let's just 00:15:15.670 --> 00:15:18.490 say that you wait until it's in a block 00:15:18.490 --> 00:15:21.400 before your wallet recognizes it. 00:15:21.400 --> 00:15:25.912 Most wallets do not do that, but most wallets maybe should. 00:15:25.912 --> 00:15:27.370 There can be a lot of weird attacks 00:15:27.370 --> 00:15:29.748 where you say, oh, I got money, and then 00:15:29.748 --> 00:15:31.540 since it never really was confirmed at all, 00:15:31.540 --> 00:15:35.578 it's pretty easy for someone to double spend. 00:15:35.578 --> 00:15:37.120 The whole point of the Bitcoin system 00:15:37.120 --> 00:15:39.383 was you can't double spend because it's 00:15:39.383 --> 00:15:41.050 got all this proof of work on top of it. 00:15:41.050 --> 00:15:42.560 It's in a block. 00:15:42.560 --> 00:15:45.970 But if we show in the UI, hey you got a payment that has not 00:15:45.970 --> 00:15:48.340 yet gone into a block, well, there's 00:15:48.340 --> 00:15:51.100 no assurance that it won't be double spent yet, because it's 00:15:51.100 --> 00:15:52.900 not in the blockchain. 00:15:52.900 --> 00:15:55.840 But most wallets will show that and usually they'll 00:15:55.840 --> 00:15:58.540 make it in like red, or put a little exclamation point 00:15:58.540 --> 00:16:02.950 or something to try to indicate, hey, this is unconfirmed, 00:16:02.950 --> 00:16:05.390 but that doesn't always get across to people. 00:16:05.390 --> 00:16:07.840 So it may be safer to just not show it at all 00:16:07.840 --> 00:16:08.960 until it's in the block. 00:16:08.960 --> 00:16:12.640 OK, so you amass all these you UTXOs, 00:16:12.640 --> 00:16:16.210 you're running your node, you've got all these addresses you've 00:16:16.210 --> 00:16:18.610 given out to people, and then every transaction 00:16:18.610 --> 00:16:21.370 that comes in you look-- hey, do any of these pay me? 00:16:21.370 --> 00:16:23.720 And sometimes you'll find one that does, which is great. 00:16:23.720 --> 00:16:25.780 And then you save that to your disk and, great. 00:16:25.780 --> 00:16:28.490 Now, next, I want to spend them. 00:16:28.490 --> 00:16:34.190 OK, any questions about the getting money procedure? 00:16:34.190 --> 00:16:34.710 Yes. 00:16:34.710 --> 00:16:36.603 AUDIENCE: So, what's the height again? 00:16:36.603 --> 00:16:38.520 TADGE DRYJA: The height is what block it's in, 00:16:38.520 --> 00:16:41.790 so height zero is the first block, zero block, 00:16:41.790 --> 00:16:45.780 and we're now at height 500,000. 00:16:45.780 --> 00:16:48.390 Usually, in diagrams, it goes this way, 00:16:48.390 --> 00:16:54.170 but I guess it could go up in numbers, I don't know. 00:16:54.170 --> 00:16:55.950 Yeah, so next, you need to spend them. 00:16:55.950 --> 00:16:58.740 Spending makes sense, right? 00:16:58.740 --> 00:17:00.240 It's not too crazy. 00:17:00.240 --> 00:17:02.700 Let's say you want to send six coins to someone. 00:17:02.700 --> 00:17:05.250 So what you do is, you look through your set of UTXOs 00:17:05.250 --> 00:17:10.380 that are your UTXOs, and you try to find some such 00:17:10.380 --> 00:17:14.260 that the total number of coins is over six, 00:17:14.260 --> 00:17:17.619 and then you use them as inputs, and then you add your outputs. 00:17:17.619 --> 00:17:20.250 So, for example, I've got two UTXOs. 00:17:20.250 --> 00:17:23.657 These are much smaller numbers, but this one 00:17:23.657 --> 00:17:25.740 has five coins in it and this one has three coins. 00:17:25.740 --> 00:17:28.140 So I received, at two different times, 00:17:28.140 --> 00:17:30.040 once I got five coins for a fancy jacket, 00:17:30.040 --> 00:17:32.640 once I got three coins for a less fancy jacket. 00:17:32.640 --> 00:17:35.470 And now I want to buy something, and I want to send it to Bob, 00:17:35.470 --> 00:17:36.870 and I want to send six coins. 00:17:39.730 --> 00:17:42.070 Well, I've got eight coins in my inputs, 00:17:42.070 --> 00:17:44.320 so I'll send him six coins. 00:17:44.320 --> 00:17:46.900 There's two coins leftover. 00:17:46.900 --> 00:17:49.250 If I don't have this, it just goes to the miners, 00:17:49.250 --> 00:17:54.230 so I create my new output, which is my change output. 00:17:54.230 --> 00:17:56.720 And then I send the remainder, two coins here. 00:17:56.720 --> 00:17:59.240 Now, if it's actually these nice, round numbers, 00:17:59.240 --> 00:18:01.520 the fee would be zero and it would probably not 00:18:01.520 --> 00:18:03.650 get confirmed on the Bitcoin network. 00:18:03.650 --> 00:18:06.740 You do have to have a small fee right now. 00:18:06.740 --> 00:18:08.810 It's really small, like a couple of cents now. 00:18:08.810 --> 00:18:11.940 It was pretty high a few months ago. 00:18:11.940 --> 00:18:13.070 But this will work. 00:18:13.070 --> 00:18:14.040 This is the basic idea. 00:18:14.040 --> 00:18:17.870 So, you look through your UTXOs, find 00:18:17.870 --> 00:18:21.080 some, OK, output six, output two, sign them. 00:18:21.080 --> 00:18:25.490 Once you've built this, sign it all, broadcast to the network. 00:18:25.490 --> 00:18:26.720 Make sense? 00:18:26.720 --> 00:18:27.546 Yes. 00:18:27.546 --> 00:18:30.182 AUDIENCE: Is the change UTXO, like, your own? 00:18:30.182 --> 00:18:30.890 TADGE DRYJA: Yep. 00:18:30.890 --> 00:18:32.240 Yep. 00:18:32.240 --> 00:18:35.660 Generally, what you'll do is, you'll make a new private key, 00:18:35.660 --> 00:18:38.330 calculate the public key, hash it, make this address, 00:18:38.330 --> 00:18:41.180 and then add it in here, all automatically. 00:18:41.180 --> 00:18:43.160 You can, and some software does, just 00:18:43.160 --> 00:18:45.380 only use one key and one address, 00:18:45.380 --> 00:18:48.680 and so it'll be pretty clear because the keys 00:18:48.680 --> 00:18:50.870 for this signature will be the same as this key 00:18:50.870 --> 00:18:53.570 that it's sending to, and so then it's really clear. 00:18:53.570 --> 00:18:56.060 Even without doing that, it's usually pretty clear 00:18:56.060 --> 00:19:01.030 and people can sort of guess, well, either Alice 00:19:01.030 --> 00:19:04.280 is sending six coins back to herself and two coins to Bob, 00:19:04.280 --> 00:19:08.090 or she's sending six coins to Bob and two back to herself. 00:19:08.090 --> 00:19:10.108 Or maybe six coins to one person, two coins 00:19:10.108 --> 00:19:11.150 to someone else entirely. 00:19:11.150 --> 00:19:13.010 That's pretty unlikely. 00:19:13.010 --> 00:19:16.550 Usually, metrics will try to analyze the transaction graph, 00:19:16.550 --> 00:19:19.250 and say, oh, the smaller outputs are usually the payments 00:19:19.250 --> 00:19:21.620 and the larger ones are the change, 00:19:21.620 --> 00:19:24.930 but you don't know if the addresses are all different. 00:19:24.930 --> 00:19:25.592 Yes? 00:19:25.592 --> 00:19:27.927 AUDIENCE: How does the fee get paid again? 00:19:27.927 --> 00:19:29.510 TADGE DRYJA: The fee is the difference 00:19:29.510 --> 00:19:32.935 between the inputs amounts and the output amounts. 00:19:32.935 --> 00:19:34.310 So, in this case, the fee is zero 00:19:34.310 --> 00:19:37.520 because I got 5, 3, 8, and then 8 here. 00:19:37.520 --> 00:19:42.590 So, really, what you do in real life is, you'd make this 1.999 00:19:42.590 --> 00:19:46.820 and then the fee would be that 0.001, or whatever 00:19:46.820 --> 00:19:50.210 that the miner gets in the coinbase transaction. 00:19:50.210 --> 00:19:53.010 That's another way to try to identify change outputs. 00:19:53.010 --> 00:19:57.540 If you actually had 5, 3, 6, and 1.999, 00:19:57.540 --> 00:20:00.380 I bet the 1.999 is going back to yourself. 00:20:00.380 --> 00:20:04.820 Nice, even, round numbers seem like real payments. 00:20:04.820 --> 00:20:08.308 And then if you've got one bunch of nines at the end, 00:20:08.308 --> 00:20:10.100 oh, that was probably just reduced a little 00:20:10.100 --> 00:20:11.750 to make the fee. 00:20:11.750 --> 00:20:13.010 But these are all guesses. 00:20:13.010 --> 00:20:16.015 If you're a third party observer looking at a transaction, 00:20:16.015 --> 00:20:16.640 you don't know. 00:20:16.640 --> 00:20:18.650 This could be two different people, 00:20:18.650 --> 00:20:20.990 or this could be an exchange and it's hard to tell, 00:20:20.990 --> 00:20:22.940 but you can get some pretty good guesses. 00:20:22.940 --> 00:20:23.440 Yes? 00:20:23.440 --> 00:20:27.090 AUDIENCE: In terms of fees, so if you have no fee 00:20:27.090 --> 00:20:29.495 or you had a really small fee and buyers 00:20:29.495 --> 00:20:32.210 are requiring something higher, that just 00:20:32.210 --> 00:20:33.590 sits on everyone's computer. 00:20:33.590 --> 00:20:35.900 They still share with each other or do they sit there 00:20:35.900 --> 00:20:37.220 until maybe there's a block? 00:20:37.220 --> 00:20:39.012 TADGE DRYJA: There are multiple thresholds. 00:20:39.012 --> 00:20:41.450 So, there's the relay threshold, which right now I 00:20:41.450 --> 00:20:43.710 believe Bitcoin is one Satoshi per byte. 00:20:43.710 --> 00:20:46.438 So, I think we said Satoshis are the smallest 00:20:46.438 --> 00:20:47.480 unit possible in Bitcoin. 00:20:47.480 --> 00:20:52.260 So one coin is actually 100 million Satoshis-- 00:20:52.260 --> 00:20:55.580 and there's no decimal places, that's just a UI thing. 00:20:55.580 --> 00:20:59.180 So right now, the minimum relay fee, by default, 00:20:59.180 --> 00:21:00.320 is 1 Satoshi per byte. 00:21:00.320 --> 00:21:05.240 So for a 250-byte transaction, you need 250 Satoshis, 00:21:05.240 --> 00:21:09.080 which is some fraction of a cent-- 00:21:09.080 --> 00:21:11.970 maybe more than a cent now, I'm not sure. 00:21:11.970 --> 00:21:15.290 And then the idea is if you see a transaction below that, 00:21:15.290 --> 00:21:17.200 you won't even relay it to anyone else. 00:21:17.200 --> 00:21:19.400 You'll be like, this is so cheap that I'm not 00:21:19.400 --> 00:21:21.260 going to bother sending it to everyone else. 00:21:21.260 --> 00:21:22.970 I'm just going to ignore it. 00:21:22.970 --> 00:21:25.580 But above that 1 Satoshi threshold, 00:21:25.580 --> 00:21:29.090 you will accept it, verify the signatures, 00:21:29.090 --> 00:21:32.300 and then pass it on to everyone else you're connected to. 00:21:32.300 --> 00:21:34.760 But that doesn't necessarily mean it will get into a block 00:21:34.760 --> 00:21:36.140 anytime soon. 00:21:36.140 --> 00:21:38.540 It's actually been really interesting the last, 00:21:38.540 --> 00:21:43.070 I'd say six months, where the fees went up enormously 00:21:43.070 --> 00:21:48.290 and you see this really crazy price inelasticity, 00:21:48.290 --> 00:21:51.560 where people who were paying one cent then 00:21:51.560 --> 00:21:55.165 started paying 10 cents, a dollar, $10, $20. 00:21:58.310 --> 00:22:01.202 And what's also sort of optimistic-- 00:22:01.202 --> 00:22:02.910 that made me feel good-- it's like, well, 00:22:02.910 --> 00:22:05.790 clearly they were getting 20 bucks worth of utility 00:22:05.790 --> 00:22:08.202 out of this because they're now perfectly 00:22:08.202 --> 00:22:10.410 willing to pay 20 bucks and they were paying one cent 00:22:10.410 --> 00:22:11.545 a few weeks ago. 00:22:11.545 --> 00:22:12.420 That's kind of weird. 00:22:12.420 --> 00:22:15.890 And then it's now gone back down to, like, one cent. 00:22:15.890 --> 00:22:19.140 But it's very inelastic in that there's 00:22:19.140 --> 00:22:21.600 a fixed size for how many transactions 00:22:21.600 --> 00:22:24.117 you can have per minute or per hour 00:22:24.117 --> 00:22:25.950 and when people really want to get in there, 00:22:25.950 --> 00:22:29.310 they have to just bid everyone else out. 00:22:29.310 --> 00:22:32.640 So we'll talk about the fee markets in a few weeks, 00:22:32.640 --> 00:22:34.050 and replace by fee. 00:22:34.050 --> 00:22:36.147 That's sort of a new evolving thing, 00:22:36.147 --> 00:22:38.730 but it's been really interesting to see in the last few months 00:22:38.730 --> 00:22:39.438 how it's changed. 00:22:39.438 --> 00:22:40.510 Yeah. 00:22:40.510 --> 00:22:42.150 AUDIENCE: At $10,000 per Bitcoin, 00:22:42.150 --> 00:22:43.822 a Satoshi is 0.01 cent, a hundredth-- 00:22:43.822 --> 00:22:45.030 TADGE DRYJA: Tenth of a cent. 00:22:45.030 --> 00:22:45.780 AUDIENCE: Hundredth of a cent. 00:22:45.780 --> 00:22:46.880 TADGE DRYJA: Hundredth of a cent. 00:22:46.880 --> 00:22:47.380 OK. 00:22:47.380 --> 00:22:50.280 So, the minimum relay fee would be more like 2 and 1/2 cents. 00:22:50.280 --> 00:22:52.470 So that's-- you know, it's not zero. 00:22:52.470 --> 00:22:55.110 That's still-- a fee, right? 00:22:55.110 --> 00:22:58.710 And you get enough of those and you start making money. 00:22:58.710 --> 00:23:00.690 But it's also interesting recently, it 00:23:00.690 --> 00:23:04.050 used to be that the initial new coins coming out to miners 00:23:04.050 --> 00:23:06.990 was just overwhelmingly the majority of what 00:23:06.990 --> 00:23:12.000 they had earned and people would ignore fees as a miner. 00:23:12.000 --> 00:23:14.250 But then, in December, January, I 00:23:14.250 --> 00:23:18.660 believe miners made more money in fees than in new coins being 00:23:18.660 --> 00:23:20.340 generated. 00:23:20.340 --> 00:23:21.840 I'm not sure if that averages out. 00:23:21.840 --> 00:23:23.070 There were definitely weeks where 00:23:23.070 --> 00:23:24.570 that was the case, or at least days, 00:23:24.570 --> 00:23:26.700 I'm not sure if it's average or the whole month. 00:23:26.700 --> 00:23:34.540 But if you-- total aside, sorry, but this guy's site 00:23:34.540 --> 00:23:40.220 is a cool way to look at the fees. 00:23:40.220 --> 00:23:42.130 So you can see here's-- 00:23:42.130 --> 00:23:44.730 he sort of organizes transactions by fee rate. 00:23:44.730 --> 00:23:46.640 It's too low-res to really get everything, 00:23:46.640 --> 00:23:48.400 but if you just search for Johoe-- 00:23:48.400 --> 00:23:53.763 J-O-H-O-E-- he works on Bitcoin stuff and he made this cool 00:23:53.763 --> 00:23:55.930 site, which is open source and you could even run it 00:23:55.930 --> 00:23:58.840 on your own node if you wanted to, and generate the same cool 00:23:58.840 --> 00:24:03.180 JavaScript color-y things and you can see the fee market. 00:24:03.180 --> 00:24:07.210 And I'm not an economist, but it is really interesting 00:24:07.210 --> 00:24:13.830 seeing there's clearly market failures occurring here 00:24:13.830 --> 00:24:14.430 in that-- 00:24:17.040 --> 00:24:21.580 so, you can pay the green-- 00:24:21.580 --> 00:24:23.500 you can pay 10 Satoshis per byte, 00:24:23.500 --> 00:24:26.260 and you'll get confirmed in 10 minutes. 00:24:26.260 --> 00:24:28.360 Or you can pay 1,000 Satoshis per byte, 00:24:28.360 --> 00:24:30.460 and you will also get confirmed in 10 minutes. 00:24:30.460 --> 00:24:35.247 And most people are paying 10, but someone's paying 1,000. 00:24:35.247 --> 00:24:36.830 You know, it's got the whole spectrum. 00:24:36.830 --> 00:24:39.010 You've got multiple orders of magnitude 00:24:39.010 --> 00:24:41.710 of people paying for the exact same thing, 00:24:41.710 --> 00:24:43.410 and they can all see each other. 00:24:43.410 --> 00:24:45.190 It's just a weird sort of-- 00:24:45.190 --> 00:24:46.600 seems broken. 00:24:46.600 --> 00:24:49.580 And part of it is just the cost to write the software. 00:24:49.580 --> 00:24:52.960 If you're an exchange and everyone's 00:24:52.960 --> 00:24:55.010 sending you support requests, and this happens-- 00:24:55.010 --> 00:24:58.990 OK, I don't know just, pay a 500 Satoshi per byte fee-- 00:24:58.990 --> 00:25:00.435 and then it seems to work. 00:25:00.435 --> 00:25:02.810 And, yeah, we're losing a couple of thousand bucks a day, 00:25:02.810 --> 00:25:06.460 but let's just not deal with that. 00:25:06.460 --> 00:25:08.170 And I think that's part of it, is 00:25:08.170 --> 00:25:09.850 that there's a lot of software out there 00:25:09.850 --> 00:25:13.060 that just has a fixed fee rate, or even a fixed fee, 00:25:13.060 --> 00:25:15.795 regardless of how big the transaction is. 00:25:15.795 --> 00:25:17.920 There's a lot of software that, years ago, wouldn't 00:25:17.920 --> 00:25:20.253 have to deal with this issue because there wasn't really 00:25:20.253 --> 00:25:22.940 competition to get into a block, and now they do. 00:25:22.940 --> 00:25:26.990 So it's kind of cool to look at and see the history of it. 00:25:26.990 --> 00:25:31.600 But I'll get into depth of fees and stuff in, I think, 00:25:31.600 --> 00:25:33.860 two weeks or something. 00:25:33.860 --> 00:25:35.800 OK, any questions about-- 00:25:35.800 --> 00:25:36.300 yeah. 00:25:36.300 --> 00:25:39.290 AUDIENCE: What was that website again? 00:25:39.290 --> 00:25:41.470 TADGE DRYJA: Well, it's in some Dutch, or something. 00:25:41.470 --> 00:25:47.580 Just search J-O-H-O-E, Johoe. 00:25:47.580 --> 00:25:48.240 He's the guy. 00:25:48.240 --> 00:25:50.920 It's the first thing on Google. 00:25:50.920 --> 00:25:54.543 J-O-H-O-E is his Dutch nickname, or something, I don't know. 00:25:54.543 --> 00:25:55.210 He's a cool guy. 00:25:55.210 --> 00:25:57.680 He actually-- I think I talked-- did 00:25:57.680 --> 00:25:59.190 I talk-- there was some randomness 00:25:59.190 --> 00:26:01.020 problems at some site. 00:26:01.020 --> 00:26:04.050 He stole a bunch of Bitcoins and gave them back to their owners. 00:26:04.050 --> 00:26:09.360 He found there was a K reuse, like nonce reuse 00:26:09.360 --> 00:26:11.160 vulnerability in some wallets. 00:26:11.160 --> 00:26:13.410 And so he's like, hey, look, there's like 100 Bitcoins 00:26:13.410 --> 00:26:16.200 that I can just take because I can calculate the private key. 00:26:16.200 --> 00:26:18.720 And he took them, and he was like, I 00:26:18.720 --> 00:26:21.150 think I know who these are and can you prove it, 00:26:21.150 --> 00:26:22.537 and then I'll give them back? 00:26:22.537 --> 00:26:24.870 So he sort of grabbed-- you know, finding a wallet with, 00:26:24.870 --> 00:26:27.990 like, thousands of dollars coming out of it on the street, 00:26:27.990 --> 00:26:31.645 he grabbed them all and tried to get them back to people. 00:26:31.645 --> 00:26:32.520 I don't know the guy. 00:26:32.520 --> 00:26:34.890 I've never met him but seems like a nice guy. 00:26:34.890 --> 00:26:35.616 Anyway. 00:26:35.616 --> 00:26:37.800 [LAUGHTER] 00:26:37.800 --> 00:26:38.888 That's how Bitcoin works. 00:26:38.888 --> 00:26:40.930 You don't meet anyone, but you see these people-- 00:26:40.930 --> 00:26:41.722 oh he's a nice guy. 00:26:41.722 --> 00:26:42.420 Oh, he's a jerk. 00:26:46.198 --> 00:26:48.240 The weekend was kind of interesting over Twitter, 00:26:48.240 --> 00:26:49.680 but anyway-- 00:26:49.680 --> 00:26:50.670 AUDIENCE: I saw that. 00:26:50.670 --> 00:26:51.790 TADGE DRYJA: Yeah. 00:26:51.790 --> 00:26:54.220 OK, so you build these transactions. 00:26:54.220 --> 00:26:55.670 There are issues here. 00:26:55.670 --> 00:26:58.140 Two inputs, two outputs-- that's going to be kind of big. 00:26:58.140 --> 00:27:00.750 You're going to have two different signatures. 00:27:00.750 --> 00:27:03.570 It's going to be a little bit higher fee. 00:27:03.570 --> 00:27:05.440 What would work better than this? 00:27:05.440 --> 00:27:06.690 It's kind of a silly question. 00:27:06.690 --> 00:27:08.160 What would work better than having 00:27:08.160 --> 00:27:10.285 two inputs and two outputs to make this transaction 00:27:10.285 --> 00:27:11.420 to pay someone six coins? 00:27:16.570 --> 00:27:17.070 Yeah? 00:27:17.070 --> 00:27:20.465 AUDIENCE: Maybe if you wanted to have an anonymous transaction 00:27:20.465 --> 00:27:24.830 doing something like multiple transactions in smaller sizes? 00:27:24.830 --> 00:27:25.580 TADGE DRYJA: Sure. 00:27:25.580 --> 00:27:29.720 Yeah, that's-- you could send-- so, that's actually two slides 00:27:29.720 --> 00:27:30.710 from now. 00:27:30.710 --> 00:27:32.630 The next slide was just, well, what 00:27:32.630 --> 00:27:35.150 if you had a UTXO that was exactly the right size? 00:27:35.150 --> 00:27:35.930 Then it's easy. 00:27:35.930 --> 00:27:38.050 You just send them the six coins. 00:27:38.050 --> 00:27:41.693 If you have the exact right size UTXO in your wallet, great. 00:27:41.693 --> 00:27:42.610 You just send it over. 00:27:42.610 --> 00:27:46.660 It's like if you go to a shop and they're like, OK, 00:27:46.660 --> 00:27:47.757 that's $10 for lunch. 00:27:47.757 --> 00:27:49.340 You're like, great, I have a $10 bill. 00:27:49.340 --> 00:27:50.363 Here it is. 00:27:50.363 --> 00:27:52.780 We don't need to deal with pennies and quarters and stuff. 00:27:52.780 --> 00:27:54.070 It's annoying. 00:27:54.070 --> 00:27:55.240 So sometimes this happens. 00:27:55.240 --> 00:27:56.380 It's great. 00:27:56.380 --> 00:27:57.490 Generally, it won't. 00:27:57.490 --> 00:28:00.190 Generally, you will have change and multiple inputs and outputs 00:28:00.190 --> 00:28:02.120 and it's kind of annoying. 00:28:02.120 --> 00:28:03.820 So coin selection is a tricky problem. 00:28:03.820 --> 00:28:08.440 For CSE terms it's NP-hard, actually, 00:28:08.440 --> 00:28:09.970 but there's heuristics that work OK. 00:28:09.970 --> 00:28:12.010 If you have a ton of UTXOs and you 00:28:12.010 --> 00:28:14.285 have to send these payments, you can actually, 00:28:14.285 --> 00:28:16.660 in a reasonable amount of time, calculate the optimal way 00:28:16.660 --> 00:28:17.380 to do it. 00:28:17.380 --> 00:28:21.010 But there's some heuristics at work, 00:28:21.010 --> 00:28:23.470 and the question is what are we optimizing for? 00:28:23.470 --> 00:28:25.720 Generally, you want to optimize-- 00:28:25.720 --> 00:28:29.302 minimize the number of inputs used. 00:28:29.302 --> 00:28:30.760 The inputs are much bigger, they're 00:28:30.760 --> 00:28:32.470 going to be like a hundred something bytes, 00:28:32.470 --> 00:28:33.845 and the outputs are pretty small, 00:28:33.845 --> 00:28:35.320 they're like 20-30 bytes. 00:28:35.320 --> 00:28:37.870 So if you want to minimize size of your transaction, 00:28:37.870 --> 00:28:40.540 minimize the number of inputs, which is easy. 00:28:40.540 --> 00:28:45.580 You just pick your biggest UTXO and spend that one. 00:28:45.580 --> 00:28:46.255 Yes? 00:28:46.255 --> 00:28:47.650 AUDIENCE: Isn't it like the knapsack problem, though? 00:28:47.650 --> 00:28:49.583 TADGE DRYJA: Yeah, it basically is, yeah. 00:28:49.583 --> 00:28:52.390 Well, because it's multi-iteration, 00:28:52.390 --> 00:28:55.390 if you're just trying to optimize your transaction right 00:28:55.390 --> 00:28:57.960 now, you just use your biggest UTXO. 00:28:57.960 --> 00:29:02.200 So for example, it's sort of the analogy of you're 00:29:02.200 --> 00:29:06.360 at a checkout counter and someone says, 00:29:06.360 --> 00:29:09.790 OK, that's $12.93. 00:29:09.790 --> 00:29:11.770 If you want to minimize the number of bills 00:29:11.770 --> 00:29:14.110 you're handing to the cashier, you just 00:29:14.110 --> 00:29:15.870 take the 100 out of your wallet. 00:29:15.870 --> 00:29:17.680 That'll always work. 00:29:17.680 --> 00:29:20.800 You just say, I take my biggest bill, hand it to you, OK, 00:29:20.800 --> 00:29:23.950 I'm minimizing the amount of bills I'm handing you 00:29:23.950 --> 00:29:25.790 in this one transaction. 00:29:25.790 --> 00:29:28.480 However, that could result in a whole bunch of bills coming 00:29:28.480 --> 00:29:30.790 back, a bunch of weird change. 00:29:30.790 --> 00:29:33.220 And then also, long-term that doesn't work. 00:29:33.220 --> 00:29:35.303 If your strategy is always just hand over the 100, 00:29:35.303 --> 00:29:37.095 or you go through your wallet and just hand 00:29:37.095 --> 00:29:38.980 over the biggest bill you have every time, 00:29:38.980 --> 00:29:41.890 no matter what they ask, that's super suboptimal 00:29:41.890 --> 00:29:45.640 because if they say $12.93, and you have a 20 and 100 00:29:45.640 --> 00:29:49.830 and you hand over the 100 like, why did you do that? 00:29:49.830 --> 00:29:51.890 And then you're going to have four 20s. 00:29:51.890 --> 00:29:53.710 So, it's very similar to that, except now 00:29:53.710 --> 00:29:59.940 that the change and bills have arbitrary denominations. 00:29:59.940 --> 00:30:01.310 There isn't a fixed-- 00:30:01.310 --> 00:30:04.210 you have 100s, 50s, 20s, 10s, 5s. 00:30:04.210 --> 00:30:06.990 Now it can be any number. 00:30:06.990 --> 00:30:09.252 So if you're just looking at one time, 00:30:09.252 --> 00:30:10.710 just pick your biggest UTXO, you'll 00:30:10.710 --> 00:30:12.830 have the smallest transaction. 00:30:12.830 --> 00:30:14.820 But you want to minimize next time, 00:30:14.820 --> 00:30:17.210 so you ideally can eliminate the change output 00:30:17.210 --> 00:30:19.610 and get you a perfect target. 00:30:19.610 --> 00:30:21.170 It's actually really complicated. 00:30:21.170 --> 00:30:23.000 There's really cool research on how do we 00:30:23.000 --> 00:30:26.090 select coins for long term? 00:30:26.090 --> 00:30:26.930 Yeah? 00:30:26.930 --> 00:30:28.930 AUDIENCE: So why don't you just take the biggest 00:30:28.930 --> 00:30:30.150 UTXO that's larger-- 00:30:30.150 --> 00:30:33.170 or, the smallest UTXO that's larger than your output size? 00:30:33.170 --> 00:30:35.330 TADGE DRYJA: Yep, that can work. 00:30:35.330 --> 00:30:37.940 That's not-- that's a good heuristic. 00:30:37.940 --> 00:30:41.780 That's a good-- pretty easy to code, sort your UTXOs, 00:30:41.780 --> 00:30:43.160 go here, use that one. 00:30:46.520 --> 00:30:48.440 It's not really optimal because then-- 00:30:48.440 --> 00:30:52.380 it's a lot better than taking big ones-- 00:30:52.380 --> 00:30:53.720 what do I have in my wallet? 00:30:53.720 --> 00:30:56.720 So I've actually written an SPV wallet and all this stuff 00:30:56.720 --> 00:30:59.660 just from scratch, and it's kind of interesting. 00:30:59.660 --> 00:31:03.050 You learn a lot about how it works. 00:31:03.050 --> 00:31:05.223 I target two inputs instead of one, 00:31:05.223 --> 00:31:07.640 because then eventually-- if you do that, what will happen 00:31:07.640 --> 00:31:10.830 is you're going to be using one input, which is great, 00:31:10.830 --> 00:31:15.255 and then you're going to run out of big inputs. 00:31:15.255 --> 00:31:17.630 And then you're going to always have to use two or three, 00:31:17.630 --> 00:31:20.180 and you can get a lot of dust. 00:31:20.180 --> 00:31:25.180 Dust is like the colloquial term for really small UTXOs, where 00:31:25.180 --> 00:31:27.990 you've got a bunch of pennies. 00:31:27.990 --> 00:31:29.940 So that's one issue. 00:31:29.940 --> 00:31:33.500 Another issue is privacy concerns. 00:31:33.500 --> 00:31:36.290 When you use two UTXOs or have two inputs 00:31:36.290 --> 00:31:40.490 in the same transaction, that's linking those transactions, 00:31:40.490 --> 00:31:43.670 linking those two UTXOs. 00:31:43.670 --> 00:31:44.870 It's not definitive. 00:31:44.870 --> 00:31:50.170 You can interactively create transactions with other people. 00:31:50.170 --> 00:31:51.700 In practice, that doesn't happen. 00:31:51.700 --> 00:31:54.250 You could say, hey, I want to pay Alice five coins, 00:31:54.250 --> 00:31:56.230 and you want to pay Bob six coins, 00:31:56.230 --> 00:31:58.590 and let's put my two UTXOs and your two UTXOs 00:31:58.590 --> 00:32:01.090 and we'll pay these two people, and we'll put our own change 00:32:01.090 --> 00:32:04.420 outputs, and we'll sort of mix this transaction together 00:32:04.420 --> 00:32:05.650 and we'll all sign it. 00:32:05.650 --> 00:32:08.620 And you can do that securely since you only 00:32:08.620 --> 00:32:10.250 sign when it all looks right to you, 00:32:10.250 --> 00:32:12.190 and everyone only signs when it's done. 00:32:12.190 --> 00:32:14.890 But the coordination problem is pretty severe. 00:32:14.890 --> 00:32:20.230 You have to find other people who want to make transactions 00:32:20.230 --> 00:32:21.957 at the same time that you do. 00:32:21.957 --> 00:32:22.540 It's annoying. 00:32:22.540 --> 00:32:25.270 So, in practice, since you're just using your wallet, 00:32:25.270 --> 00:32:27.710 if you see a transaction with multiple inputs, 00:32:27.710 --> 00:32:29.350 you can you can surmise, OK, those 00:32:29.350 --> 00:32:32.340 are the same person or the same company. 00:32:32.340 --> 00:32:35.980 And if you want privacy, if you want maximum anonymity 00:32:35.980 --> 00:32:39.940 what kind of coin selection or payment strategy would you use? 00:32:39.940 --> 00:32:42.190 AUDIENCE: Would you make just a bunch of transactions? 00:32:42.190 --> 00:32:42.940 TADGE DRYJA: Yeah. 00:32:42.940 --> 00:32:45.640 If someone says, hey, pay me six coins, 00:32:45.640 --> 00:32:48.070 well I have these three inputs, and I'm 00:32:48.070 --> 00:32:51.040 paying you two coins here and one coin here, 00:32:51.040 --> 00:32:52.510 and three coins here. 00:32:52.510 --> 00:32:55.360 And I paid you six coins but in three completely separate 00:32:55.360 --> 00:32:57.630 transactions. 00:32:57.630 --> 00:33:01.560 That no one does either because it's annoying. 00:33:01.560 --> 00:33:02.070 You could. 00:33:02.070 --> 00:33:05.040 It would be the most anonymous, but even then, 00:33:05.040 --> 00:33:07.230 what if they all happened at the same time, 00:33:07.230 --> 00:33:08.610 and you see they all get in the same block? 00:33:08.610 --> 00:33:09.985 And you're like, OK, well they're 00:33:09.985 --> 00:33:12.390 not linked nearly as closely, but I 00:33:12.390 --> 00:33:14.640 am seeing that these three transactions happened 00:33:14.640 --> 00:33:18.800 temporally similar times. 00:33:18.800 --> 00:33:22.310 So there's all sorts of things to try to optimize for. 00:33:22.310 --> 00:33:23.910 OK, any other questions about-- yeah? 00:33:23.910 --> 00:33:26.410 AUDIENCE: So does this mean that every time people are going 00:33:26.410 --> 00:33:28.960 to have a smaller and smaller split of a Bitcoin 00:33:28.960 --> 00:33:29.960 in their wallets? 00:33:29.960 --> 00:33:32.210 They're just going to have smaller and smaller amounts 00:33:32.210 --> 00:33:34.925 because you're going to-- if you have a $100 bill 00:33:34.925 --> 00:33:36.800 and then you're paying $20, then you're going 00:33:36.800 --> 00:33:39.160 to get four other $20 bills. 00:33:39.160 --> 00:33:39.910 TADGE DRYJA: Yeah. 00:33:39.910 --> 00:33:42.160 AUDIENCE: Eventually you're just going to have smaller 00:33:42.160 --> 00:33:44.350 and smaller-- is that a fair implication, or-- 00:33:44.350 --> 00:33:46.780 TADGE DRYJA: OK, short-term, yes. 00:33:46.780 --> 00:33:50.410 If you start out with a bunch of coins then start using it, yes. 00:33:50.410 --> 00:33:53.950 But it does reach equilibrium in that 00:33:53.950 --> 00:33:56.650 let's say you've got all these little tiny outputs-- 00:33:56.650 --> 00:33:59.590 you've got all these $1 bills-- 00:33:59.590 --> 00:34:03.880 but then you need to buy something that is 20 bucks. 00:34:03.880 --> 00:34:07.510 You have 20 inputs and one output. 00:34:07.510 --> 00:34:12.880 And whoever you're sending to now gets that one big output. 00:34:12.880 --> 00:34:17.710 And so, yeah, if you graph that over time, 00:34:17.710 --> 00:34:19.210 initially everyone was getting-- 00:34:19.210 --> 00:34:21.190 all their outputs were 50 coins each 00:34:21.190 --> 00:34:22.880 because that's how you mined them. 00:34:22.880 --> 00:34:25.750 And now they're getting smaller, but there 00:34:25.750 --> 00:34:30.427 is sort of an equilibrium after you've used it for a while. 00:34:30.427 --> 00:34:32.469 Any other questions about sort of coin selection, 00:34:32.469 --> 00:34:34.810 UTXO selection? 00:34:34.810 --> 00:34:35.578 Yes. 00:34:35.578 --> 00:34:37.835 AUDIENCE: According to a news report, 00:34:37.835 --> 00:34:39.460 I guess if you [INAUDIBLE] transaction, 00:34:39.460 --> 00:34:43.560 you also have [INAUDIBLE] transactions. 00:34:43.560 --> 00:34:44.560 TADGE DRYJA: Yeah, yeah. 00:34:44.560 --> 00:34:46.900 So that's costly. 00:34:46.900 --> 00:34:50.260 That's another reason probably people don't do this. 00:34:50.260 --> 00:34:53.380 I think the biggest reason is it's just annoying to code, 00:34:53.380 --> 00:34:55.960 and you can have failures where like-- 00:34:55.960 --> 00:34:57.010 here, give me six coins. 00:34:57.010 --> 00:34:59.190 OK, I'll give you 3, 2, and 1. 00:34:59.190 --> 00:35:01.090 Oh, the 3 didn't work, but the 2 and 1 did. 00:35:01.090 --> 00:35:02.360 Well, now what do we do? 00:35:02.360 --> 00:35:03.730 You paid me half of it. 00:35:03.730 --> 00:35:07.510 It's nice to have all or nothing payments. 00:35:07.510 --> 00:35:09.523 And also we have to send different addresses. 00:35:09.523 --> 00:35:10.690 There's all sorts of things. 00:35:10.690 --> 00:35:13.608 Also, it will be higher fees. 00:35:13.608 --> 00:35:15.400 In practice, it's actually not much higher. 00:35:19.220 --> 00:35:23.320 Let's say having three one input, one output transactions 00:35:23.320 --> 00:35:28.330 versus one three input, three output transaction-- 00:35:28.330 --> 00:35:30.310 you don't save too much space. 00:35:30.310 --> 00:35:33.160 Most of the space is taken by the inputs. 00:35:33.160 --> 00:35:34.630 And the overhead for a transaction 00:35:34.630 --> 00:35:37.780 is only 10 or 20 bytes or something, 00:35:37.780 --> 00:35:41.710 so it is not a huge difference. 00:35:41.710 --> 00:35:43.990 The main difference is that you're never 00:35:43.990 --> 00:35:45.865 coalescing into larger output sizes, 00:35:45.865 --> 00:35:48.115 so you're going to always have to sign since you going 00:35:48.115 --> 00:35:50.770 to have more inputs overall. 00:35:50.770 --> 00:35:52.990 This is a really, kind of, cool problem. 00:35:52.990 --> 00:35:55.270 There's a lot of computer science-y stuff 00:35:55.270 --> 00:35:59.500 but a lot of heuristics and how people use it. 00:35:59.500 --> 00:36:02.650 Also, the fact that fees are variable over time 00:36:02.650 --> 00:36:05.230 means you might want different strategies when fees are 00:36:05.230 --> 00:36:06.940 low versus when fees are high. 00:36:06.940 --> 00:36:09.910 So when fees are low now, I should make-- 00:36:09.910 --> 00:36:12.550 or maybe I just make a transaction to myself 00:36:12.550 --> 00:36:18.190 where I condense all my little $2 outputs into one big $1,000 00:36:18.190 --> 00:36:21.220 output so that when, later on, if fees are higher, 00:36:21.220 --> 00:36:24.860 I want to spend my money, I can do so more efficiently. 00:36:24.860 --> 00:36:28.210 And there is evidence of this with exchanges and stuff 00:36:28.210 --> 00:36:30.850 where a lot of times fees will be lower on the weekends 00:36:30.850 --> 00:36:33.610 because people aren't buying and spending Bitcoin as much, 00:36:33.610 --> 00:36:34.870 I guess. 00:36:34.870 --> 00:36:37.510 And so certain companies would say, OK, over the weekends 00:36:37.510 --> 00:36:42.730 we're going to sort of condense all our UTXOs and combine them 00:36:42.730 --> 00:36:46.075 and then we can make smaller transactions during the week. 00:36:46.075 --> 00:36:47.950 So there's all sorts of cool strategies here. 00:36:47.950 --> 00:36:49.940 It's an interesting topic. 00:36:49.940 --> 00:36:54.250 I haven't gone super in-depth, but the guys that chain code 00:36:54.250 --> 00:36:54.920 work on it. 00:36:54.920 --> 00:36:57.570 There's a lot of discussion about it, so it's kind of cool. 00:36:57.570 --> 00:37:00.410 OK, I'm a little bit behind. 00:37:00.410 --> 00:37:03.130 OK, next we'll talk about losing money, 00:37:03.130 --> 00:37:05.470 and that's another really important part 00:37:05.470 --> 00:37:06.940 of detecting the blockchain. 00:37:06.940 --> 00:37:11.440 It's hard to do, but you have to detect when you've lost money. 00:37:11.440 --> 00:37:13.300 And it's tricky because just because you 00:37:13.300 --> 00:37:17.170 signed the transaction doesn't really mean your money is gone. 00:37:17.170 --> 00:37:21.850 You can't just unilaterally say, OK, well, I'm making this. 00:37:21.850 --> 00:37:22.870 I signed it. 00:37:22.870 --> 00:37:25.060 There, my money is gone from my wallet. 00:37:25.060 --> 00:37:26.860 Well, not necessarily. 00:37:26.860 --> 00:37:29.850 Maybe this never gets confirmed. 00:37:29.850 --> 00:37:32.800 So maybe you still have that money. 00:37:32.800 --> 00:37:35.610 So you broadcast it, but you sort of 00:37:35.610 --> 00:37:37.630 have to wait until it gets into a block, 00:37:37.630 --> 00:37:40.680 and you also need to listen for your own UTXOs, 00:37:40.680 --> 00:37:42.600 even if you haven't made a transaction, 00:37:42.600 --> 00:37:44.580 and see if they've gotten spent. 00:37:44.580 --> 00:37:46.680 And why would that be? 00:37:46.680 --> 00:37:49.300 Can anyone think of a reason why? 00:37:49.300 --> 00:37:53.320 I haven't signed anything, as far as my program is concerned, 00:37:53.320 --> 00:37:54.910 but I might lose money anyway. 00:37:54.910 --> 00:37:57.315 Why would that be? 00:37:57.315 --> 00:37:57.815 Yeah. 00:37:57.815 --> 00:37:59.710 AUDIENCE: Well, one reason is you get hacked. 00:37:59.710 --> 00:38:01.720 TADGE DRYJA: Sure, you get hacked. 00:38:01.720 --> 00:38:02.770 That's the bad reason. 00:38:02.770 --> 00:38:05.290 A good reason is, well maybe you have the same wallet 00:38:05.290 --> 00:38:06.880 on multiple computers. 00:38:06.880 --> 00:38:08.290 You've got the same keys. 00:38:08.290 --> 00:38:12.880 So, getting hacked is sort of a malicious instance 00:38:12.880 --> 00:38:16.270 of this problem where I thought the wallet was only 00:38:16.270 --> 00:38:18.850 on my computer, but actually, someone else has a copy. 00:38:18.850 --> 00:38:22.102 But even non-maliciously, I've got a copy on my phone 00:38:22.102 --> 00:38:23.560 and I've got a copy on my computer. 00:38:23.560 --> 00:38:26.740 It's the same addresses, the same keys, the same UTXOs. 00:38:26.740 --> 00:38:28.480 That's totally doable. 00:38:28.480 --> 00:38:32.380 And then when I spend money with my phone and get to my desktop, 00:38:32.380 --> 00:38:34.270 my desktop needs to sort of download 00:38:34.270 --> 00:38:38.357 and see oh, money got-- you know, you lost money. 00:38:38.357 --> 00:38:40.690 And it's like, oh, yeah, yeah, I remember spending that. 00:38:40.690 --> 00:38:43.175 So you can have that over multiple computers. 00:38:43.175 --> 00:38:44.800 So if you're designing wallet software, 00:38:44.800 --> 00:38:46.258 you do definitely need to make sure 00:38:46.258 --> 00:38:49.510 that even if it's unexpected from the wallet itself, 00:38:49.510 --> 00:38:52.750 and it doesn't seem like I generated a transaction, 00:38:52.750 --> 00:38:55.600 there can still be a transaction taking your money away. 00:38:55.600 --> 00:38:59.730 Wallets without Bitcoin, and that's sort of a cheeky phrase. 00:38:59.730 --> 00:39:02.830 OK, I don't mean they don't have any Bitcoins in their wallets, 00:39:02.830 --> 00:39:05.560 I mean they're not running Bitcoin in the same sense 00:39:05.560 --> 00:39:06.910 that we've talked of. 00:39:06.910 --> 00:39:10.503 So we talked about running Bitcoin where you download 00:39:10.503 --> 00:39:11.920 the software, you get the headers, 00:39:11.920 --> 00:39:15.700 you verify all the signatures, you build the UTXO set. 00:39:15.700 --> 00:39:19.200 Can you use Bitcoin without doing this? 00:39:19.200 --> 00:39:21.150 What do you guys think? 00:39:21.150 --> 00:39:23.660 What's a simple way to possibly use Bitcoin 00:39:23.660 --> 00:39:25.358 without having to do all these things? 00:39:27.990 --> 00:39:30.002 So, a really, really simple way? 00:39:32.560 --> 00:39:34.060 If you don't want to do work, what's 00:39:34.060 --> 00:39:37.600 the simplest way to not have to do work? 00:39:37.600 --> 00:39:40.180 Get someone else to do it, right. 00:39:40.180 --> 00:39:43.900 So, for example, my dad has Bitcoin, 00:39:43.900 --> 00:39:47.510 but he just gives it-- he's like, you deal with it. 00:39:47.510 --> 00:39:49.365 So I've got a couple of Bitcoins that's 00:39:49.365 --> 00:39:50.990 my dad's, and I have to make sure like, 00:39:50.990 --> 00:39:52.962 no, this is not my money. 00:39:52.962 --> 00:39:55.330 Yeah, get someone else to do it, right? 00:39:55.330 --> 00:39:58.210 So that's what we're going to talk about, the different ways 00:39:58.210 --> 00:40:00.700 to get someone else to do this. 00:40:00.700 --> 00:40:04.360 And what we called before, running Bitcoin, 00:40:04.360 --> 00:40:06.760 many now call a "full node." 00:40:06.760 --> 00:40:10.750 And there's also the idea of a "light node" or "SPV node," 00:40:10.750 --> 00:40:13.412 which we'll talk about. 00:40:13.412 --> 00:40:15.370 Some people don't really like this distinction, 00:40:15.370 --> 00:40:16.900 and it's like, well, wait. 00:40:16.900 --> 00:40:18.520 Full node is running Bitcoin. 00:40:18.520 --> 00:40:22.060 These other things, we shouldn't have to call it a full node. 00:40:22.060 --> 00:40:23.810 We should just call this a Bitcoin node 00:40:23.810 --> 00:40:27.280 and these other things are not quite there. 00:40:27.280 --> 00:40:30.340 I will prefix there's a lot of argument 00:40:30.340 --> 00:40:32.290 about terms in this space. 00:40:32.290 --> 00:40:35.890 So there's some people who say, SPV doesn't exist. 00:40:35.890 --> 00:40:37.480 And other people, this isn't SPV. 00:40:37.480 --> 00:40:39.670 So people argue about the words. 00:40:39.670 --> 00:40:42.820 It's not like we have really nice, definitive terms. 00:40:42.820 --> 00:40:46.540 I'm generally trying to use the most widely used terms, 00:40:46.540 --> 00:40:48.550 but there's probably people who will take issue 00:40:48.550 --> 00:40:49.960 with it, so sorry. 00:40:49.960 --> 00:40:53.950 So, SPV is sort of a step down below running a full node 00:40:53.950 --> 00:40:55.930 in terms of security. 00:40:55.930 --> 00:40:58.900 It's called Simplified Payment Verification. 00:40:58.900 --> 00:41:02.110 It's written up in the white paper on how to do it. 00:41:02.110 --> 00:41:06.670 And you can verify all the work without doing 00:41:06.670 --> 00:41:11.510 too much signature verification or having too much data. 00:41:11.510 --> 00:41:14.170 So the basic idea is you're optimizing 00:41:14.170 --> 00:41:15.940 for not having to download as much 00:41:15.940 --> 00:41:19.900 and not having to store as much at the cost of some security, 00:41:19.900 --> 00:41:23.040 and I'll talk about those costs. 00:41:23.040 --> 00:41:26.650 OK, so before we have this list of what you do for a full node, 00:41:26.650 --> 00:41:29.817 the SPV method is a bit different. 00:41:29.817 --> 00:41:31.650 You still do the same part in the beginning. 00:41:31.650 --> 00:41:33.280 You connect, you get your headers, 00:41:33.280 --> 00:41:34.540 you verify all the work. 00:41:34.540 --> 00:41:35.560 OK, cool. 00:41:35.560 --> 00:41:38.530 The next step, you tell another node 00:41:38.530 --> 00:41:40.840 that you're connected to all of your addresses, 00:41:40.840 --> 00:41:44.470 all of the public keys that you've ever generated. 00:41:44.470 --> 00:41:46.510 You tell it to them. 00:41:46.510 --> 00:41:49.070 Then, for each header you go through-- 00:41:49.070 --> 00:41:50.820 and instead of downloading the whole block 00:41:50.820 --> 00:41:52.987 and getting all the transactions and verifying them, 00:41:52.987 --> 00:41:56.580 you ask the other node, hey, did I get any money, 00:41:56.580 --> 00:41:59.580 or did I lose any money in this block 00:41:59.580 --> 00:42:01.260 because I've told you all my addresses? 00:42:01.260 --> 00:42:02.280 Oh, sorry. 00:42:02.280 --> 00:42:04.310 You also tell them all your UTXOs. 00:42:04.310 --> 00:42:06.870 You also tell him, here's all the money I have, 00:42:06.870 --> 00:42:10.500 here's all the addresses I could possibly receive money on, 00:42:10.500 --> 00:42:14.190 did I get or lose any money in this block? 00:42:14.190 --> 00:42:17.350 And then they will return to you a Merkle proof 00:42:17.350 --> 00:42:18.940 of the transactions where they think, 00:42:18.940 --> 00:42:20.260 yeah, you got some money here, or yeah, 00:42:20.260 --> 00:42:22.450 you lost some money here, and you can verify this. 00:42:22.450 --> 00:42:22.740 Yes? 00:42:22.740 --> 00:42:24.020 AUDIENCE: What's the other nodes' incentive 00:42:24.020 --> 00:42:24.970 to respond to you? 00:42:28.240 --> 00:42:29.500 TADGE DRYJA: There is none. 00:42:29.500 --> 00:42:30.520 You're not paying them. 00:42:30.520 --> 00:42:32.230 They don't know who you are. 00:42:32.230 --> 00:42:35.110 There's sort of a meta incentive in that 00:42:35.110 --> 00:42:38.530 I run a node that will provide these Merkle 00:42:38.530 --> 00:42:42.953 proofs because it's like, well, it helps Bitcoin, 00:42:42.953 --> 00:42:44.620 and maybe if I have some Bitcoin and I'm 00:42:44.620 --> 00:42:47.740 helping other people use it, my Bitcoin will be worth more. 00:42:47.740 --> 00:42:51.340 But that's a pretty diffuse sort of thing. 00:42:51.340 --> 00:42:53.950 And it can be problematic because some of these things-- 00:42:53.950 --> 00:42:56.680 I didn't mention that in these slides, but the server side can 00:42:56.680 --> 00:42:58.480 get a little bit costly in terms of CPU 00:42:58.480 --> 00:43:01.390 because you're potentially-- 00:43:01.390 --> 00:43:04.480 as a server-- the client requests hey, 00:43:04.480 --> 00:43:05.280 here's this block. 00:43:05.280 --> 00:43:09.460 Can you filter it for me, find things that I'm looking for. 00:43:09.460 --> 00:43:11.440 So now you have to load that block into memory, 00:43:11.440 --> 00:43:12.970 look through it. 00:43:12.970 --> 00:43:15.870 It's not too CPU intensive, but it can be-- you know, 00:43:15.870 --> 00:43:18.130 when you have a bunch of them, like 20 or 30 of them 00:43:18.130 --> 00:43:19.420 connecting to you-- 00:43:19.420 --> 00:43:22.330 I've gotten 30%, 40% CPU for doing this kind of thing 00:43:22.330 --> 00:43:23.260 to serve other users. 00:43:26.050 --> 00:43:29.630 Most-- almost all phone wallets-- well, 00:43:29.630 --> 00:43:33.170 many phone wallets and many desktop wallets are using this 00:43:33.170 --> 00:43:35.210 model, and so you'll see-- 00:43:39.930 --> 00:43:46.222 for example, so here's a full node in this building. 00:43:46.222 --> 00:43:48.180 I actually rebooted it recently, so there's not 00:43:48.180 --> 00:43:49.472 very many connections incoming. 00:43:53.130 --> 00:43:56.730 In practice, these two are actual full nodes, I bet. 00:43:56.730 --> 00:43:57.887 This is a fake node. 00:43:57.887 --> 00:43:58.720 This is a fake node. 00:43:58.720 --> 00:44:02.670 This is-- they're all fake, yeah. 00:44:02.670 --> 00:44:05.050 Well, sorry-- these are all-- 00:44:05.050 --> 00:44:06.420 no, that one may be not. 00:44:06.420 --> 00:44:07.380 Well, you can look. 00:44:07.380 --> 00:44:09.935 But a lot of nodes will say they're nodes and they're not, 00:44:09.935 --> 00:44:12.060 and they're just trying to track where transactions 00:44:12.060 --> 00:44:16.050 are coming from and keep track tabs on you and stuff. 00:44:16.050 --> 00:44:18.030 And these are SPV nodes, these bitcore, 00:44:18.030 --> 00:44:20.927 because they don't really ask for-- 00:44:20.927 --> 00:44:22.260 I don't know what they're doing. 00:44:22.260 --> 00:44:23.250 They're not asking for anything. 00:44:23.250 --> 00:44:24.958 So you can look through all the messages. 00:44:24.958 --> 00:44:29.220 I think Ethan will talk about this a bit more Wednesday, 00:44:29.220 --> 00:44:30.812 but there are a lot of SPV nodes. 00:44:30.812 --> 00:44:32.520 There's a lot of stuff out on the network 00:44:32.520 --> 00:44:35.000 and you have no idea what it's doing, 00:44:35.000 --> 00:44:39.120 but it's pretty clearly not running a Bitcoin node. 00:44:39.120 --> 00:44:42.310 So, yeah so I'll go through these steps a little bit. 00:44:42.310 --> 00:44:42.810 Oh, yeah. 00:44:42.810 --> 00:44:48.660 So the Merkle verification we talked about last week, where, 00:44:48.660 --> 00:44:52.238 if there's a block and there's thousands of transactions in it 00:44:52.238 --> 00:44:54.780 and this server wants to prove that one of these transactions 00:44:54.780 --> 00:44:59.340 is yours and is in there, you say, OK, here's my transaction. 00:44:59.340 --> 00:45:03.390 They just need to provide you this transaction ID, this hash, 00:45:03.390 --> 00:45:06.540 and then you're able to see, OK, yeah, it was in the header. 00:45:06.540 --> 00:45:09.573 So my transaction is in there, you're not just making it up. 00:45:09.573 --> 00:45:10.990 I didn't talk about the good part. 00:45:10.990 --> 00:45:12.615 Well, the good part is you don't really 00:45:12.615 --> 00:45:15.140 need to maintain a UTXO set and it's pretty small, 00:45:15.140 --> 00:45:17.470 so it saves space, saves time. 00:45:17.470 --> 00:45:18.560 What are the problems? 00:45:18.560 --> 00:45:23.950 There's a lot, and I definitely admit before writing my own SPV 00:45:23.950 --> 00:45:26.650 wallet code, I didn't think there 00:45:26.650 --> 00:45:28.053 were a lot of problems with it. 00:45:28.053 --> 00:45:30.220 I thought it was like, oh this is SPV, this is cool. 00:45:30.220 --> 00:45:31.840 This is how wallets work. 00:45:31.840 --> 00:45:35.170 But when writing the code myself, I'm like wait, 00:45:35.170 --> 00:45:37.450 this is horrible. 00:45:37.450 --> 00:45:39.442 What do we do? 00:45:39.442 --> 00:45:41.650 OK, so the first thing you do is you connect, you get 00:45:41.650 --> 00:45:43.510 the headers, you verify them. 00:45:43.510 --> 00:45:46.180 This is exactly the same procedure 00:45:46.180 --> 00:45:48.430 as what a full node does so there's no difference, 00:45:48.430 --> 00:45:49.750 it works. 00:45:49.750 --> 00:45:50.980 No difference there. 00:45:50.980 --> 00:45:54.170 The next step, you tell a node all of your addresses. 00:45:54.170 --> 00:45:55.330 What? 00:45:55.330 --> 00:45:57.580 There goes all your privacy, right, 00:45:57.580 --> 00:45:59.680 because you're just connecting to a computer. 00:45:59.680 --> 00:46:02.110 You have no idea who they are, who's running it, 00:46:02.110 --> 00:46:04.720 and you're telling them hey, here's all of my addresses, 00:46:04.720 --> 00:46:06.880 and also here's how much money I have. 00:46:06.880 --> 00:46:09.130 Here's all my UTXOs. 00:46:09.130 --> 00:46:09.770 You can lie. 00:46:09.770 --> 00:46:12.730 You can add things that are not-- 00:46:12.730 --> 00:46:14.950 you can also add some addresses that aren't yours, 00:46:14.950 --> 00:46:16.660 or add some UTXOs that aren't yours, 00:46:16.660 --> 00:46:19.330 and you'll get some transactions back 00:46:19.330 --> 00:46:21.550 that you can then filter out on your own. 00:46:21.550 --> 00:46:23.920 So you can you can raise the rate of false positives 00:46:23.920 --> 00:46:25.610 for that server. 00:46:25.610 --> 00:46:29.080 And so there's these Bloom filters that 00:46:29.080 --> 00:46:33.370 are in the Bitcoin Core code. 00:46:33.370 --> 00:46:36.550 They said the idea was well, you can sort of 00:46:36.550 --> 00:46:39.187 dial your own false positive rate. 00:46:39.187 --> 00:46:41.020 I'm not going to go into Bloom filters work. 00:46:41.020 --> 00:46:44.380 If you've used those in other classes, cool. 00:46:44.380 --> 00:46:46.930 But it basically gives some data which 00:46:46.930 --> 00:46:50.050 allows people to match things. 00:46:50.050 --> 00:46:52.930 But they don't in practice have good privacy. 00:46:52.930 --> 00:46:55.900 You can create a Bloom filter where they've 00:46:55.900 --> 00:46:58.000 got 10% false positive rate. 00:46:58.000 --> 00:47:02.110 And so when the server says, oh, looks like their transaction, 00:47:02.110 --> 00:47:03.970 maybe it's not because 10% of the time 00:47:03.970 --> 00:47:05.660 it's just a false positive. 00:47:05.660 --> 00:47:08.680 However, when you have really high false positives, 00:47:08.680 --> 00:47:11.830 you lose all the efficiency savings of SPV 00:47:11.830 --> 00:47:14.500 and it sort of cascades where you've 00:47:14.500 --> 00:47:16.960 got these false positives and the server thinks, 00:47:16.960 --> 00:47:19.930 oh, you got money, but it's a false positive. 00:47:19.930 --> 00:47:22.480 And they add that "you got money" into the Bloom filter 00:47:22.480 --> 00:47:24.550 itself and the Bloom filter can really quickly 00:47:24.550 --> 00:47:26.050 become saturated, and then they just 00:47:26.050 --> 00:47:27.935 start giving you everything. 00:47:27.935 --> 00:47:29.560 So in practice, and there's some papers 00:47:29.560 --> 00:47:33.970 about how the people who put the Bloom filters into Bitcoin 00:47:33.970 --> 00:47:36.310 thought, oh this is good for privacy, it's fine, 00:47:36.310 --> 00:47:39.050 and in practice, it really is not good for privacy. 00:47:39.050 --> 00:47:44.560 So you end up basically telling a node all your addresses. 00:47:44.560 --> 00:47:49.210 And there's research on how to do this in a better way, 00:47:49.210 --> 00:47:50.710 and it's one of those kind of things 00:47:50.710 --> 00:47:54.550 where some random anonymous person with a, I think, 00:47:54.550 --> 00:47:58.810 inappropriate swear word email address posted to the mailing 00:47:58.810 --> 00:48:01.660 list and said, hey why don't you guys do it this way? 00:48:01.660 --> 00:48:03.360 And it was like, oh, yeah, we should 00:48:03.360 --> 00:48:05.830 have done it that way, oops. 00:48:05.830 --> 00:48:08.590 The basic idea is instead of creating a Bloom filter 00:48:08.590 --> 00:48:10.330 as a client sending it to a server, 00:48:10.330 --> 00:48:12.663 basically instead of telling the node all your addresses 00:48:12.663 --> 00:48:16.270 and asking, what the nodes will do-- the full nodes-- 00:48:16.270 --> 00:48:19.880 will create a Bloom filter based on the entire block. 00:48:19.880 --> 00:48:22.030 And then the client can retrieve that, 00:48:22.030 --> 00:48:25.090 match that against their addresses, and see, hey, 00:48:25.090 --> 00:48:27.280 did this block have anything of interest to me? 00:48:27.280 --> 00:48:29.200 And if so, request it-- 00:48:29.200 --> 00:48:34.383 much better privacy at a pretty small cost in overhead. 00:48:34.383 --> 00:48:35.800 And so, just no one thought of it. 00:48:35.800 --> 00:48:36.850 There's a lot of things in Bitcoin 00:48:36.850 --> 00:48:39.392 where it's like, no one thought of it, we did something dumb. 00:48:39.392 --> 00:48:41.620 And then something better came out 00:48:41.620 --> 00:48:43.860 and now we're working on it. 00:48:43.860 --> 00:48:46.780 OK, so you tell the node all your addresses. 00:48:46.780 --> 00:48:48.490 That's a problem. 00:48:48.490 --> 00:48:51.400 For each header, ask if you gained or lost you UTXOs? 00:48:51.400 --> 00:48:52.990 So can you think of any problems here? 00:48:56.690 --> 00:48:57.227 Yeah. 00:48:57.227 --> 00:48:59.310 AUDIENCE: Could they lie and not pay some of them? 00:48:59.310 --> 00:49:00.070 TADGE DRYJA: Yup. 00:49:00.070 --> 00:49:01.548 Easy to lie. 00:49:01.548 --> 00:49:02.590 You just don't tell them. 00:49:02.590 --> 00:49:05.020 If you're a server, you just omit things, 00:49:05.020 --> 00:49:08.027 and you can maybe mitigate that by connecting 00:49:08.027 --> 00:49:09.610 to a bunch of different nodes but then 00:49:09.610 --> 00:49:11.110 you lose even more privacy because you've now 00:49:11.110 --> 00:49:12.568 shared all your addresses and money 00:49:12.568 --> 00:49:15.310 with multiple anonymous nodes. 00:49:15.310 --> 00:49:18.250 But it's really easy to lie by omission. 00:49:18.250 --> 00:49:21.250 Someone says, hey, here's all my addresses, OK, 00:49:21.250 --> 00:49:22.100 did I get any money? 00:49:22.100 --> 00:49:22.560 Yup, yup. 00:49:22.560 --> 00:49:24.727 And then you see one where they got a bunch of money 00:49:24.727 --> 00:49:25.777 and just don't tell them. 00:49:25.777 --> 00:49:26.610 And they don't know. 00:49:29.530 --> 00:49:33.287 This can be annoying in regular wallets in the Lightning 00:49:33.287 --> 00:49:34.870 Network stuff that I work on that I'll 00:49:34.870 --> 00:49:36.670 talk about, hopefully, later. 00:49:36.670 --> 00:49:38.770 This can actually be very damaging. 00:49:38.770 --> 00:49:40.238 You can lose money because of this. 00:49:40.238 --> 00:49:42.280 But, in general, in Bitcoin, you won't lose money 00:49:42.280 --> 00:49:44.480 because you're not aware of a transaction. 00:49:44.480 --> 00:49:48.310 So this is also a problem, easy to lie by omission. 00:49:48.310 --> 00:49:51.230 The Merkle proofs help, but they prove inclusion, not exclusion. 00:49:51.230 --> 00:49:53.973 There's no way to construct a proof that-- 00:49:53.973 --> 00:49:55.640 I'm going to I'm going to give you proof 00:49:55.640 --> 00:49:57.740 that I'm not omitting anything. 00:49:57.740 --> 00:50:01.400 Although, with the idea of the block-based filters sending, 00:50:01.400 --> 00:50:03.740 there are ways to construct that, 00:50:03.740 --> 00:50:05.310 so it's even better in that sense. 00:50:05.310 --> 00:50:10.220 OK, so these are some of the disadvantages of SPV. 00:50:10.220 --> 00:50:13.640 Can anyone think of any other problems with it, or-- 00:50:13.640 --> 00:50:14.242 yeah? 00:50:14.242 --> 00:50:15.970 AUDIENCE: Fee estimation. 00:50:15.970 --> 00:50:17.450 TADGE DRYJA: Yeah, OK. 00:50:17.450 --> 00:50:19.310 So, yeah, you don't know-- 00:50:19.310 --> 00:50:21.590 since you're not downloading the blocks, 00:50:21.590 --> 00:50:24.215 you don't really know how much fees other people are paying. 00:50:24.215 --> 00:50:25.090 You're not verifying. 00:50:25.090 --> 00:50:27.500 So even when you get transactions, 00:50:27.500 --> 00:50:31.470 you cannot verify any signatures because you don't have UTXO 00:50:31.470 --> 00:50:34.430 sets, so you just see that it came from somewhere, 00:50:34.430 --> 00:50:37.190 but you don't know if the thing it's spending even exists 00:50:37.190 --> 00:50:41.450 or has a key or anything, so you can't verify the signature. 00:50:41.450 --> 00:50:43.890 You don't know how much money was coming in, 00:50:43.890 --> 00:50:45.950 so even if you look at the transactions, 00:50:45.950 --> 00:50:48.410 you can't tell what fees they're paying. 00:50:48.410 --> 00:50:52.230 You sort of can if you download the entire block. 00:50:52.230 --> 00:50:55.240 There's ways around it, but it's really ugly, 00:50:55.240 --> 00:50:57.680 so it can be very difficult to estimate fees. 00:50:57.680 --> 00:50:59.980 So, in practice, you'd probably ask the same server 00:50:59.980 --> 00:51:01.438 that you've told all your addresses 00:51:01.438 --> 00:51:04.420 and all your UTXOs to, hey, what fee should I use, 00:51:04.420 --> 00:51:05.560 then they tell you that. 00:51:05.560 --> 00:51:08.710 The idea is, well, if I ask five people, hopefully, most of them 00:51:08.710 --> 00:51:11.570 will be around the same. 00:51:11.570 --> 00:51:13.960 So there's a bunch of problems with SPV. 00:51:13.960 --> 00:51:17.302 OK, so SPV sounds pretty bad, right? 00:51:17.302 --> 00:51:18.760 I think I'll stick to my full node. 00:51:18.760 --> 00:51:22.360 But is there anything worse than SPV? 00:51:22.360 --> 00:51:23.650 Asking for a friend. 00:51:23.650 --> 00:51:25.120 Can I go worse? 00:51:25.120 --> 00:51:26.620 So does anyone know something we can 00:51:26.620 --> 00:51:31.240 do that's worse security, worse privacy than SPV 00:51:31.240 --> 00:51:32.810 and that's also very popular? 00:51:35.625 --> 00:51:36.125 Yeah. 00:51:36.125 --> 00:51:37.000 AUDIENCE: [INAUDIBLE] 00:51:37.000 --> 00:51:38.542 TADGE DRYJA: Yeah, that's even worse. 00:51:38.542 --> 00:51:40.175 But, yeah there's a step in between. 00:51:45.270 --> 00:51:47.420 So you can take out some of these steps 00:51:47.420 --> 00:51:50.880 where you just use an API and you just ask people. 00:51:50.880 --> 00:51:54.300 You have a website, blockchain.info or Mycelium 00:51:54.300 --> 00:51:56.370 Wallet, or bunch of wallets-- 00:51:56.370 --> 00:51:59.450 BitPay's, Copay, things like that where 00:51:59.450 --> 00:52:00.930 you don't verify any headers, you 00:52:00.930 --> 00:52:03.300 don't look at any Merkle proofs, you just 00:52:03.300 --> 00:52:07.050 skip right to the tell the remote node all your addresses 00:52:07.050 --> 00:52:11.400 and UTXOs and ask how much money you've gained or lost. 00:52:11.400 --> 00:52:14.820 So you've sort of outsourced the entire process. 00:52:14.820 --> 00:52:17.330 You don't store really anything on your computer. 00:52:17.330 --> 00:52:19.930 And you say, well, but you do have your private keys. 00:52:19.930 --> 00:52:23.070 You say, I made some private keys, I made some addresses, 00:52:23.070 --> 00:52:26.100 and then I tell this website, hey, here's all my addresses, 00:52:26.100 --> 00:52:28.590 how much money do I have? 00:52:28.590 --> 00:52:31.920 And the servers responds, yeah, you've got UTXOs, cool. 00:52:31.920 --> 00:52:33.640 So then you can build the transaction, 00:52:33.640 --> 00:52:36.290 sign them, and send them to the server. 00:52:36.290 --> 00:52:40.000 So what are some advantages and disadvantages of this? 00:52:43.500 --> 00:52:47.650 There's probably some obvious disadvantages, right? 00:52:47.650 --> 00:52:51.182 Can anyone think of an attack that this does not 00:52:51.182 --> 00:52:51.890 help you against? 00:52:55.320 --> 00:52:55.820 Yeah. 00:52:55.820 --> 00:52:58.670 AUDIENCE: You can just make up transactions. 00:52:58.670 --> 00:53:00.420 TADGE DRYJA: The server can just say, hey, 00:53:00.420 --> 00:53:01.560 you've got 1,000 Bitcoins. 00:53:01.560 --> 00:53:03.852 You're like, awesome, but it's just completely made up. 00:53:06.450 --> 00:53:08.400 As the client, you don't verify anything 00:53:08.400 --> 00:53:10.930 about these transactions. 00:53:10.930 --> 00:53:13.710 So that's a pretty big problem. 00:53:13.710 --> 00:53:17.100 And the thing is, in practice, one of the issues 00:53:17.100 --> 00:53:19.650 is that people are generally not as 00:53:19.650 --> 00:53:23.730 aware of these types of attacks because mostly people 00:53:23.730 --> 00:53:27.720 worry about spending their money, and they don't really-- 00:53:27.720 --> 00:53:29.690 merchants worry about charge-backs 00:53:29.690 --> 00:53:31.350 and worry about receiving and verifying 00:53:31.350 --> 00:53:33.070 that they've received funds all the time, 00:53:33.070 --> 00:53:37.200 but most people's experience is they get paid once a month 00:53:37.200 --> 00:53:39.238 or twice a month with a paycheck, 00:53:39.238 --> 00:53:41.280 and the money shows up in their bank or whatever, 00:53:41.280 --> 00:53:42.870 and they never really worry about that. 00:53:42.870 --> 00:53:44.412 They worry about spending their money 00:53:44.412 --> 00:53:46.308 and getting defrauded or things like that. 00:53:46.308 --> 00:53:47.850 So it's not something a lot of people 00:53:47.850 --> 00:53:52.740 think about all the time is, did I actually get paid? 00:53:52.740 --> 00:53:54.510 So there's easy fraud that you can 00:53:54.510 --> 00:53:56.010 do with this kind of attack vector 00:53:56.010 --> 00:54:00.043 where you sell a car on Craigslist, 00:54:00.043 --> 00:54:02.460 and someone comes and says, yeah, I paid you the Bitcoins, 00:54:02.460 --> 00:54:04.440 but they've actually compromised the server 00:54:04.440 --> 00:54:05.910 and you haven't gotten paid at all. 00:54:05.910 --> 00:54:08.490 But you think you have, so you give over the goods. 00:54:08.490 --> 00:54:11.070 So, yeah potential problems-- they can say you got paid when 00:54:11.070 --> 00:54:14.583 you didn't, they can say you lost money when you didn't. 00:54:14.583 --> 00:54:16.500 And if it's in a browser, that's even more fun 00:54:16.500 --> 00:54:19.700 because they can change the code. 00:54:19.700 --> 00:54:22.270 The JavaScript is not pinned to anything, 00:54:22.270 --> 00:54:23.970 so if someone compromises that server, 00:54:23.970 --> 00:54:26.490 they can change the code and potentially get 00:54:26.490 --> 00:54:28.470 your private keys. 00:54:28.470 --> 00:54:33.180 So you have, really, very little security. 00:54:33.180 --> 00:54:34.860 The blockchain is not really providing 00:54:34.860 --> 00:54:36.150 anything in this case. 00:54:36.150 --> 00:54:39.990 However, this is much more popular 00:54:39.990 --> 00:54:43.260 than running a full or SPV node, because you 00:54:43.260 --> 00:54:45.307 know, blockchain.info, you just sign in, 00:54:45.307 --> 00:54:46.890 there's a lot of wallets on the phones 00:54:46.890 --> 00:54:48.790 that work this way as well. 00:54:48.790 --> 00:54:53.127 And you do at least have your private keys, hopefully. 00:54:53.127 --> 00:54:54.210 So you've got that, right? 00:54:54.210 --> 00:54:57.450 You're not giving custody in any sense to them 00:54:57.450 --> 00:55:00.110 but they learn a lot of information. 00:55:00.110 --> 00:55:02.880 OK, so not even SPV. 00:55:02.880 --> 00:55:05.040 Can we do worse? 00:55:05.040 --> 00:55:08.490 Yeah, so the Coinbase company was an example 00:55:08.490 --> 00:55:09.930 of "can we do worse?" 00:55:09.930 --> 00:55:10.860 Yes, you can. 00:55:10.860 --> 00:55:13.590 Someone else's coins is worse. 00:55:13.590 --> 00:55:16.800 The case where my dad said, hey can you 00:55:16.800 --> 00:55:18.877 hold on to these coins for me, it's worse. 00:55:18.877 --> 00:55:21.210 He doesn't run a node, he doesn't have his private keys, 00:55:21.210 --> 00:55:24.030 he doesn't really understand Bitcoin that well. 00:55:24.030 --> 00:55:26.100 He wants to, but he's busy and he's 00:55:26.100 --> 00:55:28.590 like, hey, you know this stuff, you deal with it. 00:55:28.590 --> 00:55:30.960 You know way more about this than I do. 00:55:30.960 --> 00:55:33.960 I trust you since, you know, we're dad and son and stuff 00:55:33.960 --> 00:55:39.370 so not a huge trust problem there, so I do it for him. 00:55:39.370 --> 00:55:41.700 But you know, banks, right? 00:55:41.700 --> 00:55:44.520 So the idea of a site or an exchange or something 00:55:44.520 --> 00:55:47.130 like this where you don't even have your private keys. 00:55:47.130 --> 00:55:50.565 You just have a website where they run a node and a wallet 00:55:50.565 --> 00:55:51.690 and they owe you the money. 00:55:55.110 --> 00:55:59.020 It tends to end badly, and even if it doesn't end badly, 00:55:59.020 --> 00:56:00.403 it misses the point. 00:56:00.403 --> 00:56:02.070 The whole idea of Bitcoin was like, hey, 00:56:02.070 --> 00:56:03.237 you can have your own money. 00:56:03.237 --> 00:56:04.140 It's kind of cool. 00:56:04.140 --> 00:56:07.170 It's running on your computer. 00:56:07.170 --> 00:56:09.630 It feels like it's missing the point to just hand it over 00:56:09.630 --> 00:56:11.510 to some bank. 00:56:11.510 --> 00:56:13.170 And it's not even a bank. 00:56:13.170 --> 00:56:15.000 Most of these sites, a big reason 00:56:15.000 --> 00:56:16.680 why it tends to end badly is there 00:56:16.680 --> 00:56:19.620 aren't the same protections. 00:56:19.620 --> 00:56:22.230 Banks have to do a lot of work, and there's FDIC, 00:56:22.230 --> 00:56:24.750 there's all sorts of rules, and they also 00:56:24.750 --> 00:56:28.020 build these big structures with really heavy stone pillars, 00:56:28.020 --> 00:56:31.097 so you're like, yeah, they can't run off because this bank's not 00:56:31.097 --> 00:56:31.680 going to move. 00:56:31.680 --> 00:56:34.060 It's made out of rocks. 00:56:34.060 --> 00:56:38.310 And the banks in Bitcoin do not have big stone pillars. 00:56:38.310 --> 00:56:40.350 IP addresses are really easy to change and move 00:56:40.350 --> 00:56:42.810 the computers around. 00:56:42.810 --> 00:56:45.060 Another thing, they're running a node, 00:56:45.060 --> 00:56:48.930 right, these Bitcoin banks that hold all your funds. 00:56:48.930 --> 00:56:51.840 Sometimes they don't, so these banks themselves 00:56:51.840 --> 00:56:55.620 might run SPV nodes or API things. 00:56:55.620 --> 00:56:57.540 I don't want to name any names, but there's 00:56:57.540 --> 00:57:01.140 pretty good evidence that big exchanges might even just 00:57:01.140 --> 00:57:04.530 connect to an API and not even run their own node. 00:57:07.170 --> 00:57:10.193 Another-- there's a lot of things like this where, 00:57:10.193 --> 00:57:11.610 when something bad doesn't happen, 00:57:11.610 --> 00:57:14.070 people just keep pushing it-- 00:57:14.070 --> 00:57:17.550 where miners themselves don't verify the blocks because they 00:57:17.550 --> 00:57:21.780 think, well, he must have created a valid block 00:57:21.780 --> 00:57:24.270 and I'm not going to verify it and everything works. 00:57:24.270 --> 00:57:29.250 So the other thing is, while it sounds really bad, in practice, 00:57:29.250 --> 00:57:34.720 there haven't been really many SPV attacks or API attacks. 00:57:34.720 --> 00:57:38.640 We know of this, but in practice it's hard to do. 00:57:38.640 --> 00:57:44.160 If you want to defraud someone by compromising 00:57:44.160 --> 00:57:46.800 blockchain.info, you have to compromise blockchain.info. 00:57:46.800 --> 00:57:49.470 You don't have to do all the proof of work, 00:57:49.470 --> 00:57:52.380 because they're not validating it, but it's still hard to do 00:57:52.380 --> 00:57:56.220 and it requires a coordinated active attacker 00:57:56.220 --> 00:57:58.430 with quite a bit of resources. 00:57:58.430 --> 00:58:00.180 And so when it doesn't happen, people say, 00:58:00.180 --> 00:58:02.880 well, SPV is just as good. 00:58:02.880 --> 00:58:05.790 We don't have any evidence of people being defrauded, 00:58:05.790 --> 00:58:07.580 so it's just as good. 00:58:07.580 --> 00:58:09.330 But that is kind of dangerous because when 00:58:09.330 --> 00:58:10.920 everyone starts doing it, you start 00:58:10.920 --> 00:58:13.480 to lose these protections. 00:58:13.480 --> 00:58:17.770 Any questions about the someone else's coins model? 00:58:17.770 --> 00:58:19.300 There's all sorts of legal issues. 00:58:19.300 --> 00:58:26.160 There's a very long list of ways it ends badly. 00:58:26.160 --> 00:58:28.900 I don't know-- what is the half life of a custodial exchange 00:58:28.900 --> 00:58:29.400 in Bitcoin? 00:58:29.400 --> 00:58:33.900 It's like a year or two, and they drop off. 00:58:33.900 --> 00:58:36.930 So why do people do this? 00:58:36.930 --> 00:58:41.460 And here's a table of trade-offs with these things. 00:58:41.460 --> 00:58:46.930 It's mainly convenience, and so that's a real reason to do it. 00:58:46.930 --> 00:58:49.710 So if you're running a full node, 00:58:49.710 --> 00:58:52.860 you're going to have to download at least 170 gigabytes. 00:58:52.860 --> 00:58:53.790 That's a lot, right? 00:58:53.790 --> 00:58:54.810 It's going to take a while. 00:58:54.810 --> 00:58:56.435 Storage-- you're going to have to store 00:58:56.435 --> 00:58:59.260 at least 4 gigabytes long term. 00:58:59.260 --> 00:59:01.470 And that's going up, but not going up too much. 00:59:01.470 --> 00:59:03.780 It's actually gone down the last few weeks. 00:59:03.780 --> 00:59:06.930 That's the UTXO set you have to keep track of. 00:59:06.930 --> 00:59:09.270 You don't have to keep track of this 170 gigabytes. 00:59:09.270 --> 00:59:11.940 It, by default, does but you can turn on pruning. 00:59:11.940 --> 00:59:14.250 But that's also super user-unfriendly. 00:59:14.250 --> 00:59:19.050 You have to edit a bitcoin.conf file and type "pruning=500" 00:59:19.050 --> 00:59:21.690 or something, and then save it, and then it'll prune down to 4 00:59:21.690 --> 00:59:22.360 gigs. 00:59:22.360 --> 00:59:24.900 There's no-- at least, that I'm aware of-- there's 00:59:24.900 --> 00:59:26.918 no GUI nice menu thing where you can say, hey, 00:59:26.918 --> 00:59:27.960 I want to enable pruning. 00:59:27.960 --> 00:59:30.730 I don't have to store it. 00:59:30.730 --> 00:59:33.490 Speed-- on a really nice computer, 00:59:33.490 --> 00:59:38.260 it will take at least six hours to download all this 00:59:38.260 --> 00:59:39.033 and verify it. 00:59:39.033 --> 00:59:41.200 That's pretty impressive because it used to be more, 00:59:41.200 --> 00:59:42.610 but that's still six hours. 00:59:42.610 --> 00:59:45.130 People don't want to deal with that. 00:59:45.130 --> 00:59:47.520 Privacy-- certainly, we can do better. 00:59:47.520 --> 00:59:50.020 There's a lot of research on how to make privacy and Bitcoin 00:59:50.020 --> 00:59:52.800 better but this is what we got. 00:59:52.800 --> 00:59:58.260 Security-- this is as good as we've got 00:59:58.260 --> 00:59:59.920 So then you go down to SPV. 00:59:59.920 --> 01:00:03.190 Network-- you only have to download about 50 megs, all 01:00:03.190 --> 01:00:04.600 those headers. 01:00:04.600 --> 01:00:06.940 If you've got a wallet with lots of transactions, 01:00:06.940 --> 01:00:08.783 you're going to download 100, 200, 300 megs 01:00:08.783 --> 01:00:10.450 because you're going to have to download 01:00:10.450 --> 01:00:15.130 all the transactions that pay you or you're paying out to. 01:00:15.130 --> 01:00:18.670 Speed-- I said seconds, I think I want to change it to minutes. 01:00:18.670 --> 01:00:21.160 It's not that fast. 01:00:21.160 --> 01:00:22.610 It's a lot faster. 01:00:22.610 --> 01:00:24.660 I think seconds is an exaggeration. 01:00:24.660 --> 01:00:25.820 Well, it's like 60 seconds. 01:00:25.820 --> 01:00:28.760 Anyway, it's pretty fast. 01:00:28.760 --> 01:00:29.968 You download all the headers. 01:00:29.968 --> 01:00:31.427 That takes the same amount of time, 01:00:31.427 --> 01:00:33.287 but that can be a minute or two, and then 01:00:33.287 --> 01:00:34.370 you're syncing the blocks. 01:00:34.370 --> 01:00:36.760 It's really quick, they're small. 01:00:36.760 --> 01:00:38.470 Privacy is poor. 01:00:38.470 --> 01:00:41.350 You lose a lot of your privacy in SPV 01:00:41.350 --> 01:00:44.020 because you're basically telling random computers 01:00:44.020 --> 01:00:46.260 on the internet, hey, here's all my money. 01:00:46.260 --> 01:00:49.093 Hey, here's all my addresses. 01:00:49.093 --> 01:00:50.760 You're not completely losing everything, 01:00:50.760 --> 01:00:55.480 but it's pretty easy for actors to reconstruct your wallet 01:00:55.480 --> 01:00:56.680 from that. 01:00:56.680 --> 01:00:57.850 Security-- medium. 01:00:57.850 --> 01:01:01.510 I don't know, there haven't been any real attacks on this, 01:01:01.510 --> 01:01:04.150 but you're not verifying the rules of Bitcoin. 01:01:04.150 --> 01:01:07.030 If everyone's running SPV, then a miner can say, 01:01:07.030 --> 01:01:10.930 hey, I just generated 1,000 coins out of nowhere, 01:01:10.930 --> 01:01:13.090 and no one's looking for that transaction. 01:01:13.090 --> 01:01:15.750 It only pays me, and no one's going 01:01:15.750 --> 01:01:19.000 to see that and reject the block. 01:01:19.000 --> 01:01:20.950 So if everyone runs SPV, you're not 01:01:20.950 --> 01:01:24.460 checking up on the miners, which is a very real threat. 01:01:24.460 --> 01:01:28.000 Miners do crazy stuff and you got to watch out for them. 01:01:31.300 --> 01:01:34.370 So, security-- questionable. 01:01:34.370 --> 01:01:36.530 API query, where you just ask a website hey, 01:01:36.530 --> 01:01:41.240 here's all my addresses, how much money do I have? 01:01:41.240 --> 01:01:43.448 Network traffic-- I don't know, less than a megabyte. 01:01:43.448 --> 01:01:45.073 You have to load the websites and stuff 01:01:45.073 --> 01:01:45.992 but it's pretty light. 01:01:45.992 --> 01:01:48.200 Storage-- you basically don't have to store anything. 01:01:48.200 --> 01:01:50.390 I mean, you have to store your private keys, 01:01:50.390 --> 01:01:54.720 but those can be password-based and derived on the fly. 01:01:54.720 --> 01:01:56.850 Speed-- like a second, right. 01:01:56.850 --> 01:01:57.820 It's real quick. 01:01:57.820 --> 01:02:01.170 You're making an HTTP query, you're getting a response, 01:02:01.170 --> 01:02:03.150 you're parsing it, it's real quick. 01:02:03.150 --> 01:02:04.320 Privacy is poor. 01:02:04.320 --> 01:02:08.700 It's worse than SPV, but because it's really easy 01:02:08.700 --> 01:02:11.780 because you just hand them over all your addresses 01:02:11.780 --> 01:02:13.740 in the clear. 01:02:13.740 --> 01:02:17.280 And security is also quite poor, in that they can say hey, 01:02:17.280 --> 01:02:20.005 you got money or you lost money, and you just 01:02:20.005 --> 01:02:20.880 accept what they say. 01:02:23.500 --> 01:02:25.395 Hold my key-- this is network traffic. 01:02:25.395 --> 01:02:27.520 I don't know, you have to go to a website, I guess. 01:02:27.520 --> 01:02:30.647 There's no storage, there's no speed, there's no privacy, 01:02:30.647 --> 01:02:31.480 there's no security. 01:02:31.480 --> 01:02:35.950 You're just handing the entire thing off to someone else. 01:02:35.950 --> 01:02:42.250 So what would you guys guess are the popularity 01:02:42.250 --> 01:02:44.980 of the different models? 01:02:44.980 --> 01:02:47.050 Most popular to least popular. 01:02:47.050 --> 01:02:48.850 Yeah, this is definitely the most popular. 01:02:48.850 --> 01:02:52.450 Second most, third most, fourth most. 01:02:52.450 --> 01:02:55.780 Everyone does this, a few people do this, some people do this, 01:02:55.780 --> 01:02:57.880 and a couple thousand people do this. 01:03:00.540 --> 01:03:03.090 It's a problem, and this is something 01:03:03.090 --> 01:03:06.060 that is one of the ongoing problems, not just in Bitcoin. 01:03:06.060 --> 01:03:10.080 Ethereum would be a little different, 01:03:10.080 --> 01:03:13.860 but still, it's going to be a lot of this. 01:03:13.860 --> 01:03:15.590 Ethereum has a weird different SPV. 01:03:15.590 --> 01:03:17.060 There's other models. 01:03:17.060 --> 01:03:19.190 There's one in the middle for Ethereum 01:03:19.190 --> 01:03:20.930 that's also quite popular. 01:03:20.930 --> 01:03:24.803 It's like SPV with UTXO commitment. 01:03:24.803 --> 01:03:26.470 Well, no, I guess it would be more here. 01:03:26.470 --> 01:03:28.320 Anyway, I'm not going to go into Ethereum. 01:03:28.320 --> 01:03:34.152 But it's a problem and there's different ways to attack it. 01:03:34.152 --> 01:03:35.860 One of the issues is that a lot of people 01:03:35.860 --> 01:03:40.390 who program Bitcoin itself really only focus on this, 01:03:40.390 --> 01:03:44.680 and they say, look, this is not our problem. 01:03:44.680 --> 01:03:46.690 We can't solve this. 01:03:46.690 --> 01:03:48.445 We're going to try to make this-- the way 01:03:48.445 --> 01:03:49.820 we're going to try to solve this, 01:03:49.820 --> 01:03:52.240 is let's try to get the speed down. 01:03:52.240 --> 01:03:55.117 If it takes days, people are going to move this way. 01:03:55.117 --> 01:03:57.200 If it takes hours, maybe a lot of people will say, 01:03:57.200 --> 01:03:59.560 hey I was using SPV, but yeah, it's not too bad running this. 01:03:59.560 --> 01:04:01.690 I'm going to run this and get the more security. 01:04:01.690 --> 01:04:03.190 Let's try to keep this number down. 01:04:03.190 --> 01:04:04.570 Let's try to keep speed down. 01:04:04.570 --> 01:04:07.510 Let's try to improve privacy and security of the full node. 01:04:07.510 --> 01:04:11.530 That is generally what most of the Bitcoin Core developers 01:04:11.530 --> 01:04:14.770 focus on, which I don't argue with. 01:04:14.770 --> 01:04:21.540 But it does lead to some neglect of SPV, where there's not-- 01:04:21.540 --> 01:04:24.460 it's been over a year, year and a half, almost two years 01:04:24.460 --> 01:04:27.950 where we know how to make SPV better and more secure, 01:04:27.950 --> 01:04:31.030 but there's not a lot of enthusiasm and people 01:04:31.030 --> 01:04:32.990 working on it. 01:04:32.990 --> 01:04:35.700 And people argue about the security of these things. 01:04:35.700 --> 01:04:37.920 This, there's not much you can do. 01:04:37.920 --> 01:04:40.480 I mean, there is kind of cryptography research like, 01:04:40.480 --> 01:04:45.530 hey, is there some cool way I can send you all my addresses 01:04:45.530 --> 01:04:48.030 so that you can figure out how much money I have without you 01:04:48.030 --> 01:04:50.880 learning all my addresses? 01:04:50.880 --> 01:04:52.790 That's called private information retrieval, 01:04:52.790 --> 01:04:55.500 and there's all sorts of papers on that. 01:04:55.500 --> 01:04:58.780 In practice, there aren't any that use that. 01:04:58.780 --> 01:05:03.290 And this, well, yeah multi-sig. 01:05:03.290 --> 01:05:04.980 That's more like regulation. 01:05:04.980 --> 01:05:07.860 Can we have restrictions and rules on these, essentially, 01:05:07.860 --> 01:05:12.240 banks to try to make it safer, maybe? 01:05:12.240 --> 01:05:16.470 These are the two where software development can definitely help 01:05:16.470 --> 01:05:19.470 make this a lot easier to use. 01:05:19.470 --> 01:05:23.177 So we can encourage people to use it, but most people-- 01:05:23.177 --> 01:05:25.260 security is hard because most people, if you don't 01:05:25.260 --> 01:05:29.040 see a problem, this is a lot easier, and a lot of people 01:05:29.040 --> 01:05:32.520 think, well, I'm not good at computers, so-- 01:05:32.520 --> 01:05:35.460 they are, and it's safer if I give all my money 01:05:35.460 --> 01:05:37.170 to someone else. 01:05:37.170 --> 01:05:39.720 In some cases, it could be true. 01:05:39.720 --> 01:05:42.690 But that has systemic effects where now you've 01:05:42.690 --> 01:05:46.740 got these five computers in the world, 01:05:46.740 --> 01:05:48.990 and if you're able to compromise those, 01:05:48.990 --> 01:05:50.670 they have just billions of dollars 01:05:50.670 --> 01:05:52.630 worth of Bitcoins on them. 01:05:52.630 --> 01:05:57.270 And so that's why black hat hacker kind of people, 01:05:57.270 --> 01:05:59.760 it's like the best thing to do. 01:05:59.760 --> 01:06:02.400 It's like, there's a computer somewhere 01:06:02.400 --> 01:06:07.120 and it's got a billion dollars of untraceable money 01:06:07.120 --> 01:06:08.430 that I can just steal. 01:06:08.430 --> 01:06:11.940 Like, it's-- what could be better? 01:06:11.940 --> 01:06:14.160 Yeah, I could get everyone's passwords. 01:06:14.160 --> 01:06:14.820 That's cool. 01:06:14.820 --> 01:06:17.760 Or yeah, I could read people's emails. 01:06:17.760 --> 01:06:18.660 Whatever. 01:06:18.660 --> 01:06:21.570 Or, I can just steal a billion dollars. 01:06:21.570 --> 01:06:25.100 So what do you think they're going to do? 01:06:25.100 --> 01:06:28.020 So this leads to huge concentrations 01:06:28.020 --> 01:06:31.140 of coins in a very small number of nodes, 01:06:31.140 --> 01:06:32.430 and people try to attack it. 01:06:32.430 --> 01:06:35.370 So this is sort of the landscape we're in now. 01:06:35.370 --> 01:06:36.663 It's certainly not ideal. 01:06:36.663 --> 01:06:38.580 There's a lot of technology that's pretty good 01:06:38.580 --> 01:06:40.030 that's not being used. 01:06:40.030 --> 01:06:41.447 There's a lot of technology that's 01:06:41.447 --> 01:06:45.210 crummy that's being used a lot and how we make this stronger 01:06:45.210 --> 01:06:47.190 and faster, how to make this faster, 01:06:47.190 --> 01:06:49.590 things like that are really interesting research areas. 01:06:53.800 --> 01:06:54.370 Almost done. 01:06:54.370 --> 01:06:57.767 Wallets are fun, but usability issues. 01:06:57.767 --> 01:06:59.350 If you want to try testing out wallets 01:06:59.350 --> 01:07:03.100 you can try downloading them, playing around with them. 01:07:03.100 --> 01:07:05.450 They often leave quite a bit to be desired. 01:07:05.450 --> 01:07:10.510 The one I work on, Lit, leaves enormous amounts to be desired. 01:07:10.510 --> 01:07:12.573 It's all in text. 01:07:12.573 --> 01:07:13.990 And Ethan should be here Wednesday 01:07:13.990 --> 01:07:17.040 and good luck with the problem set.