WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode. 00:00:20.270 --> 00:00:22.250 Live from Utrecht, this is Bitcoin. 00:00:22.990 --> 00:00:23.430 Explained. 00:00:23.650 --> 00:00:23.970 It's Sjors. 00:00:24.350 --> 00:00:24.530 Hello. 00:00:24.950 --> 00:00:28.210 You want to shill one of your new projects. Is that right? 00:00:28.430 --> 00:00:34.210 Yes, I do. If you are in Amsterdam for the Coin Conference in October, then 00:00:34.210 --> 00:00:38.190 two days before that, I am giving an in-person course, which will be interesting 00:00:38.190 --> 00:00:42.150 for you if you are interested in learning how to contribute to Bitcoin Core. And 00:00:42.150 --> 00:00:45.230 if you want to find out more, go to learnbitcoincore.com. 00:00:45.710 --> 00:00:46.470 What's the date? 00:00:46.910 --> 00:00:47.730 October 10th. 00:00:47.870 --> 00:00:48.470 What's the price? 00:00:49.180 --> 00:00:50.040 Well, it depends 00:00:50.040 --> 00:00:51.240 Depends on what? 00:00:51.240 --> 00:00:53.740 On when you read this, when you listen to this. 00:00:53.740 --> 00:00:58.560 Oh, are you gonna do the thing where it gets more expensive as we get closer to the date? 00:00:58.560 --> 00:01:02.120 Maybe, but I know that people listen to these podcasts months later so… 00:01:03.510 --> 00:01:06.490 You might just decide to change the price when you feel like it. 00:01:06.490 --> 00:01:07.010 Exactly. 00:01:07.010 --> 00:01:08.730 Okay. All right. What was the website? 00:01:08.730 --> 00:01:11.070 Learnbitcoincore.com 00:01:12.890 --> 00:01:16.010 Do we have any… did you stack any sats Sjors? 00:01:17.150 --> 00:01:18.590 If you insist, I can read it. 00:01:18.690 --> 00:01:21.930 I'm not insisting at all, but if you want to, I'll do the jingle. 00:01:22.330 --> 00:01:22.710 All right. 00:01:23.190 --> 00:01:23.570 Oh, God. 00:01:24.800 --> 00:01:29.400 Sjors stacks sats. Sjors stacks sats. Sjors stacks sats. 00:01:30.220 --> 00:01:33.240 So, in general, there was some discussion about whether or not we should read the 00:01:33.240 --> 00:01:37.140 sats, and some people vehemently said we should read the sats. So, we cannot, you 00:01:37.140 --> 00:01:41.880 know, disappoint the audience, of course. You could have skipped it. So I'll read 00:01:41.880 --> 00:01:47.320 one from Loki. 10,000 sats. The sats shall get stacked. Thanks for the technical 00:01:47.320 --> 00:01:49.040 information and musical wonders. 00:01:49.740 --> 00:01:50.680 You're welcome. 00:01:50.980 --> 00:01:52.780 And then the reply to that is, duh. 00:01:54.530 --> 00:02:00.420 Sjors stacks sats. Sjors. Today we're going to discuss. It's a little bit 00:02:00.420 --> 00:02:06.280 of a different episode as usual. Because we're [unclear] really going to 00:02:06.280 --> 00:02:12.280 discuss one particular technical topic. We're more describing an 00:02:12.760 --> 00:02:17.740 outline of a vision for Bitcoin. And to be precise, it's going to be Anthony 00:02:17.740 --> 00:02:22.340 Towns' sort of scaling vision. Right? 00:02:22.880 --> 00:02:24.700 That's right. Anthony Towns had a vision. 00:02:25.640 --> 00:02:26.940 Who's Anthony Towns? 00:02:27.200 --> 00:02:28.440 He's a Bitcoin developer. 00:02:28.620 --> 00:02:33.650 Yeah, he's one of the most prolific Bitcoin Core developers. So Anthony Towns 00:02:33.650 --> 00:02:39.030 wrote a blog post called Putting the B in BTC. That's B for 00:02:39.030 --> 00:02:44.090 billions of people he writes in his blog post. So the plan is we want to scale 00:02:44.090 --> 00:02:48.930 Bitcoin to billions of people. And now he wrote a blog post on how we can do 00:02:48.930 --> 00:02:53.030 this. So to start what we're going to do is we're going to kind of just run 00:02:53.030 --> 00:02:57.760 through this blog post and you're going to comment on it, and maybe I'll comment 00:02:57.760 --> 00:03:02.580 on it as well a little bit, but we're kind of just for people that are too too 00:03:02.580 --> 00:03:07.180 lazy to read it we're going to just sort of explain what the idea is. So how are 00:03:07.180 --> 00:03:11.880 we going to scale Bitcoin to billions of people? All right so essentially Anthony 00:03:11.880 --> 00:03:17.730 writes there are three kind of main ideas of doing 00:03:17.730 --> 00:03:23.670 that. There are sort of three roads to get there if you will, one 00:03:23.670 --> 00:03:29.440 is Just make the tech super efficient. Then the second one 00:03:29.440 --> 00:03:34.660 is don't have everyone validate every transaction. And the third one is 00:03:34.660 --> 00:03:40.040 have most people transact off blockchain. I guess first of all, these three 00:03:40.040 --> 00:03:44.320 strategies. Is there a fourth one? Do you agree with these three? 00:03:44.860 --> 00:03:49.240 I think it's reasonable to say. So the premise of how you use Bitcoin is that you 00:03:49.240 --> 00:03:53.560 run a full node and you validate all the blocks. But that gets harder and harder 00:03:53.560 --> 00:03:57.860 as blocks get bigger. And since every transaction that people make, you know, 00:03:57.960 --> 00:04:02.880 takes up space, if you scale to a billion people, then naively, you know, you end 00:04:02.880 --> 00:04:06.280 up with very large blocks in the easiest case. So you could say, well, maybe we 00:04:06.280 --> 00:04:10.000 can make the validation of these large blocks simpler. Or you can say, well, I 00:04:10.000 --> 00:04:13.960 guess it's not possible for everyone to validate. Then we just say, you know, 00:04:14.040 --> 00:04:18.100 fewer people will do it. Or you can say, okay, there should be fewer transactions 00:04:18.100 --> 00:04:23.580 so that everybody can still validate the blockchain. I think that's a reasonable 00:04:23.580 --> 00:04:26.390 triangle. You could probably draw another one, but it's fine. 00:04:26.710 --> 00:04:30.790 Yeah. So we've had the block size wars a couple of years ago, of course, and this 00:04:30.790 --> 00:04:34.310 was sort of the central, you know, it's kind of a continuation 00:04:34.310 --> 00:04:40.220 of that debate we had back then. And there were 00:04:40.220 --> 00:04:41.440 indeed different ideas. 00:04:43.330 --> 00:04:46.830 Yeah. And back in the days, people were especially doing number one in practice, 00:04:47.010 --> 00:04:51.210 making the tech more efficient. You know, I've done an experiment in 2017 where I 00:04:51.210 --> 00:04:56.950 would take identical computers and try to sync the blockchain of that date using 00:04:56.950 --> 00:05:00.710 older and older versions of Bitcoin Core. And what you can see is that for the 00:05:00.710 --> 00:05:03.430 same blockchain and the same computer, Bitcoin Core was getting objectively 00:05:03.430 --> 00:05:09.710 faster every year. But that has slowed down a bit. But you could continue that process. 00:05:09.930 --> 00:05:13.550 Anthony shared some thoughts on each of these approaches. So let's just kind of 00:05:13.550 --> 00:05:19.430 walk through them. So improving the tech. He gives some examples 00:05:19.430 --> 00:05:24.090 of projects that are in development right now that would accomplish this. So one 00:05:24.090 --> 00:05:28.570 of them is Utreexo, which I think we did a whole episode on, right? 00:05:29.110 --> 00:05:29.650 Yes, we did. 00:05:29.810 --> 00:05:32.930 Well, what is Utreexo? Do you want to summarize this in…? 00:05:33.210 --> 00:05:37.730 Yeah, Utreexo helps with one of the many bottlenecks in Bitcoin. I would say 00:05:37.730 --> 00:05:38.430 memory usage. 00:05:41.030 --> 00:05:43.670 So basically what happens is... One second. 00:05:45.300 --> 00:05:49.880 So basically what happens is that you have this thing called the UTXO set, which 00:05:49.880 --> 00:05:54.380 is the list of who owns which coin. And your node keeps track of the list who 00:05:54.380 --> 00:05:59.600 owns which coin. And if billions of people own a coin, then that list gets 00:05:59.600 --> 00:06:04.780 extremely long. And so Utreexo fixes that by putting the entire ownership list in 00:06:04.780 --> 00:06:10.680 a Merkle tree. And then rather than everybody having the full 00:06:10.680 --> 00:06:14.460 list, when you want to spend a coin you need to prove that that coin exists in 00:06:14.460 --> 00:06:17.340 the first place. So I don't have to… as a node operator I don't have to remember 00:06:17.340 --> 00:06:21.220 who owns which coin. If you think you own a coin you have to prove it to me and 00:06:21.220 --> 00:06:21.860 send me some data. 00:06:22.340 --> 00:06:27.920 Yeah, so as we mentioned there are I 00:06:28.330 --> 00:06:32.330 mean there are essentially several bottlenecks when you want to scale Bitcoin up. 00:06:32.570 --> 00:06:35.450 If everyone wants to check every transaction, then one of the things they need to 00:06:35.450 --> 00:06:40.230 do is keep these UTXO set. So they need to keep a record of who owns what, 00:06:40.410 --> 00:06:46.200 essentially. And Utreexo is a way to decrease the size 00:06:46.200 --> 00:06:50.660 of that record, right? Okay, so that's one bottleneck. And then another one he 00:06:50.660 --> 00:06:55.260 mentioned is ZeroSync. I don't know. Do we... 00:06:55.260 --> 00:06:59.400 We have not covered that in any episode. I mean, there's more to it, I guess. But 00:06:59.400 --> 00:07:05.260 one of the objectives is to make it easier to catch up if you start from scratch. 00:07:05.520 --> 00:07:09.180 So the first time you download the blockchain, maybe you can use zero-knowledge 00:07:09.180 --> 00:07:13.920 proofs, which is fancy math, to say, okay, I'm just going to assume that... 00:07:13.920 --> 00:07:18.200 or no, I'm—I know that everything that happened so far is correct, so just give 00:07:18.200 --> 00:07:23.380 me the latest UTXO set. So instead of giving me all the blocks... from the you 00:07:23.380 --> 00:07:27.180 know from the past to the present give me the current set of who owns what, and 00:07:27.180 --> 00:07:31.420 a proof that this set was constructed using the official validation rules. And 00:07:31.420 --> 00:07:34.780 ZeroSync tries to achieve that. And they I think they've done some of that work 00:07:34.780 --> 00:07:39.500 like showing that enough proof of work is actually in the blockchain but by far 00:07:39.500 --> 00:07:43.630 not all of it. And that would help at least new users, which is part of the 00:07:43.630 --> 00:07:46.990 reasons why it's hard to run a node because you have to catch up. 00:07:47.250 --> 00:07:51.310 Right. So that's another one of the bottlenecks that it could potentially help 00:07:51.310 --> 00:07:55.370 resolve. So if one of the bottlenecks is the size of UTXO set, then another 00:07:55.370 --> 00:07:58.570 bottleneck is the time it takes to sync the entire blockchain. 00:07:58.910 --> 00:08:03.430 Yeah, and AssumeUTXO is another approach to do that, where... Instead of 00:08:03.430 --> 00:08:06.630 delivering any proofs, or maybe you can combine these things, right? You just 00:08:06.630 --> 00:08:11.430 say, okay, this is the UTXO set as of so many years ago. And then you're just 00:08:11.430 --> 00:08:15.520 kind of trusting that the past is real. But maybe you can combine that. 00:08:16.120 --> 00:08:21.620 Right. Another example that Anthony mentioned is silent payments, which I think 00:08:21.620 --> 00:08:23.500 we also did an episode on with Ruben, right? 00:08:23.780 --> 00:08:26.820 Yeah. So that's not an example of a scaling technology, but that is an example of 00:08:26.820 --> 00:08:31.360 saying why it is important to be able to check every single transaction in every 00:08:31.360 --> 00:08:35.820 single block. Because in order to use silent payments, which we have done an 00:08:35.820 --> 00:08:40.000 episode about, you as the recipient, as the sender it doesn't matter, but as the 00:08:40.000 --> 00:08:44.440 recipient, you have to scan every block and every transaction in a block to see 00:08:44.440 --> 00:08:50.400 if there is a payment to you. And so if blocks become massive, then 00:08:50.400 --> 00:08:54.920 that scanning effort becomes a problem. It isn't right now. It seems pretty 00:08:54.920 --> 00:08:57.640 lightweight. But it could be if we make blocks 100 times bigger. 00:08:58.410 --> 00:09:03.690 Right, okay well, so in any case this is… these are some examples that fit in 00:09:03.690 --> 00:09:09.690 bucket one is improving the technology. However I think Anthony's 00:09:09.690 --> 00:09:14.770 point is essentially that while there is room to grow here, this alone 00:09:15.470 --> 00:09:18.630 it doesn't look like it's going to get us to a billion users. 00:09:18.850 --> 00:09:22.170 No, and he mentions another thing with regard to the silent payments, if I see it 00:09:22.170 --> 00:09:25.970 correctly. We mentioned the ZeroSync idea of catching up from start, but you 00:09:25.970 --> 00:09:30.050 could also imagine using something like ZeroSync to make jumps. So instead of 00:09:30.050 --> 00:09:32.550 validating every block as it comes in, you could say, well, I'm just going to 00:09:32.550 --> 00:09:37.520 wait a month and then check whatever happened, get a compressed summary of the 00:09:37.520 --> 00:09:40.940 last month. That could also be a way to keep track of a much bigger blockchain. 00:09:41.700 --> 00:09:44.660 But you can't do that with something like silent payments because then you'd have 00:09:44.660 --> 00:09:46.160 to wait a month to know that you got paid. 00:09:47.520 --> 00:09:53.220 Right. Okay. So that's bucket one, improving the tech, which will help us 00:09:53.220 --> 00:09:58.640 grow a bit, but it's not going to be able to get us to a billion, right? 00:09:58.880 --> 00:10:03.980 So then we move to category two solutions, which is don't validate. 00:10:04.440 --> 00:10:09.540 So here we really get into what the block size wars were about for a big part, I 00:10:09.540 --> 00:10:15.380 think. Is that some people and they still exist on other blockchains 00:10:15.380 --> 00:10:20.120 they have this vision that it's actually not necessary for every user to 00:10:20.380 --> 00:10:22.340 validate every transaction. 00:10:22.340 --> 00:10:26.920 Yeah, which can go in two directions right? You can say only some users validate 00:10:26.920 --> 00:10:31.020 everything. Or you can say well most users validate some things, but not all 00:10:31.020 --> 00:10:32.480 users validate all the things. 00:10:32.480 --> 00:10:34.640 Wait, can you elaborate on that? 00:10:34.640 --> 00:10:39.930 Well, so the latter would be let's say everybody runs an SPV wallet which is just 00:10:39.930 --> 00:10:42.830 checking the headers. It's still checking that there's proof of work, that 00:10:42.830 --> 00:10:45.210 headers are building on top of each other, that there's no funny things with 00:10:45.210 --> 00:10:49.340 timestamps, but it is not checking any of the transactions and the signatures in 00:10:49.340 --> 00:10:52.800 the block. So that's a scenario where not everybody checks all the things. 00:10:53.880 --> 00:10:57.120 No, that's a scenario where everybody checks not all the things. 00:10:58.610 --> 00:10:59.630 Yeah, that's the same thing. 00:11:00.130 --> 00:11:01.430 No, no, that's a difference, right? 00:11:01.710 --> 00:11:04.450 Not everybody checks all the things. So there will still be people who run a full 00:11:04.450 --> 00:11:05.430 node and check all the things. 00:11:05.460 --> 00:11:06.090 I guess that's also true. 00:11:06.090 --> 00:11:08.770 But some people will only check some things. Now, there's other blockchains, I 00:11:08.770 --> 00:11:12.570 think, like probably things like Solana, where really there is just a small 00:11:12.570 --> 00:11:15.350 number of people who check all the things. Maybe. 00:11:16.580 --> 00:11:19.660 But most people check nothing, basically. So it's very black and white. 00:11:19.980 --> 00:11:24.960 Yeah, so basically some people check everything and then everyone else asks these 00:11:24.960 --> 00:11:29.300 people, hey, what's going on, right? That's essentially what it comes down to. I 00:11:29.300 --> 00:11:33.100 mean, it's automated, obviously. People are using APIs and that kind of stuff, 00:11:33.120 --> 00:11:34.560 but that's what it comes down to. 00:11:34.640 --> 00:11:39.080 Yeah, and if you push that too far, you have a centralized point of failure, 00:11:39.100 --> 00:11:43.400 which they could either lie or they could exclude you from the system. You know 00:11:43.400 --> 00:11:45.640 you basically go back to PayPal worst case. 00:11:45.670 --> 00:11:51.610 Yes. The people that are checking everything they could either collude to 00:11:51.610 --> 00:11:56.990 change the rules, make more than 21 million Bitcoin, or they can be regulated and 00:11:56.990 --> 00:12:01.770 introduce censorship or they can do all kinds of things that we don't really want. 00:12:01.770 --> 00:12:05.430 Yeah, and just add my own thoughts here, I think you could probably think about 00:12:05.430 --> 00:12:08.470 something in the middle where some people validate something, some people 00:12:08.470 --> 00:12:12.540 validate other things but it's… It's hard to reason whether or not that's going 00:12:12.540 --> 00:12:16.060 to be safe. We know the current approach works. It's like everybody checks 00:12:16.060 --> 00:12:20.340 everything. And how much of that you can, you know, how far you can go on the 00:12:20.340 --> 00:12:24.540 grayscale towards one person checking everything. There's some point in which it 00:12:24.540 --> 00:12:25.240 goes horribly wrong. 00:12:26.520 --> 00:12:28.360 So it's better to be on the safe side, I think. 00:12:29.460 --> 00:12:35.370 Yeah, well, essentially, so this option... it's included in the blog sort 00:12:35.370 --> 00:12:37.830 of more as an example of what not to do, right? 00:12:38.170 --> 00:12:42.510 Yeah, and he also says that even this pushes to the limits of even those few 00:12:42.510 --> 00:12:45.830 people that validate. If they really want to process every transaction of every 00:12:45.830 --> 00:12:51.190 person on the planet, it still becomes a problem or it's a fragile system that's 00:12:51.190 --> 00:12:51.930 easy to mess with. 00:12:52.900 --> 00:12:58.240 Right, okay so then we get to the third option which is kind of I would say the 00:12:58.240 --> 00:13:02.320 heart of the article, like this is kind of the vision really, which is get off 00:13:02.320 --> 00:13:02.840 the blockchain. 00:13:02.840 --> 00:13:03.980 Get off the blockchain. 00:13:03.980 --> 00:13:08.820 So not all transactions need to happen on the Bitcoin blockchain. So what does 00:13:08.820 --> 00:13:09.440 that look like? 00:13:11.110 --> 00:13:16.730 Well, I mean the most obvious example of that is Lightning, where instead of 00:13:16.730 --> 00:13:20.530 every time you want to send a satoshi, you create a Bitcoin transaction, now you 00:13:20.530 --> 00:13:24.600 create a Bitcoin transaction to open a channel. You use the Lightning Network for 00:13:24.600 --> 00:13:27.660 a while to make a bunch of payments, and then after a while you close the 00:13:27.660 --> 00:13:31.560 channel, either because you want to or because you're forced to. Unfortunately, 00:13:32.020 --> 00:13:36.160 if you run the numbers on that, which has been done, like, by Tadge Dryja seven 00:13:36.160 --> 00:13:40.110 years ago, I think, you still end up with, like, it's not going to fit the whole 00:13:40.110 --> 00:13:43.670 population, just a few tens of millions. 00:13:44.250 --> 00:13:48.050 Yeah, the problem with that is that even if you use Lightning, you still need 00:13:48.050 --> 00:13:50.430 some transactions on the blockchain, right? 00:13:50.710 --> 00:13:55.470 Yeah, so if you do the math on like every person opens one channel per year or 00:13:55.630 --> 00:13:59.350 closes one channel per year, then that still doesn't fit the whole world 00:13:59.350 --> 00:14:02.810 population onto the Bitcoin blockchain. So you still have to answer the question 00:14:02.810 --> 00:14:07.590 that we asked before. Like, okay, does that mean some people don't use the 00:14:07.590 --> 00:14:12.270 blockchain? Or do we make blocks bigger and then do we not validate them, etc.? 00:14:12.270 --> 00:14:13.930 So it doesn't solve it all the way. 00:14:16.430 --> 00:14:21.390 So Lightning doesn't solve the problem completely. But there is another idea, 00:14:21.770 --> 00:14:24.770 Sjors. There is another idea called sidechains. 00:14:25.030 --> 00:14:25.490 Yes. 00:14:25.710 --> 00:14:29.990 What's your opinion on sidechains? We've done an episode or two or we've... 00:14:29.990 --> 00:14:33.630 Well, we've talked about some examples of sidechain-ish systems. 00:14:33.790 --> 00:14:34.430 I mean, basically... 00:14:34.430 --> 00:14:35.650 Drivechains and other things. 00:14:36.030 --> 00:14:39.890 Yeah, basically every time Ruben was here, it was something sidechain-ish, right? 00:14:40.270 --> 00:14:43.370 That's right. So just look for the episodes with Ruben and you can learn all you 00:14:43.370 --> 00:14:48.080 want about that topic. Problem is, so far, it hasn't been proven out. So, 00:14:48.300 --> 00:14:54.000 critically, it is very easy to move your Bitcoin assets onto some sort of other 00:14:54.000 --> 00:14:59.910 chain, but moving them back always requires some unpleasant trade-offs. 00:15:00.190 --> 00:15:03.010 Well, yes, but it also kind of depends. 00:15:03.010 --> 00:15:06.750 Either like a custodian, like in the Liquid case, where you're essentially just 00:15:06.750 --> 00:15:11.390 using a custodian with some benefits. Or in the case of drivechains where you 00:15:11.390 --> 00:15:15.290 have a very long withdrawal window in which you have to do some fighting and 00:15:15.290 --> 00:15:21.110 stuff. So there's no clean mechanism. The ideal of a sidechain is there's this 00:15:21.110 --> 00:15:23.630 other chain with completely different rules, doesn't matter what it is, could be 00:15:23.630 --> 00:15:28.030 small blocks, could be big blocks, could be smart contracts or not, and you can 00:15:28.030 --> 00:15:32.030 move one Bitcoin onto it, and as long as that other chain doesn't implode, you 00:15:32.030 --> 00:15:36.090 can take that Bitcoin off of it. But the problem is that other chain tends to be 00:15:36.090 --> 00:15:40.450 much less secure from a censorship resistant point of view as the Bitcoin 00:15:40.450 --> 00:15:43.790 blockchain. So in the worst case, you're depending on the custodian actually 00:15:43.790 --> 00:15:48.170 giving your money back and slightly better cases is still not as strong as 00:15:48.170 --> 00:15:49.750 getting your money out of, say, a Lightning channel. 00:15:50.270 --> 00:15:51.730 Yeah, well, in the case of... 00:15:53.230 --> 00:15:58.810 Liquid, it's not necessarily one custodian, right? It's allegedly at least a 00:15:58.810 --> 00:16:02.610 federation of custodians. We don't know who's in the federation, but it's 00:16:02.610 --> 00:16:06.690 supposedly a group of companies that all hold sort of keys to a multisig. 00:16:06.910 --> 00:16:10.510 Yeah, and they've built in a lot of automation, et cetera, et cetera. You can 00:16:10.510 --> 00:16:14.690 swap with other people. So it's not horrible, but it's still not as secure as 00:16:14.690 --> 00:16:15.310 Bitcoin itself. 00:16:15.630 --> 00:16:21.550 Right, yes, there's a trade-off there. So that's an idea. Another idea, which 00:16:21.550 --> 00:16:25.850 is newer, is something like Fedimint, right? Have we done an episode of Fedimint? 00:16:26.070 --> 00:16:30.090 Yes, we have. We've done an episode about federated e-cash in general. Where we 00:16:30.090 --> 00:16:33.870 explained the whole history from David Chaum onto the latest. I mean, it has 00:16:33.870 --> 00:16:35.790 evolved a little bit, but we have explained it. 00:16:36.050 --> 00:16:36.890 Yes, we did. 00:16:36.950 --> 00:16:37.250 With Ruben. 00:16:37.370 --> 00:16:42.310 I remember now. Yes, that's right. So that's another idea, which is also a 00:16:42.310 --> 00:16:43.490 federated custodian. 00:16:43.650 --> 00:16:47.490 I would just say that's a custodian, but it's a custodian with benefits. 00:16:47.930 --> 00:16:52.350 Well, Fedimint has also a federated custodian model, right? 00:16:52.690 --> 00:16:53.510 Sure, in theory. 00:16:54.510 --> 00:16:57.090 Again, yes, you still have to sort of trust them. 00:16:57.130 --> 00:17:00.270 I mean, a federation could also just be one company that has three different 00:17:00.270 --> 00:17:01.990 staff members in different parts of the world. 00:17:03.300 --> 00:17:03.680 Sure. 00:17:04.490 --> 00:17:08.330 But in any case, it at least makes, you know, you can make custodians suck less. 00:17:08.650 --> 00:17:13.110 I think that might be one way to frame it. So Liquid makes custodians suck less 00:17:13.110 --> 00:17:16.370 because the custodians are spread out over different companies and they use a 00:17:16.370 --> 00:17:20.410 bunch of automation and they can't necessarily see what you're doing. Fedimint, 00:17:20.590 --> 00:17:24.170 similarly, you have a lot of privacy against your own custodian, so they can rug 00:17:24.170 --> 00:17:27.430 you. But other than that, they can't really see what you're doing. So that's 00:17:27.430 --> 00:17:31.960 good. And then, you know, I think it's the article says there are just regular 00:17:31.960 --> 00:17:32.760 old custodians. 00:17:34.070 --> 00:17:38.050 Yeah, exchanges, for example, hosted wallets, that kind of stuff. 00:17:40.460 --> 00:17:45.080 So what's the idea here? Do you just want to get to the point of the article, I 00:17:45.080 --> 00:17:45.760 guess, at this point? 00:17:46.360 --> 00:17:51.780 I'm not sure if it's making a very explicit point here. I think it's saying you 00:17:51.780 --> 00:17:57.040 could have a number of custodians in the thousands or tens of thousands. If you 00:17:57.040 --> 00:17:59.660 have that many different custodians, then at least there's lots of choice in the 00:17:59.660 --> 00:18:04.100 market and people can move between them. And then it would fit with the current 00:18:04.100 --> 00:18:05.000 transaction counts. 00:18:05.160 --> 00:18:10.400 I think if you do some back of a napkin math, the 00:18:11.560 --> 00:18:17.300 idea sort of is that if you have a lot of custodians that suck a little bit 00:18:17.300 --> 00:18:22.450 less and they are connected through Lightning, then you can actually get to the 00:18:22.450 --> 00:18:28.070 point where Bitcoin could support billions of users. So anyone can sort of choose 00:18:28.070 --> 00:18:33.430 the custodian and the trade-offs that they want so that can be a sidechain, it 00:18:33.430 --> 00:18:37.950 can be a Fedimint kind of thing, it can be like you said an actual custodian of 00:18:37.950 --> 00:18:42.710 an exchange. And these custodians in general would talk with each other over 00:18:42.710 --> 00:18:48.340 Lightning. So then you can sort of do the math of how many on-chain 00:18:48.340 --> 00:18:53.200 transactions that would require per custodian and how many custodians we need. 00:18:53.340 --> 00:18:57.780 And that would sort of get us to billions of users, right? I think that's kind of 00:18:57.780 --> 00:19:03.140 the summary of the article. That's sort of considering the trade-offs that we're 00:19:03.140 --> 00:19:09.020 dealing with. That's maybe the most... viable vision right now. 00:19:09.020 --> 00:19:13.860 Yeah, though my concern with custodians is that, generally in economics you get 00:19:13.860 --> 00:19:19.020 this power law distribution of one or two massive custodians 00:19:19.020 --> 00:19:24.800 and then you know 10 000 very small ones, and my issue is not with those 10 000 00:19:24.800 --> 00:19:28.840 very small ones but with those very big ones that could have some pretty undue 00:19:28.840 --> 00:19:31.850 influence over the whole protocol, and of course… 00:19:31.850 --> 00:19:35.710 Can you explain what you mean by that? Well so what's your what's your concern? 00:19:36.610 --> 00:19:41.270 I mean, I don't know, if somebody owns and controls, you know, 50% of all the 00:19:41.270 --> 00:19:46.790 Bitcoin, and they can do all sorts of shenanigans, right? If there's a fork, they can... 00:19:46.790 --> 00:19:47.690 What kind of shenanigans? 00:19:47.850 --> 00:19:49.350 I don't know, like, SegWit2x. 00:19:51.210 --> 00:19:51.950 Can they, though? 00:19:53.580 --> 00:19:55.820 So spell it out. Spell it out. I want to hear the concern. 00:19:55.880 --> 00:20:00.640 Well, so in this case, we remember from the 2017 situation where there was a 00:20:00.640 --> 00:20:02.860 bunch of companies that got together and said, hey, we're going to double the 00:20:02.860 --> 00:20:05.500 block size and we're just going to tell our customers, at least that was the 00:20:05.500 --> 00:20:09.680 initial plan, we're going to tell our customers that Bitcoin didn't change. We 00:20:09.680 --> 00:20:13.920 just upgraded it, even though they actually just put you on something that would 00:20:13.920 --> 00:20:15.040 be considered a hard fork. 00:20:16.970 --> 00:20:21.170 At the time, there were not that many people running nodes. But if you look at 00:20:21.170 --> 00:20:24.310 probably the ratio of people running nodes versus people using these custodians, 00:20:24.550 --> 00:20:29.790 that's probably going to get worse in this far future. Where even more people are using— 00:20:29.800 --> 00:20:30.860 Yes, exactly, yes. 00:20:31.310 --> 00:20:35.130 And presumably, they're also going to be more competent because I think one of 00:20:35.130 --> 00:20:38.610 the reasons SegWit2x didn't work out is because they just couldn't get the 00:20:38.610 --> 00:20:43.310 software working. Now, that might change if the whole world is using Bitcoin. 00:20:43.310 --> 00:20:47.660 Hopefully, there'll be far more competent people. Well, hopefully in the sense 00:20:47.660 --> 00:20:51.220 that it'll be good for Bitcoin, but not hopefully in the sense that these very 00:20:51.220 --> 00:20:57.060 competent people will be working for those companies. Because they're paying the money. 00:20:58.320 --> 00:21:00.000 So, yeah, I'm basically worried about... 00:21:00.000 --> 00:21:01.460 The point here, though, is... 00:21:01.460 --> 00:21:05.460 If you're not validating the rules, then it seems much, much easier. If 99% of 00:21:05.460 --> 00:21:10.590 users are not holding their own UTXOs and are not validating blocks, 00:21:10.930 --> 00:21:15.730 then, yeah, 1% is going to notice the hard fork. Then all you have left is 00:21:15.730 --> 00:21:21.530 hopefully that this minority rule thing works, that that 1% is often 00:21:21.530 --> 00:21:22.970 enough to stop the fork. 00:21:23.490 --> 00:21:28.910 Well, no, not exactly. So I think the better way of understanding this 00:21:28.910 --> 00:21:34.730 vision, so to say, is we are keeping the block size limited 00:21:34.730 --> 00:21:39.290 explicitly so that people can still validate the rules. 00:21:40.450 --> 00:21:44.360 Yeah, even if I guess you could say it's true that you could use a custodian, but 00:21:44.360 --> 00:21:48.340 still run a full node right? It's just that your coins are not on it. All you 00:21:48.340 --> 00:21:50.780 know is where your coins are maybe within the custodian 00:21:50.780 --> 00:21:56.480 Right, so you still know that there are only 21 million coins. Now I guess 00:21:56.480 --> 00:22:01.890 the the more realistic risk 00:22:01.890 --> 00:22:06.030 which is or the risk that I would be more concerned about which is also mentioned 00:22:06.030 --> 00:22:12.020 in the article is more like fractional reserve kind of problems. So there's 00:22:12.020 --> 00:22:16.180 still only 21 million Bitcoin that can change that. You're still validating that. 00:22:16.180 --> 00:22:21.720 However, you're not sure that the custodian that you are trusting is really 00:22:21.720 --> 00:22:27.480 holding the coins that it says it's holding and it's not issuing more. Now that 00:22:27.480 --> 00:22:32.420 can maybe be because you can choose your custodian, that can maybe be sort of 00:22:32.420 --> 00:22:36.820 tackled with proof of reserves or that kind of stuff which is not perfect but 00:22:36.820 --> 00:22:40.820 it's at least better than nothing. And that's how you can sort of keep them in 00:22:40.820 --> 00:22:45.780 check. And again because you can switch custodians whatever you want. So that's 00:22:45.780 --> 00:22:50.520 that's sort of I guess my opinion about this is this seems to me like the most 00:22:50.520 --> 00:22:56.340 viable and best vision we have so far. And then hopefully over 00:22:56.340 --> 00:23:00.600 time people can figure things out that are even better. But so far this seems 00:23:00.600 --> 00:23:05.660 like this this can work with the technology that we have today, with our 00:23:05.660 --> 00:23:10.220 knowledge of Bitcoin that we have today, this seems like probably the best vision 00:23:10.220 --> 00:23:12.200 considering all the trade-offs 00:23:12.200 --> 00:23:15.860 Yeah, I mean there's there's one other option which is that you just don't get 00:23:15.860 --> 00:23:20.500 billions of users. You only get a few tens of millions of users, in which case 00:23:20.500 --> 00:23:24.310 you know Bitcoin would not be the global reserve currency but it might be the 00:23:24.310 --> 00:23:28.950 global international trade currency or something like that. In that case you know 00:23:28.950 --> 00:23:32.550 we don't need too many massive technological breakthroughs because it'll work 00:23:32.740 --> 00:23:34.020 right. 00:23:34.020 --> 00:23:39.820 So in that so in that vision, Bitcoin is kind of the currency you use when the 00:23:39.820 --> 00:23:44.140 other things don't work. You would usually just use PayPal, except if you want to 00:23:44.140 --> 00:23:44.960 buy drugs then… yeah 00:23:44.960 --> 00:23:48.420 Or maybe slightly better than that. Maybe it is the preferred currency if you're 00:23:48.420 --> 00:23:52.480 doing international trade say outside you know from Europe to America something 00:23:52.480 --> 00:23:57.440 like that but… I don't know if that's even likely. I mean, that is an option. 00:23:58.280 --> 00:24:02.600 Nobody says that billions of people want to use Bitcoin, maybe. It doesn't need 00:24:02.600 --> 00:24:07.760 that many users. Though I would prefer, if we do have a way to support the entire 00:24:07.760 --> 00:24:08.440 world population. 00:24:10.160 --> 00:24:13.480 But so far, I don't really see a way to do that other than, yeah, I guess what's 00:24:13.480 --> 00:24:16.420 described here, but that's not a very satisfactory solution. 00:24:16.680 --> 00:24:21.240 I mean, it's not perfect, but it's good to have at least an idea of how you can 00:24:21.240 --> 00:24:22.700 scale if we need to, right? 00:24:22.900 --> 00:24:23.020 Yeah. 00:24:23.440 --> 00:24:25.040 That's what I think anyways. 00:24:25.300 --> 00:24:28.900 So I'm just hoping for a big breakthrough and maybe that's not unreasonable. 00:24:28.920 --> 00:24:31.800 Maybe in the next couple of decades, somebody comes up with a way to say, okay, 00:24:31.980 --> 00:24:35.380 we can add two more zeros to the number of users and now we're good. 00:24:38.090 --> 00:24:43.670 Finally, before we end this episode, Anthony Towns lays out 00:24:43.670 --> 00:24:48.590 how to get from here to there. I don't think there's anything particularly 00:24:48.590 --> 00:24:51.630 shocking there. It's kind of what you would expect. 00:24:52.990 --> 00:24:58.010 Yeah, I think what he's describing here is a phenomena that developers only fix 00:24:58.010 --> 00:25:02.690 problems when they become actual problems. So we all know the theoretical things 00:25:02.690 --> 00:25:03.650 that can go wrong with Lightning. 00:25:05.280 --> 00:25:09.080 But until they actually start happening, until Burak, you know, hits the button 00:25:09.080 --> 00:25:14.300 and blows up a bunch of nodes, bugs don't get fixed. So I think what he's saying 00:25:14.300 --> 00:25:17.720 here is that at some point, more and more people start using Lightning, then we 00:25:17.720 --> 00:25:20.980 start running into the bottlenecks, the known ones, but also maybe some 00:25:20.980 --> 00:25:26.530 surprises. And as those gets fixed, well, at some point, we'll also hit the hard 00:25:26.530 --> 00:25:29.150 limits of what these systems can do, you know, as we work through the 00:25:29.150 --> 00:25:33.640 bottlenecks. And then people will jump to the next best alternative. So maybe if 00:25:33.640 --> 00:25:36.660 Lightning becomes too expensive, they'll use Liquid or something like that. 00:25:37.120 --> 00:25:43.000 Yes. I mean, that's sort of what the plan sounds like. Let's run 00:25:43.000 --> 00:25:47.860 into the bottlenecks and then people will find alternatives, right? 00:25:48.280 --> 00:25:51.600 Yeah, exactly. So fee pressure could go up. That can force people to go to 00:25:51.600 --> 00:25:53.620 alternatives or other usabilities could cause that too. 00:25:54.850 --> 00:26:00.440 So that's just a guess of how it could… How the network might scale in practice. 00:26:00.440 --> 00:26:03.420 So not smoothly but more in I guess in bumps and… 00:26:04.540 --> 00:26:08.640 Innovations. I think that's that sort of covers it Sjors, what do you think? 00:26:08.640 --> 00:26:09.640 I think so too. 00:26:09.640 --> 00:26:14.420 So nothing too shocking in this episode, but we still want to give you an episode 00:26:14.420 --> 00:26:19.120 before we take a break, because you're going traveling on holiday Sjors, is that right? 00:26:19.120 --> 00:26:20.040 Probably, yes. 00:26:20.040 --> 00:26:21.940 And then we'll see you when? 00:26:22.440 --> 00:26:25.600 We'll keep you posted. Thank you for listening to Bitcoin 00:26:25.600 --> 00:26:26.300 Explained.