WEBVTT 00:00:01.110 --> 00:00:04.830 The following content is provided under a Creative Commons license. 00:00:04.830 --> 00:00:09.300 Your support will help MIT OpenCourseWare continue to offer high quality educational 00:00:09.300 --> 00:00:11.070 resources for free. 00:00:11.070 --> 00:00:19.400 To make a donation or to view additional materials from hundreds of MIT courses, visit MIT OpenCourseWare 00:00:19.400 --> 00:00:21.430 at ocw.mit.edu. 00:00:21.430 --> 00:00:27.540 TADGE DRYJA: So today will be some sort of future technologies, future developments that 00:00:27.540 --> 00:00:31.090 might not be around yet, but are interesting things to look for. 00:00:31.090 --> 00:00:34.600 And if you're interested in researching these kinds of things, you want to make a EmenG 00:00:34.600 --> 00:00:37.620 out of this or want to make a-- who knows? 00:00:37.620 --> 00:00:42.170 PhD probably is a little overkill for a lot of these things. 00:00:42.170 --> 00:00:47.530 But if you're interested in this kind of research, here's some things we'll talk about today-- 00:00:47.530 --> 00:00:53.890 block slash block filters or committed bloom filters, sharding, accumulators, and UTXO 00:00:53.890 --> 00:00:54.890 commitments. 00:00:54.890 --> 00:01:02.510 OK, so, first one I'll talk about is block filters. 00:01:02.510 --> 00:01:06.630 So I don't think I ever really talked about what a Bloom filter is. 00:01:06.630 --> 00:01:11.530 I'm still not really going to explain how they work, but the basic idea, the sort of 00:01:11.530 --> 00:01:14.170 high level-- here's the prototype. 00:01:14.170 --> 00:01:15.250 Here's the function prototype. 00:01:15.250 --> 00:01:17.890 Here's the interface that Bloom filters have. 00:01:17.890 --> 00:01:21.990 So you make a filter from a bunch of objects. 00:01:21.990 --> 00:01:24.408 And in this case, objects are just bytes, right? 00:01:24.408 --> 00:01:27.420 Or some string of bytes. 00:01:27.420 --> 00:01:29.960 And Bloom filters usually use hash functions under the hood. 00:01:29.960 --> 00:01:32.408 A lot of times, they don't use cryptographic hash functions. 00:01:32.408 --> 00:01:36.310 They can use sort of faster functions, where there may be collisions. 00:01:36.310 --> 00:01:39.700 But in this case, it's not like a security problem. 00:01:39.700 --> 00:01:41.439 So you've got a bunch of objects. 00:01:41.439 --> 00:01:47.060 They might be addresses, which are 20 byte pubkey hashes, or your UTXOs, which you can 00:01:47.060 --> 00:01:53.689 represent as a 36 byte TIXD and out point, or TIXD and index. 00:01:53.689 --> 00:01:55.250 So they're small, right? 00:01:55.250 --> 00:01:59.229 So either 20 bytes, 36 bytes, sometimes 32 bytes. 00:01:59.229 --> 00:02:04.420 You put these list of data objects and make a filter, and you get a filter out. 00:02:04.420 --> 00:02:09.840 And the filters are usually a kilobyte sometimes. 00:02:09.840 --> 00:02:13.010 But the idea is it's sort of a mix of hash functions. 00:02:13.010 --> 00:02:14.560 And then you say, OK, I want to match filters. 00:02:14.560 --> 00:02:18.980 Usually, a different person does this and says, OK, I've got a filter that someone generated. 00:02:18.980 --> 00:02:23.329 And I compare it against this object and see if there's a hit, all right? 00:02:23.329 --> 00:02:25.310 So I see, OK, that matched. 00:02:25.310 --> 00:02:29.660 This object matched the filter, or this object did not match the filter. 00:02:29.660 --> 00:02:33.260 And this returns a true or false. 00:02:33.260 --> 00:02:35.730 And so what's interesting about these is you can have false positives. 00:02:35.730 --> 00:02:39.989 So it may be that this object was not in here. 00:02:39.989 --> 00:02:45.569 It was not used when creating the filter, but it still returns true. 00:02:45.569 --> 00:02:49.470 So it's sort of matching against multiple different hash functions, seeing, hey, do 00:02:49.470 --> 00:02:50.480 any of these bits match? 00:02:50.480 --> 00:02:55.110 And it says, oh, yeah, this object may have been in this filter. 00:02:55.110 --> 00:02:57.410 However, there's no false negatives. 00:02:57.410 --> 00:03:04.629 So if you did put, say, address A into this filter and then matched this filter against 00:03:04.629 --> 00:03:07.569 address A, it would always return true. 00:03:07.569 --> 00:03:14.140 There's no way you can put something into the filter, and then it doesn't show up when 00:03:14.140 --> 00:03:16.510 you try to match against it. 00:03:16.510 --> 00:03:19.349 So this is useful for lots of things. 00:03:19.349 --> 00:03:24.599 Bloom filters are definitely not restricted to cryptocurrency, Bitcoin, or anything like 00:03:24.599 --> 00:03:25.599 that. 00:03:25.599 --> 00:03:30.140 They're used all the time in various databases, all the time in things like that. 00:03:30.140 --> 00:03:36.260 The current way they're used in Bitcoin is for SPV filtering. 00:03:36.260 --> 00:03:38.620 So we defined SPV, like, months ago. 00:03:38.620 --> 00:03:41.250 The basic idea is I'm a client. 00:03:41.250 --> 00:03:43.900 I don't want to download and verify the whole blockchain. 00:03:43.900 --> 00:03:46.590 I want someone else to do that. 00:03:46.590 --> 00:03:48.420 I assume the miners are doing the right thing. 00:03:48.420 --> 00:03:51.410 I assume the rest of the network is doing the right thing. 00:03:51.410 --> 00:03:53.950 And I just want to know about my data. 00:03:53.950 --> 00:03:55.630 So I'm not going to download the whole block. 00:03:55.630 --> 00:03:59.980 I'm not going to verify all the signatures or keep a UTXO set on my own. 00:03:59.980 --> 00:04:04.310 I'm just concerned with my UTXOs in my wallet. 00:04:04.310 --> 00:04:07.120 So what I do-- and this exists today. 00:04:07.120 --> 00:04:09.110 You can do this. 00:04:09.110 --> 00:04:12.420 You make a Bloom filter of all your UTXOs and addresses. 00:04:12.420 --> 00:04:17.079 So you say, OK, here's all my addresses that I'm hoping to receive money on. 00:04:17.079 --> 00:04:22.210 I've got 20 of them, 30 of them, 100 of them-- however many-- although Bloom filters don't 00:04:22.210 --> 00:04:23.839 really work once you have too many. 00:04:23.839 --> 00:04:28.210 But so the idea is if you have five addresses, let's say, you start a wallet. 00:04:28.210 --> 00:04:29.539 You don't have any money. 00:04:29.539 --> 00:04:33.379 You're pretty sure you don't know of any money yet existing. 00:04:33.379 --> 00:04:36.199 But you say, OK, I made five addresses. 00:04:36.199 --> 00:04:37.490 I told these addresses to people. 00:04:37.490 --> 00:04:38.569 They might have sent me money. 00:04:38.569 --> 00:04:39.669 That'd be nice. 00:04:39.669 --> 00:04:42.499 So you make a Bloom filter of all these addresses, right? 00:04:42.499 --> 00:04:51.058 So let's say you've got, OK, address A-- dot dot dot-- A through E. And you make a filter. 00:04:51.058 --> 00:04:58.729 OK, so you say I've got my filter F. I then send that filter F to a remote server. 00:04:58.729 --> 00:04:59.879 So there's the cloud. 00:04:59.879 --> 00:05:04.300 There's some Bitcoin full node out here. 00:05:04.300 --> 00:05:10.659 It receives filter F. OK, so this got filter F. And it knows that this filter F is specific 00:05:10.659 --> 00:05:11.759 to me, right? 00:05:11.759 --> 00:05:17.589 So it sees that, hey, I'm a client. 00:05:17.589 --> 00:05:18.899 I'm an SPV client. 00:05:18.899 --> 00:05:23.069 I connect to a full node, and I say, hey, I sent a message that's called load filter. 00:05:23.069 --> 00:05:28.639 And I say, hey, load filter, here's my filter F. Only send stuff to me that matches this 00:05:28.639 --> 00:05:30.129 filter. 00:05:30.129 --> 00:05:35.058 99% of all the whole thing-- everything going on in Bitcoin, I don't care about. 00:05:35.058 --> 00:05:39.300 Here's a filter, and only send me messages that match this filter. 00:05:39.300 --> 00:05:45.800 And so when it sends a transact-- well, they send INV messages, right? 00:05:45.800 --> 00:05:49.740 When it sends an INV message with inventory, saying, hey, I found this thing that you might 00:05:49.740 --> 00:05:55.210 be interested in, normally, a full node to another full node-- so let's say there's communication 00:05:55.210 --> 00:06:00.779 between two full nodes, Full2. 00:06:00.779 --> 00:06:04.210 These guys will talk to each other about every transaction they see, right? 00:06:04.210 --> 00:06:07.089 So if they see a transaction, it's valid. 00:06:07.089 --> 00:06:08.539 There's nothing wrong with it. 00:06:08.539 --> 00:06:12.069 They'll just send it to each other to propagate transaction throughout the network, so they 00:06:12.069 --> 00:06:13.339 can get mined later. 00:06:13.339 --> 00:06:19.219 However, if a filter has been loaded, it says, oh, OK, I will only send you INV messages 00:06:19.219 --> 00:06:20.749 that match this filter. 00:06:20.749 --> 00:06:25.300 So if there's a transaction that doesn't have any of these five addresses as an output, 00:06:25.300 --> 00:06:28.800 they're just not going to send it to you. 00:06:28.800 --> 00:06:33.289 Similarly, when a block comes out-- this is the big one. 00:06:33.289 --> 00:06:35.620 Normally, blocks get propagated the same. 00:06:35.620 --> 00:06:37.949 They just send you the block. 00:06:37.949 --> 00:06:41.649 Here, we do something called a Merkle block. 00:06:41.649 --> 00:06:43.889 I don't send you a regular block. 00:06:43.889 --> 00:06:51.129 I filter everything within the block and send you only the things that match to that filter. 00:06:51.129 --> 00:06:54.810 So generally, it gets very small. 00:06:54.810 --> 00:06:57.779 So the Merkle block might just have one transaction in it. 00:06:57.779 --> 00:07:01.419 And it has the sort of Merkle proof up to the root. 00:07:01.419 --> 00:07:06.289 So the server sends only the matching transactions in the block, which can drop from a megabyte 00:07:06.289 --> 00:07:08.189 to less than a kilobyte. 00:07:08.189 --> 00:07:10.509 And then the client says, oh, cool. 00:07:10.509 --> 00:07:12.779 There's a transaction where I received money. 00:07:12.779 --> 00:07:13.779 Great. 00:07:13.779 --> 00:07:20.089 Also, let me update my filter to include this new transaction that I received. 00:07:20.089 --> 00:07:23.900 So if that gets spent later, I want to know about it, even if it doesn't send to one of 00:07:23.900 --> 00:07:25.150 these five addresses, right? 00:07:25.150 --> 00:07:29.360 So if you're only matching on addresses, you can only sort of get money. 00:07:29.360 --> 00:07:34.539 But if you're matching on these UTXOs, you can lose the money as well. 00:07:34.539 --> 00:07:38.479 And you don't want to lose money, but you sort of want to know when everyone else thinks 00:07:38.479 --> 00:07:41.319 you lost money. 00:07:41.319 --> 00:07:42.659 So this works today. 00:07:42.659 --> 00:07:44.539 This was implemented 2012-ish. 00:07:44.539 --> 00:07:51.169 The history behind it was the first Android Bitcoin wallet. 00:07:51.169 --> 00:07:54.930 Andreas Schildbach wrote it, and it didn't do this, right? 00:07:54.930 --> 00:08:00.800 It just downloaded the whole block and then threw away most of the data and only kept-- 00:08:00.800 --> 00:08:04.229 it wasn't a full node, and then it didn't keep a UTXO set. 00:08:04.229 --> 00:08:07.789 But it did download everything. 00:08:07.789 --> 00:08:09.739 And then they were saying, OK, this is really slow. 00:08:09.739 --> 00:08:14.839 We want a decentralized way to do this kind of thing, where instead of just connecting 00:08:14.839 --> 00:08:21.889 to a server-- so the other model I explained, again, weeks ago was, you just have some server. 00:08:21.889 --> 00:08:24.119 And you tell it the address and say, hey, here's my address. 00:08:24.119 --> 00:08:25.469 How much money do I have? 00:08:25.469 --> 00:08:29.759 And it sends you transactions, and you maintain your wallet that way. 00:08:29.759 --> 00:08:32.200 This is nicer because it's decentralized, right? 00:08:32.200 --> 00:08:33.909 Every full node can do this. 00:08:33.909 --> 00:08:39.209 And by default, if you download Bitcoin 0.16 or whatever recent versions-- not even recent-- 00:08:39.209 --> 00:08:40.269 since like 0.7? 00:08:40.269 --> 00:08:42.149 I don't know. 00:08:42.149 --> 00:08:49.399 Most of the versions will have this capability, where if a client says, hey, here's a Bloom 00:08:49.399 --> 00:08:50.399 filter. 00:08:50.399 --> 00:08:51.399 Load it. 00:08:51.399 --> 00:08:52.820 Your full node will load that filter. 00:08:52.820 --> 00:08:57.509 And then every block that comes in or every block that's requested, they will match against 00:08:57.509 --> 00:08:58.509 the filter. 00:08:58.509 --> 00:09:00.899 The filter match function call's not too heavy. 00:09:00.899 --> 00:09:02.279 It involves a bunch of hash functions. 00:09:02.279 --> 00:09:05.690 It's not too slow, but it's slower than doing nothing, right? 00:09:05.690 --> 00:09:07.550 It's slower than just sending it directly. 00:09:07.550 --> 00:09:09.870 OK, so this is nice, right? 00:09:09.870 --> 00:09:17.490 You can sync the entire chain in way less data and having SPV security. 00:09:17.490 --> 00:09:20.660 Problems-- it's really bad for privacy. 00:09:20.660 --> 00:09:22.220 You're sending a Bloom filter, right? 00:09:22.220 --> 00:09:26.810 So it's this thing that's created from your list of addresses. 00:09:26.810 --> 00:09:33.310 But in practice, it's got about the same security as just telling them all your addresses, right? 00:09:33.310 --> 00:09:36.650 So it's sort of like, oh, I'm sending a hash of my address, instead of my address. 00:09:36.650 --> 00:09:41.100 Well, yeah, but I know all the addresses in existence on the Bitcoin network. 00:09:41.100 --> 00:09:45.640 I can just try to match it, try to hash and stuff like that. 00:09:45.640 --> 00:09:49.440 When you do Bloom filters, there's this sort of false positive rate that's sort of a knob 00:09:49.440 --> 00:09:50.440 you can twist. 00:09:50.440 --> 00:09:56.000 And you can say, oh, I'm going to make a Bloom filter where 10% of the time, when you perform 00:09:56.000 --> 00:10:02.680 this match filter for any given object, I'm going to create a filter where 10% of the 00:10:02.680 --> 00:10:03.920 time, it'll just return true. 00:10:03.920 --> 00:10:05.610 So I can dial in a false positive rate. 00:10:05.610 --> 00:10:08.810 So I can say, OK, I'll make it 1%. 00:10:08.810 --> 00:10:17.029 And then when I get these matching transactions from the full node, yeah, I'll get an extra 00:10:17.029 --> 00:10:19.449 few transactions that don't match my filter. 00:10:19.449 --> 00:10:24.160 Or they match my filter, but they don't actually match anything I'm looking at. 00:10:24.160 --> 00:10:26.090 And that will improve my privacy, right? 00:10:26.090 --> 00:10:32.100 Because then the full node doesn't see what's-- he doesn't know what's truly mine. 00:10:32.100 --> 00:10:35.329 In fact, you don't even know what the false positive rate is. 00:10:35.329 --> 00:10:39.660 When you receive a filter, you don't know what the false positive rate is. 00:10:39.660 --> 00:10:43.079 You just see, OK, these things match, and you send them. 00:10:43.079 --> 00:10:48.459 Another strategy is OK, I'm a SPV client. 00:10:48.459 --> 00:10:55.540 I connect to a bunch of full nodes, and I can give different filters to each one. 00:10:55.540 --> 00:10:58.120 I think the initial software did this. 00:10:58.120 --> 00:11:03.089 And because you can sort of put some randomness into your different filters to hope-- why 00:11:03.089 --> 00:11:04.790 did they do this? 00:11:04.790 --> 00:11:06.660 It actually makes it worse. 00:11:06.660 --> 00:11:12.339 It actually makes it worse because if these full nodes collude-- collaborate-- whatever. 00:11:12.339 --> 00:11:17.339 If these full nodes share the information of the filters, it makes it easier to determine, 00:11:17.339 --> 00:11:19.069 to sort of filter out the false positives. 00:11:19.069 --> 00:11:22.700 Because they'll have different false positives because they had a different filter. 00:11:22.700 --> 00:11:28.570 And so if they collaborate, if they work together, they can say, oh, well, I got some false positive 00:11:28.570 --> 00:11:29.570 transactions. 00:11:29.570 --> 00:11:30.570 I did, too. 00:11:30.570 --> 00:11:34.990 We can filter out the ones that one of us had as a false positive and not the other, 00:11:34.990 --> 00:11:35.990 right? 00:11:35.990 --> 00:11:38.540 So we can detect the false positives we're sending to the client. 00:11:38.540 --> 00:11:41.029 So privacy is really bad. 00:11:41.029 --> 00:11:46.190 There's a paper written I think 2013 or 2014, where they basically broke the whole privacy 00:11:46.190 --> 00:11:49.779 argument for this Bloom filter based SPV. 00:11:49.779 --> 00:11:53.759 And they said in practice, you can get like 90 something percent of the addresses and 00:11:53.759 --> 00:11:57.439 UTXOs that people are sending for the software. 00:11:57.439 --> 00:12:02.540 And their recommendations were like, yeah, I don't see how you make this work privately. 00:12:02.540 --> 00:12:05.490 There's just no privacy here. 00:12:05.490 --> 00:12:10.470 It's slow for the servers, so when you're running-- I don't know if you can see. 00:12:10.470 --> 00:12:15.300 When you're running a full node-- OK, I should close that. 00:12:15.300 --> 00:12:17.579 Don't even know what that is. 00:12:17.579 --> 00:12:29.269 When you're running a full node, you can see here's all the nodes that are connected to 00:12:29.269 --> 00:12:32.790 my full node and running downstairs. 00:12:32.790 --> 00:12:35.240 Most of them are other full nodes. 00:12:35.240 --> 00:12:36.449 Oh, OK, these are not. 00:12:36.449 --> 00:12:37.730 I don't know what those are. 00:12:37.730 --> 00:12:39.310 Those are not true. 00:12:39.310 --> 00:12:42.139 All these 0.9, 0.99s, they're not actually nodes at all. 00:12:42.139 --> 00:12:44.670 They don't seem to ask for anything. 00:12:44.670 --> 00:12:46.749 And then some people put their version message. 00:12:46.749 --> 00:12:47.990 They put an address. 00:12:47.990 --> 00:12:49.800 Hopefully, someone will send them lots of money. 00:12:49.800 --> 00:12:52.649 It's not going to happen. 00:12:52.649 --> 00:12:53.800 That's weird. 00:12:53.800 --> 00:12:57.620 There's like no SPV-- well, OK, bitcoinj. 00:12:57.620 --> 00:13:03.060 So that's a Java implementation, which does filter load. 00:13:03.060 --> 00:13:05.819 And so we can look-- hm. 00:13:05.819 --> 00:13:14.829 A fee filter, but no filter load. 00:13:14.829 --> 00:13:17.069 Well, that's weird. 00:13:17.069 --> 00:13:19.829 Someone's sending me lots of different fee filter messages. 00:13:19.829 --> 00:13:21.699 There's lots of weird stuff going on in the Bitcoin network. 00:13:21.699 --> 00:13:28.529 But I weirdly don't have any SPV filter load things going on right now, which is unusual. 00:13:28.529 --> 00:13:31.560 I don't know. 00:13:31.560 --> 00:13:40.320 It changes a lot, too, based on-- so also, you can sort of track your hourly data usage. 00:13:40.320 --> 00:13:45.829 And this server basically is only for-- all this traffic is the clients connected. 00:13:45.829 --> 00:13:48.019 You know, Bitcoin. 00:13:48.019 --> 00:13:54.389 And so I'm doing, like, a gigabyte every hour, which is a lot for a home connection, but 00:13:54.389 --> 00:13:55.680 not too bad for here. 00:13:55.680 --> 00:13:58.480 But in December, everyone was interested in Bitcoin. 00:13:58.480 --> 00:14:01.329 And so you had lots of people downloading it, running it. 00:14:01.329 --> 00:14:05.759 And it would be something like 10 times this, where just tons of people were installing 00:14:05.759 --> 00:14:10.819 it, downloading it, getting a whole blockchain, and then probably after losing interest, deleting 00:14:10.819 --> 00:14:12.449 it, but whatever. 00:14:12.449 --> 00:14:17.550 And a lot of SPV clients doing filter loads can slow down your server. 00:14:17.550 --> 00:14:20.749 It can take CPU time. 00:14:20.749 --> 00:14:24.499 Right now, yeah, OK, so 6%, 2%. 00:14:24.499 --> 00:14:31.100 It's pretty low CPU usage generally for Bitcoin, even with that many-- however many that was-- 00:14:31.100 --> 00:14:34.920 30 or 40 different other nodes connecting and downloading stuff. 00:14:34.920 --> 00:14:39.580 Basically, this is like receiving transactions, verifying the signatures, and sending them 00:14:39.580 --> 00:14:40.580 out. 00:14:40.580 --> 00:14:42.529 And granted-- but this is per core, right? 00:14:42.529 --> 00:14:45.790 So if I have 2%, that's 2% of a single core. 00:14:45.790 --> 00:14:47.089 It's really not much. 00:14:47.089 --> 00:14:52.610 And then I guess Cryptokernel's only using 1%, so even less. 00:14:52.610 --> 00:15:00.279 So yeah, it's not much, but when you have a lot of SPV clients, it can start using a 00:15:00.279 --> 00:15:02.009 lot of CPU. 00:15:02.009 --> 00:15:05.569 OK, so how do we improve this? 00:15:05.569 --> 00:15:06.860 This is a new-ish idea. 00:15:06.860 --> 00:15:08.769 It's actually about two years old. 00:15:08.769 --> 00:15:10.490 And it was kind of interesting. 00:15:10.490 --> 00:15:16.709 It was just a random anonymous internet person posted on the mailing list. 00:15:16.709 --> 00:15:21.300 I think his email address was some inappropriate swear word or something. 00:15:21.300 --> 00:15:22.570 Anyway. 00:15:22.570 --> 00:15:28.410 But whoever this person was just said, hey, why don't we do it the other way? 00:15:28.410 --> 00:15:30.170 Why don't we do it backwards? 00:15:30.170 --> 00:15:36.019 And instead of having the client create a Bloom filter and send it to the full node, 00:15:36.019 --> 00:15:42.139 have the full nodes make Bloom filters from all the transactions within a block. 00:15:42.139 --> 00:15:45.399 And then the client will just ask for that filter. 00:15:45.399 --> 00:15:51.540 The client can then perform the filter match function on their own UTXO set. 00:15:51.540 --> 00:15:55.209 And then if they do find a match, they request the entire block. 00:15:55.209 --> 00:15:56.319 Right? 00:15:56.319 --> 00:15:58.370 So this is a different model. 00:15:58.370 --> 00:15:59.570 I don't know. 00:15:59.570 --> 00:16:04.730 Does it get the idea where, OK, so you're a client. 00:16:04.730 --> 00:16:06.279 All you do is request filters. 00:16:06.279 --> 00:16:08.619 So you say, filter please. 00:16:08.619 --> 00:16:13.089 So you have some kind of filter request. 00:16:13.089 --> 00:16:18.170 And then the full node just says, OK, for every block in the blockchain, I'm going to 00:16:18.170 --> 00:16:21.240 create a filter, right? 00:16:21.240 --> 00:16:26.750 I take all the objects in the block, which are basically all the addresses used in every 00:16:26.750 --> 00:16:29.990 transaction, all the UTXOs spent in every transaction. 00:16:29.990 --> 00:16:35.190 I concatenate that, so there's going to be 5,000, 10,000-- a lot of these objects. 00:16:35.190 --> 00:16:39.820 Put it into a really big Bloom filter, generally bigger than the ones used in this method. 00:16:39.820 --> 00:16:45.819 Because usually, a wallet won't have thousands of addresses or thousands of UTXOs. 00:16:45.819 --> 00:16:50.910 It's possible, but in this model, usually, you've got 20, 30, maybe 100. 00:16:50.910 --> 00:16:53.319 But in this case, you're going to have thousands. 00:16:53.319 --> 00:16:58.459 Make a larger filter, create the filter, and store it for each block. 00:16:58.459 --> 00:17:00.750 So maybe it's 20 kilobytes or something. 00:17:00.750 --> 00:17:03.369 And maybe in this case, they're only like 1 kilobyte. 00:17:03.369 --> 00:17:04.500 So you have a filter. 00:17:04.500 --> 00:17:07.939 And then the node will request these filters for every block. 00:17:07.939 --> 00:17:08.939 So it's OK, this block, get the filter. 00:17:08.939 --> 00:17:10.359 Get the filter. 00:17:10.359 --> 00:17:13.720 And then perform the matching on their own, right? 00:17:13.720 --> 00:17:15.520 So they've got the filter. 00:17:15.520 --> 00:17:18.619 They see, hey, does this filter match any of my addresses? 00:17:18.619 --> 00:17:23.689 So is there anything in this block that may have paid me or anything in this block where 00:17:23.689 --> 00:17:26.940 my transactions may have been spent? 00:17:26.940 --> 00:17:29.560 And if they get a true, they just request the whole block. 00:17:29.560 --> 00:17:33.309 They just download the whole 1 megabyte block or whatever it is. 00:17:33.309 --> 00:17:35.070 And there may be false positives, right? 00:17:35.070 --> 00:17:38.260 So they might be downloading the block for no reason. 00:17:38.260 --> 00:17:40.890 They download the whole block, see there's nothing of their address. 00:17:40.890 --> 00:17:41.890 Yeah. 00:17:41.890 --> 00:17:48.492 AUDIENCE: How does that work if we increase the block size to a ridiculous amount? 00:17:48.492 --> 00:17:49.492 [INAUDIBLE] 00:17:49.492 --> 00:17:50.492 TADGE DRYJA: Wait, ridiculous amount block size? 00:17:50.492 --> 00:17:51.492 Yeah, I guess. 00:17:51.492 --> 00:17:52.492 AUDIENCE: [INAUDIBLE] 00:17:52.492 --> 00:17:58.640 TADGE DRYJA: Well, I mean, they're not going to actually-- I don't think any of these have 00:17:58.640 --> 00:18:02.640 actually 32 megabyte blocks and that no one's using them. 00:18:02.640 --> 00:18:08.309 Even Bitcoin now, right, where the actual block usage has gone down substantially. 00:18:08.309 --> 00:18:12.649 You've got like-- I don't know-- 500k or something average now? 00:18:12.649 --> 00:18:13.649 It's low. 00:18:13.649 --> 00:18:18.930 Occasionally, you have lots of little transactions saturating the mempool and then full blocks 00:18:18.930 --> 00:18:20.630 for a few hours. 00:18:20.630 --> 00:18:22.760 But it's gone down, and it's not even at full usage. 00:18:22.760 --> 00:18:27.220 So and Bitcoin cash, yeah, you've got 8 megabyte max size, but-- 00:18:27.220 --> 00:18:28.270 AUDIENCE: [INAUDIBLE] 00:18:28.270 --> 00:18:30.380 TADGE DRYJA: Right, right. 00:18:30.380 --> 00:18:32.500 And they're going to do 32 megs full sized. 00:18:32.500 --> 00:18:37.610 But still, the actual blocks are like 10k, 20k, whatever. 00:18:37.610 --> 00:18:45.480 I mean, yeah, but if you did have actually 32 megabyte blocks, a false positive would 00:18:45.480 --> 00:18:47.950 be a big problem for a light node. 00:18:47.950 --> 00:18:51.950 Because now you have to download this 32 megabyte block, look through the whole thing. 00:18:51.950 --> 00:18:54.150 Actually, there was nothing of interest. 00:18:54.150 --> 00:18:56.130 It was a false positive. 00:18:56.130 --> 00:18:59.380 OK, try again. 00:18:59.380 --> 00:19:01.440 But yeah, you can download 32 megs. 00:19:01.440 --> 00:19:03.059 It's not the end of the world. 00:19:03.059 --> 00:19:08.310 And if you're only downloading one out of every 100 maybe, if you have a 1% false positive 00:19:08.310 --> 00:19:10.070 rate, it's not too bad. 00:19:10.070 --> 00:19:13.770 That's like 32 megs a day or so. 00:19:13.770 --> 00:19:20.059 But anyway this model is-- and not only that, you can request all the filters, match them, 00:19:20.059 --> 00:19:23.840 and then download from someone else, the full block, right? 00:19:23.840 --> 00:19:27.260 You can request a block, download it from someone else. 00:19:27.260 --> 00:19:30.310 So this full node, they know you requested all the filters. 00:19:30.310 --> 00:19:33.399 They don't see anything else other than that. 00:19:33.399 --> 00:19:38.150 And then another full node just sees you requesting blocks and thinks nothing of it. 00:19:38.150 --> 00:19:39.600 Because that's totally normal. 00:19:39.600 --> 00:19:44.490 This is a lot nicer model for privacy because the full nodes don't learn anything other. 00:19:44.490 --> 00:19:48.600 At most, they learn you downloaded this block and not this other block. 00:19:48.600 --> 00:19:52.240 So maybe you have transactions in this block, but not this one. 00:19:52.240 --> 00:19:57.580 But that's a much bigger sort of needle in a haystack problem, where OK, here are the 00:19:57.580 --> 00:19:58.630 blocks they used. 00:19:58.630 --> 00:20:03.260 What are the commonalities between these sets of blocks they were downloading? 00:20:03.260 --> 00:20:05.179 Possible to maybe weed things out, right? 00:20:05.179 --> 00:20:09.390 If the blocks are small, and there's only a few transactions, and they download the 00:20:09.390 --> 00:20:13.799 entire blockchain from a single node, and that node can track, OK, which blocks are 00:20:13.799 --> 00:20:14.799 being downloaded? 00:20:14.799 --> 00:20:17.510 What are the common transactions or addresses in these? 00:20:17.510 --> 00:20:18.510 It's possible. 00:20:18.510 --> 00:20:24.899 But it's a lot better for privacy than the current model and a lot better for CPU, right? 00:20:24.899 --> 00:20:26.690 So privacy-- great. 00:20:26.690 --> 00:20:28.490 Great improvement. 00:20:28.490 --> 00:20:34.960 The server has much lower CPU, because it can pre-compute all the filters for every 00:20:34.960 --> 00:20:36.060 block, right? 00:20:36.060 --> 00:20:39.770 So as soon as it downloads a block-- or a few seconds later-- there's no rush. 00:20:39.770 --> 00:20:44.010 Compute a Bloom filter for it, store it on disk-- because it doesn't change-- and then 00:20:44.010 --> 00:20:47.590 when anyone requests it, you've already got it on disk. 00:20:47.590 --> 00:20:50.580 So you just read it off the disk, send it over the network, you're done. 00:20:50.580 --> 00:20:55.240 The current model where you don't write these to disk because they're sort of client specific, 00:20:55.240 --> 00:21:00.190 so client connects in, sends you a Bloom filter, you have to keep that in RAM, and then match 00:21:00.190 --> 00:21:03.130 all the things against this specific filter for this specific user. 00:21:03.130 --> 00:21:09.510 Whereas in this model, you make a filter for the block, save it, you're good. 00:21:09.510 --> 00:21:10.510 Yes. 00:21:10.510 --> 00:21:20.060 AUDIENCE: Is the filter for the block [INAUDIBLE] given you're just sending the addresses and 00:21:20.060 --> 00:21:21.060 not [INAUDIBLE]? 00:21:21.060 --> 00:21:22.660 Or is it just less data? 00:21:22.660 --> 00:21:25.340 It's just not the full block, right? 00:21:25.340 --> 00:21:26.340 It's just the-- 00:21:26.340 --> 00:21:27.340 TADGE DRYJA: Yeah. 00:21:27.340 --> 00:21:29.529 So if it were the addresses and the UTXOs, then it would be really big. 00:21:29.529 --> 00:21:34.730 It would be-- oh, maybe like 40% of the whole block size. 00:21:34.730 --> 00:21:38.799 So the idea of the Bloom filter is you squish it down. 00:21:38.799 --> 00:21:43.750 So the Boom filter itself might only be like 20k. 00:21:43.750 --> 00:21:51.809 And so yeah, the basic way a Bloom filter will work is you take sort of a bunch of hashes 00:21:51.809 --> 00:21:55.370 and populate a bit field with them. 00:21:55.370 --> 00:22:00.210 So the thing is, if you keep adding objects to the filter, the filter will eventually 00:22:00.210 --> 00:22:02.510 just be like FFFF. 00:22:02.510 --> 00:22:03.840 And everything will match it. 00:22:03.840 --> 00:22:10.179 So you need to sort of decide how big the filter should be when you start creating and 00:22:10.179 --> 00:22:11.440 adding objects to it. 00:22:11.440 --> 00:22:17.730 So with this, you can get it down to about 20k, and then it'll have a pretty low false 00:22:17.730 --> 00:22:24.450 positive rate, but not tell you exactly what the addresses and UTXOs were. 00:22:24.450 --> 00:22:27.520 So it's a nice trade-off to have. 00:22:27.520 --> 00:22:33.490 Yeah, so I mean, the perfect sort of easiest Bloom filter would be, here's a list of all 00:22:33.490 --> 00:22:39.059 the addresses and all the UTXOs-- basically a block minus the signatures, which is sort 00:22:39.059 --> 00:22:41.570 of what you can get with segwit, where you say, hey. 00:22:41.570 --> 00:22:46.539 In segwit, you can say, hey, give me the block without all the segwit data. 00:22:46.539 --> 00:22:48.370 Because I'm just looking for things. 00:22:48.370 --> 00:22:51.940 I don't want to actually validate the signatures. 00:22:51.940 --> 00:22:57.010 So if you did that with regular-- yeah, it drops it by about 50%. 00:22:57.010 --> 00:23:02.080 But the Bloom filter drops it substantially more. 00:23:02.080 --> 00:23:07.299 So if you did this, it'd be better-- lower CPU for the server. 00:23:07.299 --> 00:23:09.610 It's also harder to lie and omit things. 00:23:09.610 --> 00:23:15.470 So in the current SPV model, if someone is running a client-- it says, hey, here's my 00:23:15.470 --> 00:23:16.690 Bloom filter. 00:23:16.690 --> 00:23:18.260 And the full node responds. 00:23:18.260 --> 00:23:22.710 The full node can easily just omit things. 00:23:22.710 --> 00:23:26.529 So there was a transaction that did hit the Bloom filter and did match. 00:23:26.529 --> 00:23:33.740 And address A was present in a transaction, and the full node just doesn't send it. 00:23:33.740 --> 00:23:39.940 There's really nothing the client can do to detect that kind of thing, which in general, 00:23:39.940 --> 00:23:42.429 it's not the end of the world. 00:23:42.429 --> 00:23:47.440 In normal Bitcoin usage, if you don't hear about a transaction, maybe you'll hear about 00:23:47.440 --> 00:23:49.580 it eventually. 00:23:49.580 --> 00:23:53.019 The worst they can do is sort of lie about you-- they say you didn't get paid, but you 00:23:53.019 --> 00:23:54.059 actually did. 00:23:54.059 --> 00:23:58.630 Not the worst thing in the world, although in Lightning Network, that can change a little 00:23:58.630 --> 00:24:03.840 bit in that you want to know about the transactions that potentially close the channel and immediately 00:24:03.840 --> 00:24:04.880 respond to them. 00:24:04.880 --> 00:24:08.920 So that's more of a security problem with Lightning. 00:24:08.920 --> 00:24:15.850 So with this, it could be harder to omit things, especially if you commit the Bloom filter 00:24:15.850 --> 00:24:17.970 into the Coinbase transaction. 00:24:17.970 --> 00:24:23.141 So if this committed filter becomes like a consensus rule, and you say, OK, everyone 00:24:23.141 --> 00:24:25.519 makes a 20 kilobyte Bloom filter. 00:24:25.519 --> 00:24:30.620 Everyone takes the hash of that and puts it into an op return in the Coinbase transaction 00:24:30.620 --> 00:24:33.000 the way they do a segwit. 00:24:33.000 --> 00:24:34.000 Then it's a consensus rule. 00:24:34.000 --> 00:24:40.289 Then it becomes essentially impossible for the full nodes to lie or omit anything. 00:24:40.289 --> 00:24:44.150 Because you can say, hey, I've got the headers. 00:24:44.150 --> 00:24:47.760 Give me the Coinbase transaction and a Merkle proof for it. 00:24:47.760 --> 00:24:49.090 And now I've got the Coinbase transaction. 00:24:49.090 --> 00:24:56.840 And now, hey, give me that filter that matches this committed hash in the Coinbase transaction. 00:24:56.840 --> 00:25:01.429 So they would have to do valid proof of work to lie or omit. 00:25:01.429 --> 00:25:04.840 Whereas now, they can just easily omit anything they want. 00:25:04.840 --> 00:25:07.990 Oh, lying also. 00:25:07.990 --> 00:25:11.549 So it becomes harder to lie because it's in a block, right? 00:25:11.549 --> 00:25:13.419 So this is operating on the block level. 00:25:13.419 --> 00:25:16.150 The current SPV does not operate on the block level. 00:25:16.150 --> 00:25:21.360 So you can get unconfirmed transactions over the wire that match your filter. 00:25:21.360 --> 00:25:23.890 I think this is a really bad idea. 00:25:23.890 --> 00:25:26.679 I'm not 100% sure why they put it in. 00:25:26.679 --> 00:25:29.309 But there's still people who like it. 00:25:29.309 --> 00:25:34.450 But the whole idea of SPV is that you're verifying the proof of work, right? 00:25:34.450 --> 00:25:37.480 You're verifying that the miners validated this. 00:25:37.480 --> 00:25:41.049 And you think, well, the incentives are such that miners don't want to mine invalid things. 00:25:41.049 --> 00:25:42.230 They won't get paid. 00:25:42.230 --> 00:25:47.139 So if it's in a block, I'll accept it as OK. 00:25:47.139 --> 00:25:51.880 For mempool transactions, if it's just an inv message for a transaction that's not in 00:25:51.880 --> 00:25:54.710 a block yet, there's no SPV security at all. 00:25:54.710 --> 00:26:01.230 And it's trivial to send an invalid transaction to an SPV client, this currently. 00:26:01.230 --> 00:26:05.419 So if you say, hey, here's-- and it's not only is it trivial, but you can also try to 00:26:05.419 --> 00:26:10.020 figure out what their addresses are, and lie to them, and say that, hey, you just got thousands 00:26:10.020 --> 00:26:12.049 of coins. 00:26:12.049 --> 00:26:16.919 So that's the current problem with SPV usage. 00:26:16.919 --> 00:26:20.799 You're basically telling the full load your addresses, and you're accepting transactions 00:26:20.799 --> 00:26:22.150 without proof of work. 00:26:22.150 --> 00:26:28.020 So the full load can say, hey, here's a transaction that sends you 5,000 coins to an address that 00:26:28.020 --> 00:26:29.020 I think you have. 00:26:29.020 --> 00:26:32.120 Because I tried to figure out your address from your filter. 00:26:32.120 --> 00:26:34.889 And it's got an input that doesn't actually exist, right? 00:26:34.889 --> 00:26:37.840 So I'm just saying I'm spending 5,000 coins from here. 00:26:37.840 --> 00:26:40.890 And the from part isn't actually a thing. 00:26:40.890 --> 00:26:43.460 But since you're an SPV node, you don't know that. 00:26:43.460 --> 00:26:45.510 So there's like a-- let's see. 00:26:45.510 --> 00:26:54.410 Lie to SPV is like a branch on Bitcoin [INAUDIBLE]. 00:26:54.410 --> 00:26:59.510 OK, yeah. 00:26:59.510 --> 00:27:04.760 So there's a branch that Peter Todd made called Lie to SPV. 00:27:04.760 --> 00:27:10.590 I don't know. 00:27:10.590 --> 00:27:13.210 Quick and dirty hack to lie to SPV wallets. 00:27:13.210 --> 00:27:18.280 They can't verify amounts, so yeah. 00:27:18.280 --> 00:27:21.490 So you can just sort of detect-- well, if you want to look at it. 00:27:21.490 --> 00:27:24.460 You can detect their addresses. 00:27:24.460 --> 00:27:29.780 And then I think that one just sort of opportunistically, if it finds a match, just multiplies the amount 00:27:29.780 --> 00:27:32.610 that they're receiving by, like, 100. 00:27:32.610 --> 00:27:35.980 And there's no way that they can validate that since it's in mempool. 00:27:35.980 --> 00:27:40.350 So this also makes it on the block level, which is what SPV really should be. 00:27:40.350 --> 00:27:42.700 So that's nice. 00:27:42.700 --> 00:27:46.759 Downsides-- mainly that it's going to be higher network traffic for the client, right? 00:27:46.759 --> 00:27:53.240 So even at low false positive rates, the entire rest of the block is essentially a false positive, 00:27:53.240 --> 00:27:54.240 right? 00:27:54.240 --> 00:27:56.399 So they're like, hey, there's one transaction in this block I want to get. 00:27:56.399 --> 00:27:59.049 I have to download the whole block to get it. 00:27:59.049 --> 00:28:03.750 So yeah, more network traffic for the client, which is a downside, but it helps with privacy. 00:28:03.750 --> 00:28:06.190 So there is current development. 00:28:06.190 --> 00:28:10.120 Lighting Labs-- basically [INAUDIBLE] working on-- it's called neutrino. 00:28:10.120 --> 00:28:12.350 It's a variant of this. 00:28:12.350 --> 00:28:18.889 So, and then hopefully, something like this will eventually get into Bitcoin Core itself 00:28:18.889 --> 00:28:23.890 and replace the current server side Bloom filter code. 00:28:23.890 --> 00:28:27.740 Hopefully, but something to work on. 00:28:27.740 --> 00:28:31.380 Any questions about the Bloom filter stuff? 00:28:31.380 --> 00:28:34.240 Cool, OK. 00:28:34.240 --> 00:28:38.049 OK, other issue, sharding. 00:28:38.049 --> 00:28:41.480 So this is mainly being worked on in the context of Ethereum. 00:28:41.480 --> 00:28:45.960 And it's sort of their sort of holy grail of scalability. 00:28:45.960 --> 00:28:51.610 It's common in the database world, where you've got d data objects, n servers. 00:28:51.610 --> 00:28:56.140 So in the case of Bitcoin or these blockchains, you just store d times n, right? 00:28:56.140 --> 00:28:58.360 Every node stores all data. 00:28:58.360 --> 00:29:03.190 Instead, store something closer to d itself and shard the data over all the servers, so 00:29:03.190 --> 00:29:06.460 that each server holds like d divided by n, right? 00:29:06.460 --> 00:29:11.130 So if you have 10 servers and a gigabyte, have them each store 100 megs. 00:29:11.130 --> 00:29:12.870 And then you still got all the data. 00:29:12.870 --> 00:29:18.080 Of course, if they actually store exactly d over n-- and you need to coordinate it so 00:29:18.080 --> 00:29:24.440 they all store their own little shard-- and then if any single node goes down, well, you're 00:29:24.440 --> 00:29:25.440 stuck. 00:29:25.440 --> 00:29:27.799 So this is sort of the limit. 00:29:27.799 --> 00:29:33.299 And there's no redundancy there. 00:29:33.299 --> 00:29:35.240 But you can have different redundancy ratings. 00:29:35.240 --> 00:29:38.740 So you could say, OK, well, any-- you could have [INAUDIBLE] you're coding. 00:29:38.740 --> 00:29:43.059 So if any five nodes or any 20% of the nodes disappear, we're still OK. 00:29:43.059 --> 00:29:48.409 So in the database world, this is a well studied problem. 00:29:48.409 --> 00:29:53.700 But in the context of Bitcoin, Ethereum, and blockchains, it's more difficult. 00:29:53.700 --> 00:29:57.780 It's difficult here because you're in this adversarial environment, where people are 00:29:57.780 --> 00:30:01.590 trying to break your system at all times. 00:30:01.590 --> 00:30:06.470 People want to create transactions that are invalid. 00:30:06.470 --> 00:30:08.649 Because that can be worth a lot of money. 00:30:08.649 --> 00:30:15.880 I can say, hey, you don't know about this shard, but I'm telling you that on this shard, 00:30:15.880 --> 00:30:17.020 I have a lot of money. 00:30:17.020 --> 00:30:21.169 And I'm sending it to you, so give me your house or whatever. 00:30:21.169 --> 00:30:28.679 So the idea is to split a single UTXO set into multiple smaller sets, and that part 00:30:28.679 --> 00:30:29.679 is OK. 00:30:29.679 --> 00:30:31.889 But you need communication between the shards, right? 00:30:31.889 --> 00:30:38.100 So you could say, OK, well, making sort of a bunch of different UTXO sets, each node 00:30:38.100 --> 00:30:41.150 can choose their own UTXO set that they're keeping track of. 00:30:41.150 --> 00:30:45.759 And then you have some kind of merge mining between the UTXO sets, but you need swaps 00:30:45.759 --> 00:30:46.820 between the shards. 00:30:46.820 --> 00:30:51.650 It's kind of an interesting thing to think of. 00:30:51.650 --> 00:30:54.690 We already have multiple UTXO sets, right? 00:30:54.690 --> 00:31:02.360 So as of this morning, coinmarketcap.com tracks 1,614 different currencies, 10,000 markets. 00:31:02.360 --> 00:31:05.960 There's supposedly $434 billion going around. 00:31:05.960 --> 00:31:10.200 Is this sharding, right? 00:31:10.200 --> 00:31:17.790 And it's sort of a joke, but in a real sense, it has taken scalability pressure off of Bitcoin 00:31:17.790 --> 00:31:23.009 and off of any individual currency because there's so many of them. 00:31:23.009 --> 00:31:26.340 So if you didn't have Dogecoin, maybe there will be more Bitcoin transactions. 00:31:26.340 --> 00:31:30.880 AUDIENCE: And how does this play into Bitcoins that are just running on Ether? 00:31:30.880 --> 00:31:37.570 TADGE DRYJA: Right, so in the case of ERC-20 or ERC-721, it actually is worse. 00:31:37.570 --> 00:31:46.950 Because now you've got sort of multiple UTXO sets all being managed by a single UTXO set. 00:31:46.950 --> 00:31:51.210 So if you want to keep track of how many-- I don't know. 00:31:51.210 --> 00:31:53.159 What's an ECR-20 token? 00:31:53.159 --> 00:31:58.379 If you want to keep track of how many Pied Piper coins there are, you need to download 00:31:58.379 --> 00:32:00.879 the entire Ethereum blockchain. 00:32:00.879 --> 00:32:05.490 So that's sort of the opposite of sharding in that now any single UTXO set you want to 00:32:05.490 --> 00:32:08.040 keep track of, you need to keep track of all of them. 00:32:08.040 --> 00:32:12.649 However, in this case, if I want to keep track of my Bitcoin UTXO set, I don't need to download 00:32:12.649 --> 00:32:13.649 Dogecoin. 00:32:13.649 --> 00:32:14.649 So that's great. 00:32:14.649 --> 00:32:19.500 And if people want to swap between Dogecoin and Bitcoin, they can do so-- well, Dogecoin 00:32:19.500 --> 00:32:21.009 doesn't have segwit support, right? 00:32:21.009 --> 00:32:22.870 So it's a little harder. 00:32:22.870 --> 00:32:28.620 But Vertcoin, Litecoin-- a lot of different coins have fairly easy swaps. 00:32:28.620 --> 00:32:30.370 But it's more than just swaps. 00:32:30.370 --> 00:32:35.559 We need actual fungibility between the shards. 00:32:35.559 --> 00:32:42.049 Because if I can say, oh, I'm going to use Litecoin, and I can just swap to Bitcoin whenever 00:32:42.049 --> 00:32:44.740 I need to pay someone who accepts Bitcoin, right, maybe. 00:32:44.740 --> 00:32:50.250 But maybe Litecoin drops in value 20% with respect to Bitcoin. 00:32:50.250 --> 00:32:53.000 And then I tried to pay. 00:32:53.000 --> 00:32:57.289 And this is sort of getting ahead of the real use cases of these things. 00:32:57.289 --> 00:33:04.880 Because well, Bitcoin also drops 20% randomly against whatever asset you're trying to buy. 00:33:04.880 --> 00:33:09.720 And so but Bitcoin does tend to be a bit more stable than most of the smaller market cap 00:33:09.720 --> 00:33:10.720 coins. 00:33:10.720 --> 00:33:15.789 I mean, you can sort of think that generally, if you have a bigger market capitalization, 00:33:15.789 --> 00:33:19.799 you're going to tend to be less volatile. 00:33:19.799 --> 00:33:24.799 And we've seen that in Bitcoin, where it still seems ridiculously volatile, right? 00:33:24.799 --> 00:33:27.269 It's gone down 50% since January. 00:33:27.269 --> 00:33:32.419 And most currencies in the developed world don't do that. 00:33:32.419 --> 00:33:37.200 But if you actually compare it to in 2011, it dropped, like, 95% in a month or two. 00:33:37.200 --> 00:33:38.200 Yeah. 00:33:38.200 --> 00:33:43.039 AUDIENCE: It's more likely to be liquid supply [INAUDIBLE] 00:33:43.039 --> 00:33:50.279 TADGE DRYJA: Yeah, so sometimes, there is a currency that has these really inflated 00:33:50.279 --> 00:33:52.379 market caps. 00:33:52.379 --> 00:33:57.990 So you'll see one where someone makes a coin and says, OK, I'm making a million coins. 00:33:57.990 --> 00:34:00.830 And I'll sell you one for $100. 00:34:00.830 --> 00:34:05.580 And really, I still have all of the coins, and one other person has one of them. 00:34:05.580 --> 00:34:09.320 But we can sort of do the math and get a market cap of $100 million that way. 00:34:09.320 --> 00:34:12.360 So a lot of the coins do that to sort of inflate. 00:34:12.360 --> 00:34:16.670 Because a coin market cap is literally a ranking. 00:34:16.670 --> 00:34:20.370 And it even says rank. 00:34:20.370 --> 00:34:24.489 So if you click EOS, it'll say rank. 00:34:24.489 --> 00:34:25.989 Where does it say there? 00:34:25.989 --> 00:34:26.989 Yeah, rank five. 00:34:26.989 --> 00:34:30.409 So it's the fifth best, presumably. 00:34:30.409 --> 00:34:35.380 And yeah, to what extent-- how many actual people hold these things? 00:34:35.380 --> 00:34:41.389 They just sort of made them up. 00:34:41.389 --> 00:34:43.492 But there's all sorts of problems with this. 00:34:43.492 --> 00:34:47.840 But the idea is, if you really want sharding, you want the swaps between the shards to not 00:34:47.840 --> 00:34:52.429 really have counter parties and to maintain the same value. 00:34:52.429 --> 00:34:56.730 You want fungibility between the shards, so that you can quickly and easily say, OK, well, 00:34:56.730 --> 00:35:01.620 I've got something on shard A. I'm going to pay someone who's using shard B. And I don't 00:35:01.620 --> 00:35:02.620 want any friction. 00:35:02.620 --> 00:35:06.830 I don't want any exchange between there. 00:35:06.830 --> 00:35:08.810 So this is hard. 00:35:08.810 --> 00:35:12.040 There's a lot of cool research going on here. 00:35:12.040 --> 00:35:14.790 And if it works, it's a real scalability improvement. 00:35:14.790 --> 00:35:17.110 This is sort of the holy grail. 00:35:17.110 --> 00:35:21.330 I don't really see much in-- in Bitcoin, they're sort of like side chains. 00:35:21.330 --> 00:35:24.890 But those weren't really talked about as a scalability improvement. 00:35:24.890 --> 00:35:28.950 And it's mostly the Ethereum crowd that are like, this is our real sort of holy grail 00:35:28.950 --> 00:35:30.740 for scalability. 00:35:30.740 --> 00:35:31.760 So it's interesting to look at. 00:35:31.760 --> 00:35:32.760 I haven't kept up. 00:35:32.760 --> 00:35:36.500 I've read a little bit about their most recent sharding ideas. 00:35:36.500 --> 00:35:38.540 So it's cool if it works. 00:35:38.540 --> 00:35:41.600 But there's a lot of sort of different assumptions that go in. 00:35:41.600 --> 00:35:42.600 Yeah. 00:35:42.600 --> 00:35:47.360 AUDIENCE: What are some of the current plans to do sharding? 00:35:47.360 --> 00:35:49.680 TADGE DRYJA: They sort of like-- a lot of them hinge on fraud proofs. 00:35:49.680 --> 00:35:54.100 So the idea is, you've got, say, five different chains going along. 00:35:54.100 --> 00:35:56.550 And you don't validate the other four. 00:35:56.550 --> 00:35:58.560 You say I'm going to only validate this one. 00:35:58.560 --> 00:36:00.380 There's four others going on. 00:36:00.380 --> 00:36:05.030 And if, in my chain, something bad happens, like a transaction with an invalid signature 00:36:05.030 --> 00:36:11.370 gets confirmed, or transaction has more coins coming out than going in-- something like 00:36:11.370 --> 00:36:14.440 that-- you provide a small fraud proof. 00:36:14.440 --> 00:36:18.420 You provide a proof that says, OK, you don't need to know everything that's going on in 00:36:18.420 --> 00:36:19.420 this chain. 00:36:19.420 --> 00:36:25.630 But I'll provide enough data to convince you that this specific transaction is broken. 00:36:25.630 --> 00:36:30.000 And then I try to broadcast to the other people in those other four subchains. 00:36:30.000 --> 00:36:33.010 And then they know, OK, something's going on wrong here. 00:36:33.010 --> 00:36:37.680 Let's freeze-- let's not accept any cross shard swaps from that one. 00:36:37.680 --> 00:36:42.170 And then the other-- this chain will have to reorg. 00:36:42.170 --> 00:36:45.010 So the idea is as long as you have-- and it sort of makes sense. 00:36:45.010 --> 00:36:49.660 As long as you have some number of people checking it that can then broadcast it between 00:36:49.660 --> 00:36:52.010 the different shards, you can assume that they're doing OK. 00:36:52.010 --> 00:36:53.010 Yeah. 00:36:53.010 --> 00:36:54.010 AUDIENCE: Problems temporarily arise from [INAUDIBLE]. 00:36:54.010 --> 00:37:01.430 So you'll have a situation where [INAUDIBLE]. 00:37:01.430 --> 00:37:19.481 And then you wait two days, and then the transaction [INAUDIBLE] which relies on data from two 00:37:19.481 --> 00:37:20.481 years ago for that shard. 00:37:20.481 --> 00:37:21.481 All of those shards have disappeared. 00:37:21.481 --> 00:37:22.481 So you have a choice. 00:37:22.481 --> 00:37:23.481 Do you do it to your real or just accept that that money is gone? 00:37:23.481 --> 00:37:24.481 TADGE DRYJA: Yeah. 00:37:24.481 --> 00:37:25.481 Or just accept that, oh, well, it's two years ago. 00:37:25.481 --> 00:37:26.481 So I'll assume it's OK. 00:37:26.481 --> 00:37:27.481 AUDIENCE: Yeah. 00:37:27.481 --> 00:37:28.481 TADGE DRYJA: Yeah. 00:37:28.481 --> 00:37:29.481 Which is probably more dangerous. 00:37:29.481 --> 00:37:30.481 Yeah, so sort of availability and liveness are other issues here, where if in Bitcoin 00:37:30.481 --> 00:37:33.410 or Ethereum-- well, it's more of an issue in Ethereum. 00:37:33.410 --> 00:37:36.400 In Bitcoin, there's a lot of copies of the full set. 00:37:36.400 --> 00:37:41.270 So if you're not sure about something, you can pretty easily get the entire blockchain, 00:37:41.270 --> 00:37:44.100 even though it's like 180 gigs, and go through it. 00:37:44.100 --> 00:37:46.010 There's so many copies of it out there. 00:37:46.010 --> 00:37:48.270 In Ethereum, a little bit less so. 00:37:48.270 --> 00:37:49.950 Well, there's more full nodes. 00:37:49.950 --> 00:37:51.820 But full is sort of redefined. 00:37:51.820 --> 00:37:53.870 And so it may be harder to get the full thing. 00:37:53.870 --> 00:37:59.780 And in the case of sharding, if you divide it too finally, it may be that you lose data, 00:37:59.780 --> 00:38:01.770 and no one has it. 00:38:01.770 --> 00:38:03.690 And then you're in real trouble. 00:38:03.690 --> 00:38:07.020 OK, so that's sharding. 00:38:07.020 --> 00:38:10.630 OK, accumulators-- this is something I'm actually looking at. 00:38:10.630 --> 00:38:17.520 I'm not going to go into the details of what I'm working on, but accumulators in general. 00:38:17.520 --> 00:38:22.950 This is a cool-- so accumulators, as I will describe, are nothing new. 00:38:22.950 --> 00:38:27.150 But if you read the papers-- so one of the first papers was called One Way Accumulators 00:38:27.150 --> 00:38:28.400 in, like, '93. 00:38:28.400 --> 00:38:31.560 And if you read the paper, a lot of the words jump out. 00:38:31.560 --> 00:38:33.530 It's like, hey, this might be useful for Bitcoin. 00:38:33.530 --> 00:38:38.500 It's like, set membership, and timestamping, and signature aggregate. 00:38:38.500 --> 00:38:41.390 It's got a lot of stuff in there that's like, hey, this could be useful. 00:38:41.390 --> 00:38:46.900 So an accumulator is basically a cryptographic set. 00:38:46.900 --> 00:38:51.870 And there's some set operations that you can do and then provide proofs. 00:38:51.870 --> 00:38:54.930 So, the simplest-- well, not even the simplest. 00:38:54.930 --> 00:38:57.320 The simplest would just be add and prove. 00:38:57.320 --> 00:38:58.920 But sometimes you can add. 00:38:58.920 --> 00:38:59.940 Sometimes you can remove. 00:38:59.940 --> 00:39:01.420 Sometimes you can prove something's in there. 00:39:01.420 --> 00:39:04.510 Sometimes you can prove something's not in there. 00:39:04.510 --> 00:39:06.490 And if you can do all four, that's even better. 00:39:06.490 --> 00:39:09.460 So the idea is, you take an accumulator. 00:39:09.460 --> 00:39:11.150 And you add an object to it. 00:39:11.150 --> 00:39:15.500 And in general, objects are going to be strings of bytes or just numbers, right? 00:39:15.500 --> 00:39:16.990 And then it spits out a new accumulator. 00:39:16.990 --> 00:39:20.690 Essentially, it modifies the accumulator in place. 00:39:20.690 --> 00:39:23.210 So if you delete-- you say OK, I've got an accumulator. 00:39:23.210 --> 00:39:24.990 And I want to delete this object. 00:39:24.990 --> 00:39:29.170 Well, it'll modify in place and return a different accumulator. 00:39:29.170 --> 00:39:33.320 And then maybe I want to prove that this object is in this accumulator. 00:39:33.320 --> 00:39:34.790 And it will return a Boolean. 00:39:34.790 --> 00:39:36.950 Like, yep, that worked, or no, it didn't. 00:39:36.950 --> 00:39:43.340 So the simplest example, which I think is kind of fun, composite numbers. 00:39:43.340 --> 00:39:47.110 So accumulate prime numbers. 00:39:47.110 --> 00:39:48.790 So to add, multiply. 00:39:48.790 --> 00:39:50.450 To delete, divide. 00:39:50.450 --> 00:39:55.510 So really, if you're going to do this, you start with 1. 00:39:55.510 --> 00:40:00.300 1 is not a prime, I guess, but whatever. 00:40:00.300 --> 00:40:02.440 So let's say you've got-- so yeah. 00:40:02.440 --> 00:40:03.750 1 is not a prime, so that works. 00:40:03.750 --> 00:40:07.650 So you cannot prove any prime exists within that accumulator. 00:40:07.650 --> 00:40:11.120 Anyway, but let's say you start with 1, and then you added 3 to the accumulator. 00:40:11.120 --> 00:40:12.900 So you multiplied by 3, and you get 3. 00:40:12.900 --> 00:40:15.210 Now I want to add the number 5 to the accumulator. 00:40:15.210 --> 00:40:16.620 So I multiply by 5. 00:40:16.620 --> 00:40:17.940 I get 15. 00:40:17.940 --> 00:40:21.740 And now I want to add 7 to this accumulator. 00:40:21.740 --> 00:40:23.860 So I've got my accumulator, which is 15. 00:40:23.860 --> 00:40:27.250 I add the number 7 into it, and I get 105, right? 00:40:27.250 --> 00:40:28.910 I just multiply by 7. 00:40:28.910 --> 00:40:31.070 I get 105. 00:40:31.070 --> 00:40:33.940 Wait, is it called fundamental theorem of arithmetic? 00:40:33.940 --> 00:40:36.700 I think that's what it's called, where everything's a product of primes. 00:40:36.700 --> 00:40:40.010 It's got some cool name. 00:40:40.010 --> 00:40:43.310 So everything's a product of primes. 00:40:43.310 --> 00:40:45.060 And everything has a unique factorization. 00:40:45.060 --> 00:40:48.980 So 105 is 3 times 5 times 7, right? 00:40:48.980 --> 00:40:54.360 There's no other ways around it. 00:40:54.360 --> 00:40:59.280 And if you want to delete, you can say, OK, well, I'm going to delete the number 5 from 00:40:59.280 --> 00:41:00.280 this accumulator. 00:41:00.280 --> 00:41:01.280 Just divide. 00:41:01.280 --> 00:41:02.280 Now I get 21. 00:41:02.280 --> 00:41:04.820 And then I want to prove 7 is in there. 00:41:04.820 --> 00:41:07.250 So I can say, hey, 7 is in this accumulator. 00:41:07.250 --> 00:41:09.590 It was added, but not deleted. 00:41:09.590 --> 00:41:10.640 And I can do that, right? 00:41:10.640 --> 00:41:13.300 I tried to divide 21 by 7, and it worked. 00:41:13.300 --> 00:41:15.810 I want to divide, and I want to make sure there's no remainder. 00:41:15.810 --> 00:41:17.380 I want to see that it divides evenly. 00:41:17.380 --> 00:41:19.410 So I get a true. 00:41:19.410 --> 00:41:22.550 Yep, if I divide 21 by 7, I get 3. 00:41:22.550 --> 00:41:24.550 3 is a natural number. 00:41:24.550 --> 00:41:25.550 It works. 00:41:25.550 --> 00:41:29.600 So this is kind of cool. 00:41:29.600 --> 00:41:32.480 It is not really [INAUDIBLE]. 00:41:32.480 --> 00:41:35.290 Oh, but this works even if you do modulo. 00:41:35.290 --> 00:41:40.970 So you could do modulo some big prime and have just formality based accumulators. 00:41:40.970 --> 00:41:44.260 So anyway, you get the idea, right? 00:41:44.260 --> 00:41:48.660 I think in this case, you can also prove things are not in there. 00:41:48.660 --> 00:41:49.960 But this is limited to prime numbers. 00:41:49.960 --> 00:41:53.150 Anyway, but the idea is, keep adding things to it, removing things from it, and proving 00:41:53.150 --> 00:41:55.690 that things are in it. 00:41:55.690 --> 00:41:59.790 So there's RSA accumulators, which are some of the most well-known. 00:41:59.790 --> 00:42:05.260 And that's you've got some RSA number, which is basically a product of two large primes. 00:42:05.260 --> 00:42:09.210 And the accumulator itself is of constant size. 00:42:09.210 --> 00:42:11.440 And the proofs are also of constant size. 00:42:11.440 --> 00:42:13.290 So we call this a proof. 00:42:13.290 --> 00:42:17.770 You're just giving the number itself in this case. 00:42:17.770 --> 00:42:24.170 So it's efficient, but the RSA accumulators use trusted setup. 00:42:24.170 --> 00:42:29.610 So the idea is you need to find some composite number n, which is p times q, where p and 00:42:29.610 --> 00:42:33.250 q are prime, where nobody knows p and q. 00:42:33.250 --> 00:42:37.220 Or nobody knows or you trust that the person who does know p and q not to screw around 00:42:37.220 --> 00:42:38.990 with the accumulator. 00:42:38.990 --> 00:42:43.990 Because the person who-- if knowledge of p-- I think it's actually knowledge of p or q-- 00:42:43.990 --> 00:42:50.050 will let you create proofs that, hey, this object is in the accumulator when really, 00:42:50.050 --> 00:42:52.319 it isn't. 00:42:52.319 --> 00:42:55.500 So that's not so much fun for Bitcoin. 00:42:55.500 --> 00:43:00.080 If you need trusted setup, people don't really like that. 00:43:00.080 --> 00:43:01.870 There's all these other accumulator assay ideas. 00:43:01.870 --> 00:43:03.780 Some are one way where you can't delete. 00:43:03.780 --> 00:43:08.380 You can add things to the accumulator, but there's no way to remove it. 00:43:08.380 --> 00:43:12.710 Sometimes you can batch things, where, OK, if I want-- so you can see in the composite 00:43:12.710 --> 00:43:14.830 number accumulator, you could batch things. 00:43:14.830 --> 00:43:20.490 Where if I add 105 to the accumulator, I'm performing one operation that essentially 00:43:20.490 --> 00:43:22.810 adds three objects, right? 00:43:22.810 --> 00:43:25.180 3, 5, and 7. 00:43:25.180 --> 00:43:27.420 Some can be batched like that, some cannot. 00:43:27.420 --> 00:43:29.530 Some have trusted setup, some don't. 00:43:29.530 --> 00:43:33.570 So there's different tradeoffs for all these different use cases. 00:43:33.570 --> 00:43:38.740 And in the case of Bitcoin, the idea of an accumulator would be put the UTXO set in it, 00:43:38.740 --> 00:43:40.590 or put the STXO. 00:43:40.590 --> 00:43:44.280 Like, spent the transaction outputs into it. 00:43:44.280 --> 00:43:49.650 And then prove, in the case of UTXOs, prove that it's in the accumulator. 00:43:49.650 --> 00:43:53.310 Or in the case of STXOs, prove that it's no longer in the accumulator. 00:43:53.310 --> 00:43:54.650 Right? 00:43:54.650 --> 00:43:58.750 Provided proof of non-inclusion, that, hey, it's not in this STXO set. 00:43:58.750 --> 00:44:03.230 So, well, with the STXO inclusion-- so let's say you did it that way. 00:44:03.230 --> 00:44:10.740 You'd have headers, and then you've got this STXO accumulator. 00:44:10.740 --> 00:44:17.950 And what you can do there is say I've got a transaction. 00:44:17.950 --> 00:44:19.470 It's got some inputs. 00:44:19.470 --> 00:44:23.560 I prove that this input exists in the headers, right? 00:44:23.560 --> 00:44:25.650 I provide you an SPV proof. 00:44:25.650 --> 00:44:29.280 So I say, OK, at some point, this was created, right? 00:44:29.280 --> 00:44:30.570 This input. 00:44:30.570 --> 00:44:33.620 Maybe a year ago, I showed you, OK, there is this header. 00:44:33.620 --> 00:44:35.830 Here's a Merkle proof that this was in a block. 00:44:35.830 --> 00:44:37.860 So this exists. 00:44:37.860 --> 00:44:41.490 Then I also prove somehow that it doesn't exist in here, right? 00:44:41.490 --> 00:44:43.930 It exists, but it was never spent. 00:44:43.930 --> 00:44:48.070 So now you can accept that, oh, OK, he gave me an SPV proof. 00:44:48.070 --> 00:44:51.050 He gave me a non-inclusion to the STXO set proof. 00:44:51.050 --> 00:44:58.190 So I know this transaction, this input still exists and can be spent. 00:44:58.190 --> 00:45:03.600 So what this would do, if you get it working, you don't need to store the UTXOs anymore. 00:45:03.600 --> 00:45:08.080 You just store the accumulator, and then everyone provides proofs that, hey, I've got these 00:45:08.080 --> 00:45:09.470 coins. 00:45:09.470 --> 00:45:14.180 But so right now, if you store the UTXO set, it's a couple of gigabytes-- 3 or 4 gigs. 00:45:14.180 --> 00:45:22.000 And when someone sends a transaction, you just look in your UTXO set, right? 00:45:22.000 --> 00:45:23.190 So you see this input. 00:45:23.190 --> 00:45:25.850 You say, hey, does that exist in my UTXO set? 00:45:25.850 --> 00:45:27.080 OK, it does. 00:45:27.080 --> 00:45:28.080 Cool. 00:45:28.080 --> 00:45:31.230 We'll now verify the signature, verify everything else about the transaction. 00:45:31.230 --> 00:45:34.390 If it doesn't exist in my UTXO set, I'm like, hey, you're trying to spend something that 00:45:34.390 --> 00:45:37.220 isn't there. 00:45:37.220 --> 00:45:42.360 So what would be cool is if you got rid of the UTXO set and only used an accumulator. 00:45:42.360 --> 00:45:45.200 Because the accumulators are constant size. 00:45:45.200 --> 00:45:51.850 So even if the UTXO set is 20 gigabytes, well, I've got this 10 kilobyte accumulator thing 00:45:51.850 --> 00:45:53.230 on my hard drive. 00:45:53.230 --> 00:45:55.350 And I just modify that in place. 00:45:55.350 --> 00:45:59.090 And now I don't need to store a bazillion gigabytes. 00:45:59.090 --> 00:46:04.120 And I basically can have the same security as a full node. 00:46:04.120 --> 00:46:07.200 I'm still a full node, but I just don't store the UTXO set. 00:46:07.200 --> 00:46:13.950 I just require either SPV proofs or STXOs-- different proofs from the people trying to 00:46:13.950 --> 00:46:15.790 spend the transactions. 00:46:15.790 --> 00:46:17.220 So this is really cool. 00:46:17.220 --> 00:46:19.430 Constant size, the proofs are small. 00:46:19.430 --> 00:46:21.460 Sometimes the proofs are really small. 00:46:21.460 --> 00:46:23.400 And then the wallets track the proofs. 00:46:23.400 --> 00:46:25.360 So some questions. 00:46:25.360 --> 00:46:30.050 Proofs can be like constant size, or sometimes they're log n. 00:46:30.050 --> 00:46:35.470 If the proofs are o of n, then it's not useful, right? 00:46:35.470 --> 00:46:37.590 Because you might as well store the UTXO set at that point. 00:46:37.590 --> 00:46:38.940 Also, what is n? 00:46:38.940 --> 00:46:41.870 Is it the number of transactions, blocks? 00:46:41.870 --> 00:46:43.530 Can you aggregate these operations? 00:46:43.530 --> 00:46:46.930 So there's a bunch of questions there. 00:46:46.930 --> 00:46:52.170 Another really big problem-- so I was talking to Peter Wool, who's sort of one of the premier 00:46:52.170 --> 00:46:53.910 researchers on Bitcoin. 00:46:53.910 --> 00:46:58.390 He had been talking to people at Stanford about a lattice based accumulator that did 00:46:58.390 --> 00:46:59.960 not need trusted setup. 00:46:59.960 --> 00:47:03.570 And he was very excited about it because it was like, hey, there's no trusted setup. 00:47:03.570 --> 00:47:05.480 You have constant size proofs. 00:47:05.480 --> 00:47:07.360 The accumulator itself is pretty small. 00:47:07.360 --> 00:47:09.900 CPU wise, it seems doable. 00:47:09.900 --> 00:47:17.300 The thing that sort of killed it was you couldn't batch operations that accumulated. 00:47:17.300 --> 00:47:20.470 And the other thing is we need some kind of bridge node. 00:47:20.470 --> 00:47:24.040 So the idea is, normal transactions, right? 00:47:24.040 --> 00:47:26.260 They just say, here's my input. 00:47:26.260 --> 00:47:27.700 I've got a couple inputs. 00:47:27.700 --> 00:47:30.370 I've got a couple outputs. 00:47:30.370 --> 00:47:32.180 I don't provide any proofs or anything. 00:47:32.180 --> 00:47:34.670 I just point to what I'm spending. 00:47:34.670 --> 00:47:38.170 And you look in your UTXO set and see if it's there. 00:47:38.170 --> 00:47:42.040 With this new idea with accumulators, you're going to have to stick proofs on. 00:47:42.040 --> 00:47:47.150 So really, it's an extra data structure, probably per input. 00:47:47.150 --> 00:47:50.940 So you say, hey, I'm a node. 00:47:50.940 --> 00:47:52.130 I run an accumulator. 00:47:52.130 --> 00:47:53.640 I don't keep the whole set. 00:47:53.640 --> 00:47:58.650 So for all your inputs, please provide proofs. 00:47:58.650 --> 00:48:05.610 And wallets can maintain these proofs and attach them to their transactions. 00:48:05.610 --> 00:48:07.280 And then the nodes will verify them. 00:48:07.280 --> 00:48:11.690 However, right now, most wallets don't have these proofs-- have no idea that this is a 00:48:11.690 --> 00:48:12.690 thing, right? 00:48:12.690 --> 00:48:17.330 So if you're the first node to do this and say, hey, I'm getting rid of my UTXO set. 00:48:17.330 --> 00:48:22.570 I'm only going to verify proofs that these UTXOs exist. 00:48:22.570 --> 00:48:24.910 Most of the wallets won't provide those proofs. 00:48:24.910 --> 00:48:28.760 And so as a new node, say, hey, I got rid of my UTXO set, but no one's giving you proofs. 00:48:28.760 --> 00:48:29.870 OK, I'm just stuck, right? 00:48:29.870 --> 00:48:31.250 I see a block come out. 00:48:31.250 --> 00:48:32.250 I can't validate it. 00:48:32.250 --> 00:48:35.710 So you're going to need some kind of transition, right? 00:48:35.710 --> 00:48:40.530 If you started from scratch and say, OK, the responsibility of every wallet is not just 00:48:40.530 --> 00:48:45.890 keep your private keys and keep track of what your UTXO is, it's also to keep track of a 00:48:45.890 --> 00:48:46.890 proof. 00:48:46.890 --> 00:48:49.560 So that when you want to spend it, you give it to someone else. 00:48:49.560 --> 00:48:52.380 If you started that way, great. 00:48:52.380 --> 00:48:56.350 But if you want to transition, what you're kind of going to need is a bridge node. 00:48:56.350 --> 00:49:05.460 And the idea of a bridge node is you've got-- so here's an accumulator node, where it requires 00:49:05.460 --> 00:49:06.660 proofs. 00:49:06.660 --> 00:49:10.760 Here's a old node that just has regular UTXOs. 00:49:10.760 --> 00:49:17.460 So when the old node sends a transaction, this gives TX proof, right? 00:49:17.460 --> 00:49:23.070 So this basically has proofs for everything, like all proofs. 00:49:23.070 --> 00:49:28.880 So the bridge node can provide proofs. 00:49:28.880 --> 00:49:30.620 You'll need one bridge node, right? 00:49:30.620 --> 00:49:36.560 So if these accumulator nodes talk to each other, they can send the proofs along to each 00:49:36.560 --> 00:49:37.980 other and stuff like that. 00:49:37.980 --> 00:49:42.330 The old nodes cannot send proofs because they're not aware of it in their software. 00:49:42.330 --> 00:49:45.890 But if you have the new nodes, you can say, OK, well, when I receive a transaction, I 00:49:45.890 --> 00:49:46.970 verify the proofs. 00:49:46.970 --> 00:49:52.230 I also keep the proofs and give them to other peers who want to verify them. 00:49:52.230 --> 00:49:55.090 But you need some kind of bridge between these two networks. 00:49:55.090 --> 00:49:56.090 Yeah. 00:49:56.090 --> 00:50:00.070 AUDIENCE: You would just keep that running until everyone switches? 00:50:00.070 --> 00:50:03.300 TADGE DRYJA: Probably forever. 00:50:03.300 --> 00:50:04.300 So yeah. 00:50:04.300 --> 00:50:08.270 So the issue with the bridge node is like, well, if you're an old wallet, you don't to 00:50:08.270 --> 00:50:10.490 keep track of these proofs. 00:50:10.490 --> 00:50:14.100 So, how much of a problem is this? 00:50:14.100 --> 00:50:21.510 And the lattice based accumulator, that was sort of what killed it, was that you couldn't 00:50:21.510 --> 00:50:22.700 batch operations. 00:50:22.700 --> 00:50:27.600 Sorry, and the proofs changed. 00:50:27.600 --> 00:50:34.830 That's not the case with the sort of silly prime number accumulator that I showed. 00:50:34.830 --> 00:50:39.720 But in the lattice space one, the proofs changed every time an accumulator operation happened. 00:50:39.720 --> 00:50:43.370 So every time an ad happened, your proof had to change. 00:50:43.370 --> 00:50:47.310 So you didn't just need to add something and modify the accumulator in place. 00:50:47.310 --> 00:50:50.730 You had to modify your proofs in place as well. 00:50:50.730 --> 00:50:56.830 And so if you're a wallet, and you've got three UTXOs, that meant that every block, 00:50:56.830 --> 00:50:59.750 you'd have to do a couple thousand operations, right? 00:50:59.750 --> 00:51:04.690 Because every block, you're going to have a few thousand adds and a few thousand deletes 00:51:04.690 --> 00:51:06.160 to this accumulator. 00:51:06.160 --> 00:51:09.740 Every time one of those happened, you'd have to modify your proof for each of your three 00:51:09.740 --> 00:51:10.980 UTXOs. 00:51:10.980 --> 00:51:15.010 So, a little ugly but doable, because you've got three UTXOs. 00:51:15.010 --> 00:51:19.930 You basically 3x the number of operations, set operations in the block. 00:51:19.930 --> 00:51:26.960 The bridge node, on the other hand, has to keep track of something like 70 million UTXOs. 00:51:26.960 --> 00:51:27.960 Right? 00:51:27.960 --> 00:51:29.380 That's about how many there are right now. 00:51:29.380 --> 00:51:36.020 And so since there's no way to batch it, that means you're going to have maybe 10k times 00:51:36.020 --> 00:51:38.110 70 million every block. 00:51:38.110 --> 00:51:43.730 It's just not going to happen. 00:51:43.730 --> 00:51:46.610 And then it's like, well, maybe you can sort of try to shard the bridge nodes. 00:51:46.610 --> 00:51:50.300 And this bridge node only keeps track of this portion of the set. 00:51:50.300 --> 00:51:52.860 But it just looked really daunting. 00:51:52.860 --> 00:51:56.580 And that was why he was sort of like, yeah, I don't think this lattice-- I think it's 00:51:56.580 --> 00:52:02.410 really key that either there's some kind of batching operation, where we can consolidate 00:52:02.410 --> 00:52:07.840 all the operations within a single block to one set operation for the accumulator, or 00:52:07.840 --> 00:52:13.840 try to make it so that the proofs don't have to be updated or something like that. 00:52:13.840 --> 00:52:19.510 So this is still an unsolved problem, although I'm working on a fun way that I think might 00:52:19.510 --> 00:52:21.950 work to do this. 00:52:21.950 --> 00:52:23.560 And I don't want to-- because this is videotaped. 00:52:23.560 --> 00:52:24.970 It's going on the internet and stuff. 00:52:24.970 --> 00:52:26.260 I don't want to talk about it. 00:52:26.260 --> 00:52:32.270 But if you have questions, we can talk about it at office hours or something. 00:52:32.270 --> 00:52:37.290 So if it works, it'll be cool, although in some cases, it might-- so in the case of that 00:52:37.290 --> 00:52:40.860 bridge node, it was the bridge node that really killed it. 00:52:40.860 --> 00:52:45.240 Because it was just like, oh, you're going to have to do billions of operations per block. 00:52:45.240 --> 00:52:50.260 But in other cases, it's like, well, you can have accumulators that seem good, but aren't 00:52:50.260 --> 00:52:52.060 actually faster. 00:52:52.060 --> 00:52:54.460 Because verifying the proofs takes a long time or something like that. 00:52:54.460 --> 00:53:01.640 So it's sort of like with the range proofs or something like nimble-wear where the o 00:53:01.640 --> 00:53:03.090 of n is great. 00:53:03.090 --> 00:53:07.770 But you've got these constant factors that, in practice, end up meaning you're not actually 00:53:07.770 --> 00:53:08.770 faster, right? 00:53:08.770 --> 00:53:11.790 Because the Bitcoin UTXO set, well, it's 4 gigs. 00:53:11.790 --> 00:53:12.790 Not even, right? 00:53:12.790 --> 00:53:15.550 It's 3 and 1/2 gigs now. 00:53:15.550 --> 00:53:20.050 So in practice, there's probably a lot of cool cryptographic technologies. 00:53:20.050 --> 00:53:22.280 And you can write a whole paper and have all these cool things. 00:53:22.280 --> 00:53:26.470 And then if you actually implement it, it's like, well, it actually goes twice as slow 00:53:26.470 --> 00:53:27.910 as just using the regular. 00:53:27.910 --> 00:53:30.560 Also, this is super optimized. 00:53:30.560 --> 00:53:36.160 One of the biggest sort of code engineering things that has happened in Bitcoin Core is 00:53:36.160 --> 00:53:38.540 OK, how can we make database updates to this? 00:53:38.540 --> 00:53:44.670 How can we make different caching, different flushes to disk, and editing level DB itself. 00:53:44.670 --> 00:53:49.890 So making this UTXO set database operation faster is a big thing in Bitcoin. 00:53:49.890 --> 00:53:51.970 So it's pretty optimized. 00:53:51.970 --> 00:53:56.300 And even if you've got something that seems like in computer science terms, hey, this 00:53:56.300 --> 00:54:03.200 is log n instead of n, like, yeah, but what about the constant factors? 00:54:03.200 --> 00:54:06.200 So that's another issue for these. 00:54:06.200 --> 00:54:07.330 OK. 00:54:07.330 --> 00:54:11.090 Other things-- I was going to talk-- well, yeah. 00:54:11.090 --> 00:54:16.920 I'll do last one, and then we can maybe end a little early and talk about projects if 00:54:16.920 --> 00:54:17.920 you want. 00:54:17.920 --> 00:54:23.160 UTXO commitments, which is somewhat in the same region as accumulators-- a little bit 00:54:23.160 --> 00:54:24.670 different idea. 00:54:24.670 --> 00:54:27.040 And this exists in some coins. 00:54:27.040 --> 00:54:33.480 Like in Ethereum, Joe Bonneau was saying that you basically have a tree of all the different 00:54:33.480 --> 00:54:37.580 contracts that exist, all the different addresses in Ethereum. 00:54:37.580 --> 00:54:40.310 And the root of that tree appears in every block header. 00:54:40.310 --> 00:54:44.821 So you can make these proofs that coins exist based on a block header. 00:54:44.821 --> 00:54:46.310 So it exists in Ethereum. 00:54:46.310 --> 00:54:50.490 It doesn't exist in Bitcoin, but people have been talking about it for years. 00:54:50.490 --> 00:54:56.640 The simplest would say take a hash of the UTXO set and put it in every Coinbase transaction. 00:54:56.640 --> 00:55:02.260 And make that a consensus rule, so that when you mine a block, you have to take the hash 00:55:02.260 --> 00:55:04.430 of the UTXO set that you're aware of. 00:55:04.430 --> 00:55:06.810 Put it in the block so that everyone can see it. 00:55:06.810 --> 00:55:10.840 And if everyone disagrees, they're going to invalidate that block. 00:55:10.840 --> 00:55:11.980 This is really simple. 00:55:11.980 --> 00:55:16.480 You probably want to do a little bit fancier than this. 00:55:16.480 --> 00:55:22.331 A bit more useful-- instead of just taking a linear hash of the entire UTXO set, make 00:55:22.331 --> 00:55:25.170 it a Merkle tree, right? 00:55:25.170 --> 00:55:28.760 And that way, yeah, sure, it's very little extra hashing. 00:55:28.760 --> 00:55:31.830 Well, no, wait, twice as much hashing, right? 00:55:31.830 --> 00:55:32.830 But anyway. 00:55:32.830 --> 00:55:38.430 2x the hashing, but now you've got the ability to make small proofs. 00:55:38.430 --> 00:55:45.000 And then you can prove an output exists at a given block height pretty easily at SPV 00:55:45.000 --> 00:55:46.010 level security. 00:55:46.010 --> 00:55:50.950 So currently, you can prove that a transaction exists at a block height. 00:55:50.950 --> 00:55:55.700 And you can also prove that a transaction was consumed at a certain block height, right? 00:55:55.700 --> 00:56:04.440 So if you have all these different blocks, 2, 3, 4, 5, you can say, hey, here's a Merkle 00:56:04.440 --> 00:56:09.650 proof that transaction 1 was included in block 2. 00:56:09.650 --> 00:56:16.760 And then you can prove here, OK, here's transaction 2 that consumes one of the outputs from transaction 00:56:16.760 --> 00:56:18.820 1. 00:56:18.820 --> 00:56:25.740 But you can't prove just given-- but also, you can omit this proof, right? 00:56:25.740 --> 00:56:33.030 So if you want to prove that-- so at block 6, how do I prove that the outputs from transaction 00:56:33.030 --> 00:56:36.360 1 still exist at block 6? 00:56:36.360 --> 00:56:37.360 You're stuck, right? 00:56:37.360 --> 00:56:44.130 You basically have to go through blocks 3 through 6 and look at the whole thing. 00:56:44.130 --> 00:56:47.850 So with current SPV proofs, we can prove inclusion, right? 00:56:47.850 --> 00:56:51.440 You sort of think of this as an accumulator, where you've got-- a Merkle tree is kind of 00:56:51.440 --> 00:56:53.250 an accumulator. 00:56:53.250 --> 00:56:56.480 I can prove inclusion, and then I can prove transaction 1 is in block 2. 00:56:56.480 --> 00:57:02.680 I can prove that transaction 2 consumes transaction 1 in block 5. 00:57:02.680 --> 00:57:06.810 But you have to rely on me to give you that proof honestly, right? 00:57:06.810 --> 00:57:12.930 If I'm trying to cheat you and say, oh yeah, I've totally still got money, I can't prove 00:57:12.930 --> 00:57:14.660 that it hasn't been deleted. 00:57:14.660 --> 00:57:21.590 Whereas with a UTXO set commitment, if every block, there was a total commitment to every 00:57:21.590 --> 00:57:27.170 UTXO, I could just say, hey, at block 6, my output from transaction 1, it's still in there. 00:57:27.170 --> 00:57:28.310 Well, it wouldn't be in this case. 00:57:28.310 --> 00:57:30.090 But I could prove it at block 4, right? 00:57:30.090 --> 00:57:33.650 And say, hey, look, transaction 1, it's still in there at block 4. 00:57:33.650 --> 00:57:35.990 No longer there at block 6. 00:57:35.990 --> 00:57:43.460 Depending on how you construct the UTXO commitment, you may be able to provide non inclusion proofs, 00:57:43.460 --> 00:57:45.410 which is also really cool. 00:57:45.410 --> 00:57:53.260 So for example, if you had it be a Merkle tree, if it was just in order insertion-- 00:57:53.260 --> 00:58:01.580 so this is TX1, this is TX2, this is TX3, and you make a Merkle tree that way, then 00:58:01.580 --> 00:58:05.900 you cannot prove that something's not in it, right? 00:58:05.900 --> 00:58:14.020 So when TX3 gets deleted and now TX4 goes here, and TX5 comes here, you can't prove 00:58:14.020 --> 00:58:16.640 the TX3's not there anymore in any real way. 00:58:16.640 --> 00:58:23.180 However, if you sort them so that every time so now you sort them canonically, so like 00:58:23.180 --> 00:58:28.740 by hash, just like greater than, less than, and then the order gets all weird, right? 00:58:28.740 --> 00:58:37.050 So now TX5 is here and TX6 is here because TX5's hash is closer to 1 and stuff like that. 00:58:37.050 --> 00:58:38.740 Then you can prove non-inclusion. 00:58:38.740 --> 00:58:46.310 So then you can say, hey, TX3 is not here because TX3 would be between 5 and 4, right? 00:58:46.310 --> 00:58:48.390 Just based on what the hash looks like. 00:58:48.390 --> 00:58:49.390 And I can show you 5. 00:58:49.390 --> 00:58:50.540 I'm going to prove for it. 00:58:50.540 --> 00:58:52.290 I can show you 4 and approve for it. 00:58:52.290 --> 00:58:56.320 I can show that these two things are adjacent, right, in the tree. 00:58:56.320 --> 00:58:58.750 And there's no 3 there, and it would be there. 00:58:58.750 --> 00:59:01.281 If it existed, it would be right here. 00:59:01.281 --> 00:59:02.800 And I can show that it's not there. 00:59:02.800 --> 00:59:06.850 So then I have non-inclusion proofs in the UTXO set, which could be used for some kind 00:59:06.850 --> 00:59:07.900 of fraud proof. 00:59:07.900 --> 00:59:13.810 So if someone makes a transaction spending something, you can say, no, look, here is 00:59:13.810 --> 00:59:14.810 the last block. 00:59:14.810 --> 00:59:16.460 Here's the UTXO set hash. 00:59:16.460 --> 00:59:20.160 And here's a proof that this input doesn't exist. 00:59:20.160 --> 00:59:22.170 So this must be an invalid transaction. 00:59:22.170 --> 00:59:23.400 That would be really cool, too. 00:59:23.400 --> 00:59:29.650 Because then you could propagate that on the network and sort of prove fraud. 00:59:29.650 --> 00:59:32.570 So this is an idea that's been around for a long time. 00:59:32.570 --> 00:59:39.940 I think maybe the reason it hasn't yet been implemented is, no one can really agree on 00:59:39.940 --> 00:59:41.450 exactly how to do it. 00:59:41.450 --> 00:59:43.420 A lot of people are like, yeah, we should do that. 00:59:43.420 --> 00:59:44.700 That would be cool. 00:59:44.700 --> 00:59:48.800 Yeah, you can prove [INAUDIBLE]. 00:59:48.800 --> 00:59:52.810 So, one thing you could do would be to skip years of initial block download. 00:59:52.810 --> 00:59:56.550 So I don't really care what happened from 2009 to 2015. 00:59:56.550 --> 00:59:59.390 I assume it was fine, right? 00:59:59.390 --> 01:00:04.520 I'm going to start my synchronization in 2016 and just synchronize the last two years. 01:00:04.520 --> 01:00:09.640 So I'll go get this UTXO commitment from end of 2015. 01:00:09.640 --> 01:00:15.260 I will then not just get the commitment, but download a UTXO snapshot from that time. 01:00:15.260 --> 01:00:20.070 And then I'll check that it matches the committed UTXO set hash. 01:00:20.070 --> 01:00:26.120 And then I'll just start from there and then become a full node, where I didn't check the 01:00:26.120 --> 01:00:29.170 first six years or something. 01:00:29.170 --> 01:00:35.680 And its interesting mix of SPV security and regular full node security, and I think personally 01:00:35.680 --> 01:00:38.570 that's probably OK, right? 01:00:38.570 --> 01:00:43.440 If you only verify the last six months of signatures, well, if everyone's been wrong 01:00:43.440 --> 01:00:45.980 for six months, we have bigger problems, right? 01:00:45.980 --> 01:00:53.790 If there's some erroneous transaction in 2015 and the entire network has been just extending 01:00:53.790 --> 01:00:58.720 for three years without reorging, like, wait, what? 01:00:58.720 --> 01:01:03.880 So on the one hand, you don't want to do this for today's blocks, right? 01:01:03.880 --> 01:01:06.550 Because then the miners have full control. 01:01:06.550 --> 01:01:08.510 And the miners can just make up transactions. 01:01:08.510 --> 01:01:12.751 And if you really just say, oh, well, the miners are doing the right thing, then they 01:01:12.751 --> 01:01:14.330 get a lot more power. 01:01:14.330 --> 01:01:18.310 But if you say, well, other people are validating it in real time. 01:01:18.310 --> 01:01:22.850 And I assume that that's the case, and I'll validate six months' worth of transactions. 01:01:22.850 --> 01:01:26.410 So I'll pick up any errors in the last six months and be able to report them. 01:01:26.410 --> 01:01:30.580 But I will assume that after a certain amount of time, I'm pretty sure it's been OK. 01:01:30.580 --> 01:01:32.550 Everyone else has been looking for this. 01:01:32.550 --> 01:01:36.010 So that's a slightly different model than full nodes. 01:01:36.010 --> 01:01:37.780 But in practice, not really. 01:01:37.780 --> 01:01:44.280 Because if you look at the code for Bitcoin today, there's assume valid, which doesn't 01:01:44.280 --> 01:01:45.280 check signatures. 01:01:45.280 --> 01:01:49.790 It sort of has a block hash and says, OK, anything before this, don't check signatures. 01:01:49.790 --> 01:01:54.210 The developers themselves have said, yeah, every signature before here is OK, so you 01:01:54.210 --> 01:01:58.380 have to check the signatures, which is a little nicer. 01:01:58.380 --> 01:02:02.531 Before they had check points, where it would just not validate anything before a certain 01:02:02.531 --> 01:02:03.531 block hash. 01:02:03.531 --> 01:02:08.540 So you sort of already have things like that to speed up the initial synchronization process. 01:02:08.540 --> 01:02:12.560 But a UTXO commitment would make it a lot more sort of decentralized. 01:02:12.560 --> 01:02:17.590 Because right now, it's just the programmers are like, well, this is last year. 01:02:17.590 --> 01:02:18.590 Everyone's validated. 01:02:18.590 --> 01:02:23.610 Let's just hard code this into the code, into the client. 01:02:23.610 --> 01:02:25.580 Anyway. 01:02:25.580 --> 01:02:27.800 So this is an idea. 01:02:27.800 --> 01:02:31.500 The issues-- timing is probably one of the biggest issues. 01:02:31.500 --> 01:02:37.680 If it's consensus critical, then the miners need to put this into their blocks. 01:02:37.680 --> 01:02:41.520 And miners also need to verify it when they get a block. 01:02:41.520 --> 01:02:48.060 And adding even a second to creating and verifying a block can centralize mining a bit. 01:02:48.060 --> 01:02:52.210 Because the idea isl I want to be able to immediately start mining as soon as I see 01:02:52.210 --> 01:02:54.650 a block. 01:02:54.650 --> 01:03:00.100 Because a larger miner doesn't need to verify the block that just came out, right? 01:03:00.100 --> 01:03:01.100 Because they created it. 01:03:01.100 --> 01:03:04.260 If they created a block themselves, they know it's fine. 01:03:04.260 --> 01:03:09.400 They build on top of it immediately with zero propagation delays, zero verification delay. 01:03:09.400 --> 01:03:13.800 Smaller miners or miners receiving that block have to make sure it's correct before mining 01:03:13.800 --> 01:03:15.810 on top of it. 01:03:15.810 --> 01:03:21.140 So adding even a one second creation verification delay is something that a lot of the programmers 01:03:21.140 --> 01:03:25.060 are like, mm, if you can get it down to half a second, maybe we're OK. 01:03:25.060 --> 01:03:29.920 We want this functionality, but not at the cost of increasing that. 01:03:29.920 --> 01:03:31.520 That's the worst time to add something. 01:03:31.520 --> 01:03:37.430 If you can defer it, if you can say, oh, well, you need to verify this, but you can do it 01:03:37.430 --> 01:03:39.570 after the fact or something, then it's fine. 01:03:39.570 --> 01:03:43.450 So this I ran up against this because I had this fun idea, where you could half aggregate 01:03:43.450 --> 01:03:46.660 Schnorr signatures within a block and do it non-interactively. 01:03:46.660 --> 01:03:50.740 And it was really cool, and I'm pretty sure it works. 01:03:50.740 --> 01:03:58.040 But it added, like, three seconds to block verification, so that killed that idea. 01:03:58.040 --> 01:04:01.030 So one of the issues, yeah, timing. 01:04:01.030 --> 01:04:06.740 Another issue is it does encourage more SPV level verification, where you can sort of 01:04:06.740 --> 01:04:11.590 see that a lot of people will now use this method to not run a full node. 01:04:11.590 --> 01:04:16.630 Because they're like, well, I can just get these compact proofs for all the UTXOs, whether 01:04:16.630 --> 01:04:18.630 inclusion or non-inclusion. 01:04:18.630 --> 01:04:19.630 So why run a full node? 01:04:19.630 --> 01:04:23.750 I don't need to verify it because other people are. 01:04:23.750 --> 01:04:26.740 You don't really want to encourage that because there's so much of that already. 01:04:26.740 --> 01:04:30.620 Also, the biggest is probably there's got to be a better way to do this. 01:04:30.620 --> 01:04:32.600 So there's all these different ideas on how to do it. 01:04:32.600 --> 01:04:35.560 And they never seem to settle or converge on a single way. 01:04:35.560 --> 01:04:43.750 So the three main ideas are sort of hash based UTXO sets, elliptic curve based commitments, 01:04:43.750 --> 01:04:46.420 and RSA based commitments. 01:04:46.420 --> 01:04:51.640 And there's a lot of overlap with accumulators, in that you're sort of-- the UTXO commitment 01:04:51.640 --> 01:04:55.710 could be the sort of route or the hash of the accumulator itself. 01:04:55.710 --> 01:05:00.480 That you want to prove that something's in there or prove that something's not in there. 01:05:00.480 --> 01:05:03.990 And the EC one is the current one that Sip was looking at was looking at, but it never 01:05:03.990 --> 01:05:04.990 made sense to me. 01:05:04.990 --> 01:05:09.960 Because it's trivially-- you can provide invalid proofs really easily. 01:05:09.960 --> 01:05:11.529 So it's all trusted. 01:05:11.529 --> 01:05:17.170 But his idea was, well, let's say you have a node that you synced up, and you want to 01:05:17.170 --> 01:05:21.490 sort of port that to somewhere else. 01:05:21.490 --> 01:05:27.000 You can do that very compactly with an elliptic curve based UTXO commitment, which is cool, 01:05:27.000 --> 01:05:30.779 but you can't trust the inclusion or non-inclusion proofs. 01:05:30.779 --> 01:05:36.340 And there's RSA ones that also-- yeah, so there's some overlap there. 01:05:36.340 --> 01:05:38.700 Anyway it's a pretty cool idea. 01:05:38.700 --> 01:05:43.720 It does exist in Ethereum, which is just hash based that Joe Bonneau sort of explained the 01:05:43.720 --> 01:05:46.270 tree thing they used. 01:05:46.270 --> 01:05:49.470 But that doesn't provide for non-inclusion proofs, which would be fun. 01:05:49.470 --> 01:05:52.480 So yeah, so this is another research area. 01:05:52.480 --> 01:05:57.710 Any questions about UTXO commitments? 01:05:57.710 --> 01:06:02.380 There's a bunch of-- Bram Cohen's Bitfield thing. 01:06:02.380 --> 01:06:03.720 Have you seen that? 01:06:03.720 --> 01:06:04.720 Yeah. 01:06:04.720 --> 01:06:09.810 So that was a really interesting case of-- in computer science terms, it's o of n. 01:06:09.810 --> 01:06:15.670 But he got it so that it's actually one bit per spent transaction output. 01:06:15.670 --> 01:06:22.810 So the idea would be maintain a TXO set, right? 01:06:22.810 --> 01:06:28.660 So for every transaction output ever created in order, you have just bits, right? 01:06:28.660 --> 01:06:32.270 So if eight transaction outputs are created, that's a byte. 01:06:32.270 --> 01:06:34.830 And you leave it all as zeros when they're unspent. 01:06:34.830 --> 01:06:37.930 And when they have been spent, you just set it to 1. 01:06:37.930 --> 01:06:43.980 And the thing is, yeah, there's 70 million, but if it's that-- well, there's more. 01:06:43.980 --> 01:06:45.350 There's hundreds of millions. 01:06:45.350 --> 01:06:48.460 But if it's bits instead of bytes, that's pretty small, right? 01:06:48.460 --> 01:06:54.100 It's maybe 100 megabytes if you have 800 million outputs ever. 01:06:54.100 --> 01:06:58.310 And then you can quickly see on your hard drive, OK, this output has been spent. 01:06:58.310 --> 01:07:00.060 And you can provide proofs and stuff. 01:07:00.060 --> 01:07:02.480 So the Bitfield thing was a kind of an interesting one. 01:07:02.480 --> 01:07:08.500 OK, it's o of n, but 1 bit per object. 01:07:08.500 --> 01:07:10.910 And you can sort of quickly sort between them. 01:07:10.910 --> 01:07:15.180 So these are some of the things that-- I think that's it for today, right? 01:07:15.180 --> 01:07:22.180 I was going to talk about covenants, but that's another story. 01:07:22.180 --> 01:07:30.180 So these are some of the current research issues in Bitcoin, blockchain, cryptocurrency. 01:07:30.180 --> 01:07:31.260 And there's lots of other topics. 01:07:31.260 --> 01:07:34.720 But these are some of the big ones that I'm aware of and I know people working on. 01:07:34.720 --> 01:07:41.020 But yeah, there's lots of ways to improve privacy, scalability, functionality. 01:07:41.020 --> 01:07:45.690 It's certainly not like-- and sometimes people say, oh, well, Bitcoin was made in 2009. 01:07:45.690 --> 01:07:53.370 And it's like blockchain version 1.0, and we need to make blockchain 4.0 or whatever. 01:07:53.370 --> 01:07:56.510 And to some extent, yeah, Bitcoin is annoying to change, right? 01:07:56.510 --> 01:08:01.540 It's difficult to change, and you've got the idea of a bridge node, and can't we just start 01:08:01.540 --> 01:08:02.540 over? 01:08:02.540 --> 01:08:03.540 It'd be so much easier. 01:08:03.540 --> 01:08:06.950 In some cases, yes, it would be nicer to start over. 01:08:06.950 --> 01:08:08.010 But that's sort of the challenge. 01:08:08.010 --> 01:08:16.040 It's like, wait, can we make this system better, but maintain backwards compatibility? 01:08:16.040 --> 01:08:23.799 And so, in a lot of cases, like the accumulators or the client side Bloom filter checking, 01:08:23.799 --> 01:08:27.270 it's not a fork at all, right? 01:08:27.270 --> 01:08:28.899 The miners don't have to change anything. 01:08:28.899 --> 01:08:33.788 If you don't know about this new change, you don't have to change anything. 01:08:33.788 --> 01:08:38.149 And so there are totally optional ways to improve some of these things. 01:08:38.149 --> 01:08:39.960 And that's a fun challenge, right? 01:08:39.960 --> 01:08:40.960 You're given this system. 01:08:40.960 --> 01:08:46.259 It's sort of like trying to improve an airplane while it's in flight, where you're like, OK, 01:08:46.259 --> 01:08:49.769 I'm going to make it faster, make it better while it's flying. 01:08:49.769 --> 01:08:52.179 We can't even land. 01:08:52.179 --> 01:08:55.568 So yeah, that definitely makes it harder. 01:08:55.568 --> 01:09:01.698 But other things are-- but what's also interesting is that there's not that many things in it 01:09:01.698 --> 01:09:05.979 that really require starting over from scratch. 01:09:05.979 --> 01:09:12.880 So I know at the New York City Bitcoin Core Developer Meetup in March, Bram Cohen, who 01:09:12.880 --> 01:09:16.660 made BitTorrent-- he's making his own coin, I guess, now. 01:09:16.660 --> 01:09:21.520 And it's kind of interesting because usually, the Bitcoin people don't like alt coins or 01:09:21.520 --> 01:09:26.630 are sort of wary of them, and don't invite alt coin people to their events and stuff. 01:09:26.630 --> 01:09:31.799 But Bram Cohen invented BitTorrent, so everyone sort of owes him in some spiritual way a couple 01:09:31.799 --> 01:09:37.120 thousand bucks for all the music and movies they've downloaded, right? 01:09:37.120 --> 01:09:40.210 So it's like, oh, Bram, he helped us out. 01:09:40.210 --> 01:09:41.818 So he comes to these things. 01:09:41.818 --> 01:09:46.759 And he was asking at the thing in March, OK-- asking a lot of people-- if you were going 01:09:46.759 --> 01:09:51.029 to start Bitcoin over from scratch, what would you change? 01:09:51.029 --> 01:09:55.699 All the people who were programming this for years and dealing with all the annoying problems 01:09:55.699 --> 01:10:00.619 in it gave, if you started from scratch, what code do you change? 01:10:00.619 --> 01:10:04.820 Or what sort of basic infrastructure things do you change in the system? 01:10:04.820 --> 01:10:06.400 And there weren't that many, right? 01:10:06.400 --> 01:10:08.869 A lot of people were like, oh, there's the little things. 01:10:08.869 --> 01:10:12.300 Like, oh, get rid of the little silly op zero in multi sig. 01:10:12.300 --> 01:10:14.890 Get rid of this, or change a couple of these things. 01:10:14.890 --> 01:10:21.180 But not a lot of really fundamental changes people would want to have made. 01:10:21.180 --> 01:10:25.969 Some people were saying, hey, maybe instead of pointing based on TXID, be able to point 01:10:25.969 --> 01:10:30.860 height and index, so you can have a lot smaller there. 01:10:30.860 --> 01:10:36.800 Some different opcode things, but what was interesting is that-- and also, it's a super 01:10:36.800 --> 01:10:37.800 biased sample. 01:10:37.800 --> 01:10:42.099 And it's like, if you're asking all the people who work on Bitcoin, well, yeah, they sort 01:10:42.099 --> 01:10:45.989 of like how Bitcoin works, or at least, they've grown accustomed to it. 01:10:45.989 --> 01:10:49.239 So you might want to ask other people if you want to sort of think out of the box. 01:10:49.239 --> 01:10:52.940 But there weren't a ton of major changes that people wanted to have made. 01:10:52.940 --> 01:11:00.760 So it does seem that it's a fairly well thought out base of a system. 01:11:00.760 --> 01:11:04.800 And then I'd say the Ethereum design is the other design that's very different, right? 01:11:04.800 --> 01:11:07.619 The account based versus UTXO base. 01:11:07.619 --> 01:11:11.800 And a lot of the people who work on Bitcoin think that account based is worse. 01:11:11.800 --> 01:11:15.519 A lot of people maybe in Ethereum case think UTXO base is worse. 01:11:15.520 --> 01:11:17.700 They do have tradeoffs.