WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode. 00:00:19.700 --> 00:00:22.080 Live from Utrecht, this is Bitcoin. 00:00:22.360 --> 00:00:22.920 Explained. 00:00:23.820 --> 00:00:24.420 Hey, Sjors. 00:00:25.260 --> 00:00:25.500 Yo. 00:00:25.960 --> 00:00:26.560 Hey, Ruben. 00:00:26.920 --> 00:00:27.160 Hey. 00:00:27.700 --> 00:00:32.960 Ruben is back. I think last time in Prague, we were all in Prague last week. And 00:00:32.960 --> 00:00:38.220 there I introduced you as our resident funky second layer expert. 00:00:38.560 --> 00:00:39.020 That is right. 00:00:39.320 --> 00:00:43.620 This week we're going to... talk about one of your new proposals, which is 00:00:43.620 --> 00:00:45.260 actually not a second layer proposal. 00:00:45.440 --> 00:00:45.680 True. 00:00:46.200 --> 00:00:48.860 You've promoted to the base chain. 00:00:49.100 --> 00:00:50.860 [unclear] Thank you. 00:00:51.180 --> 00:00:52.500 Welcome to the base chain. 00:00:53.020 --> 00:00:54.620 It's good to be here. Thank you. 00:00:55.180 --> 00:00:57.460 So yeah, we're going to discuss silent payments. 00:00:57.700 --> 00:00:57.840 Yep. 00:00:58.220 --> 00:01:01.580 This is a proposal you made recently, right? 00:01:01.720 --> 00:01:03.680 Yeah, it's a recent proposal, yeah. 00:01:03.920 --> 00:01:07.980 Yeah, so you proposed this a couple months ago, but I think the general idea is 00:01:07.980 --> 00:01:13.080 also older, right? Very old. It's based on an old idea called stealth addresses, 00:01:13.360 --> 00:01:15.820 I think, originally proposed by Peter Todd years ago. 00:01:15.940 --> 00:01:16.520 Yeah, 2014. 00:01:16.860 --> 00:01:21.610 Right. And this is... improvement on that, an iteration on that? How would you 00:01:21.610 --> 00:01:22.210 describe that? 00:01:22.370 --> 00:01:26.330 Yeah, you could say that. So the interesting thing is that the original proposal, 00:01:26.610 --> 00:01:31.890 I think the idea is kind of old, but the downside of this 00:01:31.890 --> 00:01:35.970 version is that you have to do a lot of work, essentially, to recognize that you 00:01:35.970 --> 00:01:36.450 got paid. 00:01:36.530 --> 00:01:37.230 Of your version. 00:01:37.330 --> 00:01:42.390 Yes. And I think in the past, it's not like people didn't think of that, but at 00:01:42.390 --> 00:01:46.710 the time, it seemed like that was going to be too much work. And Bitcoin has 00:01:46.710 --> 00:01:50.050 improved a lot over the years. So actually I think sort of like that that 00:01:50.050 --> 00:01:54.270 thinking never got updated. Uh and now we're at the point where we can do uh 00:01:54.270 --> 00:01:59.010 these these kind of the verifications of blockchain quite quickly, right and the 00:01:59.010 --> 00:02:03.750 uh the the library that we use libsecp 25— 20— what— 00:02:03.750 --> 00:02:09.560 256k1 Um, that library is very fast 00:02:09.560 --> 00:02:15.380 now. So basically, it made it more viable than it was back in 2014. 00:02:15.700 --> 00:02:21.700 And for the loyal listeners, we did an episode about libsecp256k1. I 00:02:21.700 --> 00:02:23.320 think it's episode two. 00:02:24.200 --> 00:02:24.760 Really? 00:02:25.120 --> 00:02:25.540 Oh, wow. 00:02:26.630 --> 00:02:31.270 That's short for you. You'll remember everything. Okay, so we can maybe get into 00:02:31.270 --> 00:02:36.900 the comparisons later. But for now, what is the general... idea what's the 00:02:36.900 --> 00:02:38.420 general problem that we're solving? 00:02:38.420 --> 00:02:42.560 Yeah, so kind of a good way of putting it is that generally speaking when you 00:02:42.560 --> 00:02:48.100 want to make a payment you have two options. Someone can give an address and you 00:02:48.100 --> 00:02:52.760 can reuse that address and continually pay that person on the same address. And 00:02:52.760 --> 00:02:57.320 if you do that then you lose all all privacy, because every time you receive a 00:02:57.320 --> 00:03:01.220 payment I know it's your address and then maybe you know Sjors sent some money to 00:03:01.220 --> 00:03:05.870 you and I I can see how many bitcoins you have etc etc Um, so because that's a 00:03:05.870 --> 00:03:10.110 problem generally what we do is let's say Aaron if I want to send you a payment I 00:03:10.110 --> 00:03:13.670 I tell you I say like hey Aaron I want to send you some Bitcoin could you please 00:03:13.670 --> 00:03:16.790 give me an address? And you're sure here's here's an address and every time I 00:03:16.790 --> 00:03:18.370 want to pay you you have to give me that address. 00:03:18.370 --> 00:03:20.630 Well I'll generate a new address every time right? 00:03:20.630 --> 00:03:21.890 That's what you generate a new one 00:03:21.890 --> 00:03:22.970 Yeah ideally a fresh one. 00:03:22.970 --> 00:03:28.520 Yeah, and so, This proposal, silent payments, allows you to 00:03:28.520 --> 00:03:34.260 basically have a single static address and allow me to derive 00:03:34.260 --> 00:03:39.740 an address from that, that nobody can recognize except for you and me. And so 00:03:39.740 --> 00:03:43.640 this makes it basically, it makes it the same process, but now it's 00:03:43.640 --> 00:03:47.000 non-interactive where I don't have to ask you for an address. And that is 00:03:47.000 --> 00:03:51.220 particularly useful when you think of things like donations, where there's a 00:03:51.220 --> 00:03:55.140 cause, the cause posts one single address and everybody goes and donates to that 00:03:55.140 --> 00:03:59.900 cause and no interaction is required. So that is basically the proposal. 00:04:00.100 --> 00:04:03.660 Right. So if I want to accept donations, then I'll post this. 00:04:05.560 --> 00:04:08.820 No, it's a stealth address, but you're not calling it a stealth address. You're 00:04:08.820 --> 00:04:10.460 calling it a silent payment address, right? 00:04:10.580 --> 00:04:13.700 Yes, just to differentiate. But it is essentially a form of stealth address. 00:04:13.700 --> 00:04:18.900 Same idea. So I'm posting this quote-unquote address on my website, and then you, 00:04:19.200 --> 00:04:23.060 Ruben, in this case, can generate new addresses from this? 00:04:23.260 --> 00:04:23.520 Yes. 00:04:23.980 --> 00:04:28.120 And send money there and then somehow I should be able to spend from this address 00:04:28.120 --> 00:04:31.880 that's kind of where the trick comes in that is like how can I spend money from 00:04:31.880 --> 00:04:34.180 addresses that you generated Yes. Okay. 00:04:35.740 --> 00:04:39.800 Ruben, how can I spend money from addresses that you generated? 00:04:40.160 --> 00:04:40.300 Sure. 00:04:41.560 --> 00:04:47.500 Essentially, what we do is we generate a shared secret. Generating a 00:04:47.500 --> 00:04:50.080 shared secret is done by taking two public keys. 00:04:51.300 --> 00:04:56.940 You have a public key, I have a public key. Because we both know one private key, 00:04:57.060 --> 00:05:00.940 you know your private key, I know my private key, we can do this calculation, 00:05:00.940 --> 00:05:02.280 which is basically a multiplication. 00:05:03.520 --> 00:05:08.500 That allows us to generate a number that you know and I know, but nobody else 00:05:08.500 --> 00:05:14.450 knows. And with this number, we can then generate a key that is sort of shared 00:05:14.450 --> 00:05:19.250 between us. So it's a public key. You could set money to that key. But if I were 00:05:19.250 --> 00:05:22.350 to set money to that key, both you and I could spend it. So that's not quite good 00:05:22.350 --> 00:05:26.630 enough. So we add one more step after we have the shared secret, which we turn 00:05:26.630 --> 00:05:31.730 into a shared key. We then add your public key to it. So now it's a combination 00:05:31.730 --> 00:05:37.230 of the shared key plus your key. And that combination is something that only you 00:05:37.230 --> 00:05:40.490 know, because I don't know your public key. I don't know the private key behind 00:05:40.490 --> 00:05:41.010 your public key. 00:05:41.050 --> 00:05:45.770 Okay, that's a lot of information in one go. So let's break it down. 00:05:45.850 --> 00:05:49.210 So what we did was a Diffie-Hellman exchange plus something else. 00:05:49.410 --> 00:05:52.130 Right, exactly. So, Sjors. 00:05:53.010 --> 00:05:53.450 Yes. 00:05:53.930 --> 00:05:58.230 What is a Diffie-Hellman exchange? That's the first part we can break down here, I think. 00:05:58.370 --> 00:06:00.730 So Diffie-Hellman was a famous rapper. No. 00:06:01.770 --> 00:06:02.450 I wish. 00:06:02.630 --> 00:06:08.190 Basically, the idea, it's being used in browsers too, for example, right? 00:06:08.940 --> 00:06:14.800 So when you connect to a website that's secure, they have a public 00:06:14.800 --> 00:06:18.860 key. The website essentially has a public key. And you on your computer generate 00:06:18.860 --> 00:06:23.720 another public key. And you basically tell the web server, hey, here's my public 00:06:23.720 --> 00:06:27.280 key. And then the web server can send you information in secret. And you can send 00:06:27.280 --> 00:06:33.030 the web server information to that secret. And so this really uses 00:06:33.030 --> 00:06:38.930 a very nice mathematical property, which is that if you take a private key 00:06:38.930 --> 00:06:44.550 A and you multiply it by a public key B, that is the same as when you take 00:06:44.550 --> 00:06:47.710 public key A times private key B. 00:06:47.890 --> 00:06:48.830 Yep, right. 00:06:49.090 --> 00:06:52.770 So that means that, well, with Bitcoin we have addresses, which is essentially 00:06:52.770 --> 00:06:57.930 just a combination of a private key and a public key. So if I know my private 00:06:57.930 --> 00:07:03.790 key, obviously, and you know my public key and vice versa, then we can create a 00:07:03.790 --> 00:07:08.230 shared, essentially a shared address, a shared Bitcoin address, where we both 00:07:08.230 --> 00:07:14.090 would own the shared Bitcoin private key and we both would own the Bitcoin shared 00:07:14.090 --> 00:07:18.610 public key. But this would be utterly useless because if either of us sends money 00:07:18.610 --> 00:07:22.630 to that, then either of us can steal that money. We don't want that. 00:07:22.930 --> 00:07:23.490 Yeah, okay. 00:07:24.700 --> 00:07:29.600 I'm following you, but that's also because before we started recording, I had an 00:07:29.600 --> 00:07:35.380 hour to try to understand this. So to summarize this real briefly, 00:07:35.640 --> 00:07:40.060 the Diffie-Hellman exchange, two people have a public and a private key, and then 00:07:40.060 --> 00:07:45.340 multiplying one public key with the other private key gets a secret number. 00:07:46.060 --> 00:07:51.440 Right so and because both persons know their own private key and the other 00:07:51.440 --> 00:07:55.120 person's public key they can both generate this number but no one else can 00:07:55.120 --> 00:07:58.900 generate this number because no one has either no one else has either private key 00:07:58.900 --> 00:08:04.240 yeah okay so from this secret number you could potentially create a Bitcoin 00:08:04.240 --> 00:08:09.480 private you could say that's a Bitcoin private key essentially yeah and have a 00:08:09.480 --> 00:08:14.370 public key and then So basically what you were just saying, Sjors, is you could 00:08:14.370 --> 00:08:18.570 use that like if Ruben wants to send me money, he could use that. 00:08:19.870 --> 00:08:25.830 Well, he couldn't, but he could send me money to that Bitcoin public key. 00:08:26.050 --> 00:08:29.970 And then we both have the first key. So the problem is then Ruben can just take 00:08:29.970 --> 00:08:34.250 the money back. I would have been paid, but I wouldn't because Ruben can claim 00:08:34.250 --> 00:08:34.670 the money back. 00:08:34.690 --> 00:08:35.410 It could be a future. 00:08:35.990 --> 00:08:39.710 So we need to add one more level—level, right? 00:08:39.710 --> 00:08:43.310 It's a reversible payment maybe exchanges would like this right they send money 00:08:43.310 --> 00:08:44.970 and they can take it back just kidding. 00:08:44.970 --> 00:08:48.170 Or you make it a two-step process right where you receive the money on this 00:08:48.170 --> 00:08:51.610 common address and then the other side sweeps it away yeah and once it's 00:08:51.610 --> 00:08:55.330 confirmed but that would mean two transactions for one but we really don't need 00:08:55.330 --> 00:08:55.770 to do that 00:08:55.770 --> 00:09:00.450 Yeah, so I'm I'm I'm not sure if I just made it more confusing for the listener. 00:09:00.800 --> 00:09:05.160 This is the way I understood it. So maybe that helps. So like you you could now 00:09:05.160 --> 00:09:09.480 generate a Bitcoin private key and a public key however if you send money to that 00:09:09.480 --> 00:09:13.080 that's not secure because you can claim the money back. So there's one extra step 00:09:13.080 --> 00:09:15.420 that needs to be taken here what's that extra step? Yeah. 00:09:15.420 --> 00:09:21.360 Yeah, so the extra step is that we take that shared secret that shared key and we 00:09:21.360 --> 00:09:25.200 add the public key of the recipients to that shared key. 00:09:25.200 --> 00:09:30.710 Right, so this is the same public key that I was sharing publicly the silent 00:09:30.710 --> 00:09:36.490 payment thing that I had as a donation address, yeah and we now add the 00:09:36.490 --> 00:09:41.270 shared uh am I no you finish this sentence for me before I say it wrong. 00:09:41.270 --> 00:09:45.430 Yeah, you add the shared key to it, right which is a derivative of the shared secret. 00:09:45.430 --> 00:09:50.050 And in this case when you say adding it to it it's basic it's kind of like 00:09:50.050 --> 00:09:55.550 creating a two out of two multi-sig yes, except we use cryptographic 00:09:56.890 --> 00:10:01.230 tricks it's not actually a two of two it looks like a [unclear] but it's sort of… 00:10:02.140 --> 00:10:04.180 it is kind of like a two of two, right? 00:10:04.340 --> 00:10:09.320 You could think of it in that way. But essentially, basically, we're using the 00:10:09.320 --> 00:10:14.340 fact that you can use elliptic curve cryptography in a way that is basically like 00:10:14.340 --> 00:10:17.960 regular math, where you can take someone's key and you can take someone else's 00:10:17.960 --> 00:10:23.160 key and you add them together. And if you do this with the public keys, the 00:10:23.160 --> 00:10:26.780 private key is also the addition of one private key with the other private key. 00:10:26.940 --> 00:10:32.600 So we have two private keys, essentially. And by adding... By adding those two 00:10:32.600 --> 00:10:37.420 together, we generate a key that only you know, because I know one of the private 00:10:37.420 --> 00:10:41.200 keys if I were to send a payment to you, but I don't know the other one because 00:10:41.200 --> 00:10:41.780 it's your key. 00:10:41.960 --> 00:10:46.380 Right, so the two private keys that we're adding together, to be very clear, are 00:10:46.380 --> 00:10:51.820 the shared secret private key that you were able to generate in combination with 00:10:51.820 --> 00:10:57.750 my public key, and then my actual private key that... corresponds to the public 00:10:57.750 --> 00:11:02.050 key that I posted. So that's the two that we're adding together to create a new 00:11:02.050 --> 00:11:05.630 private key and a new public key. Well, I'm the only one who can create the new 00:11:05.630 --> 00:11:09.670 private key because I'm the only one who has the private key that corresponds 00:11:09.670 --> 00:11:10.490 with my public. 00:11:11.110 --> 00:11:15.390 Maybe I can illustrate it from the other side, which is that if you just 00:11:15.390 --> 00:11:19.630 published your stealth address and we don't use it as a silent payment address, 00:11:19.810 --> 00:11:24.550 if you just publish an address, then anybody can send to it. It would just be a 00:11:24.550 --> 00:11:28.010 regular transaction where you only have the private key and I have the public 00:11:28.010 --> 00:11:32.390 key. The downside of that is that everybody can see what's going on. So what if 00:11:32.390 --> 00:11:36.790 you just add something to this regular address? So you're adding a shared key to 00:11:36.790 --> 00:11:40.290 the regular address, essentially. That might even be an easier way to understand 00:11:40.290 --> 00:11:43.650 it. So we just explain how you make the shared key. Then we say we take a regular 00:11:43.650 --> 00:11:47.170 address or a regular private key. We just add a shared key to it so that nobody 00:11:47.170 --> 00:11:49.230 else in the world can see what's going on. 00:11:50.420 --> 00:11:55.540 Okay, so you, Ruben, you were going to send money to my donation address. Now 00:11:55.540 --> 00:11:59.540 we've tried to explain how that works. We've explained how that works. I hope 00:11:59.540 --> 00:12:01.340 people have been able to follow that. 00:12:01.500 --> 00:12:01.640 Yeah. 00:12:01.940 --> 00:12:04.300 So you're sending money to that address. 00:12:04.480 --> 00:12:04.700 Yeah. 00:12:05.230 --> 00:12:11.050 Now the question is, how do I know that you did that? And how do I actually 00:12:11.050 --> 00:12:16.390 generate the private key that corresponds to that? Because I need to know about 00:12:16.390 --> 00:12:16.810 it, right? 00:12:17.130 --> 00:12:20.990 Yeah. So the first thing you need is you need to know the key that I used in 00:12:20.990 --> 00:12:25.250 order to generate the shared secrets. Because you know your key, obviously. And I 00:12:25.250 --> 00:12:28.470 know your key because it was publicly online or your Twitter profile or whatever. 00:12:29.000 --> 00:12:34.340 And so the key that I use is one of the keys of the inputs in the transaction 00:12:34.340 --> 00:12:38.400 that I create. So if I want to send a payment to you, I create a transaction. The 00:12:38.400 --> 00:12:44.340 transaction has inputs. The inputs have a public key corresponding to them. And I 00:12:44.340 --> 00:12:46.660 know the private key of those keys. 00:12:46.960 --> 00:12:52.840 This is just a Bitcoin private key, public key, just a public key that you were 00:12:52.840 --> 00:12:57.140 using anyways, that has your money on it, right? Okay. Yeah. 00:12:58.100 --> 00:13:02.700 So when I create that transaction, I pick my inputs and that is the key that I 00:13:02.700 --> 00:13:07.060 use to generate the new address that only you can spend. And that is where I sent 00:13:07.060 --> 00:13:11.570 the money. And so the second step, so this is how I make the payment. But the 00:13:11.570 --> 00:13:16.430 second step is for you to recognize that I actually did that. And that is sort of 00:13:16.430 --> 00:13:20.690 the tricky part and sort of the downside, I would say, of this proposal, which is 00:13:20.690 --> 00:13:24.950 that in order for you to recognize that I made a payment, you have to go and 00:13:24.950 --> 00:13:27.970 check every transaction that appears on the Bitcoin blockchain. And you have to 00:13:27.970 --> 00:13:32.330 go and see if it is a payment to you. And the way you do that is basically the 00:13:32.330 --> 00:13:36.110 same way we generated this address. You're also going to generate the address and 00:13:36.110 --> 00:13:41.120 you're going to see… So you're going to take the inputs, you're going to generate 00:13:41.120 --> 00:13:45.580 the shared secrets, add it to your own key, see if the result is one of the 00:13:45.580 --> 00:13:49.680 outputs. And that is how you recognize whether or not you got paid. So it's a lot 00:13:49.680 --> 00:13:54.520 of effort, but the effort is all on the recipient side. And if you're running a 00:13:54.520 --> 00:13:57.720 full node already, it's relatively not a lot more effort. 00:13:57.940 --> 00:14:02.420 So basically every input of every transaction on the blockchain 00:14:02.420 --> 00:14:08.340 could be, as a recipient, could be for you. So, yeah. So that means you 00:14:08.340 --> 00:14:11.800 have to inspect every single transaction that's on the blockchain. And for every 00:14:11.800 --> 00:14:16.140 input of every transaction, you want to add your shared key to it. And then that 00:14:16.140 --> 00:14:20.500 generates an address. And you then see, hey, is this transaction actually 00:14:20.500 --> 00:14:26.390 spending to that address? If so... boom, you just essentially add that address 00:14:26.390 --> 00:14:31.290 to your own wallet, and then it just functions as any other wallet address would function. 00:14:31.470 --> 00:14:37.250 Well, I guess it's already the case that you need to check every transaction to 00:14:37.250 --> 00:14:42.850 see if there's an output for you, right? Yes. So the new part is that you have to 00:14:42.850 --> 00:14:47.270 do some extra calculations to see if the inputs... 00:14:47.630 --> 00:14:51.930 But it's definitely a lot of extra work, right? So normally what you do is when 00:14:51.930 --> 00:14:55.130 you see a transaction, you only care about the outputs. I mean, you care whether 00:14:55.130 --> 00:14:59.170 the transaction is valid at all. That's why you look at the inputs. But... the 00:14:59.170 --> 00:15:02.850 outputs, the only thing your wallet needs to do is look at the scriptPubKey of 00:15:02.850 --> 00:15:07.630 this output, so basically the destination of the output, and then compare it to 00:15:07.630 --> 00:15:12.090 the list of addresses or scriptPubKeys in your own wallet. So that is just 00:15:12.090 --> 00:15:16.790 comparing one list to another list. That's very cheap. But in this new scheme, 00:15:16.850 --> 00:15:22.730 you need to do basically elliptic curve key multiplication on 00:15:22.730 --> 00:15:27.050 every input. And then that gives you an address. So it is significantly more work 00:15:27.050 --> 00:15:28.090 than just looking at a list. 00:15:28.450 --> 00:15:34.310 Yeah. And to give a sort of approximate idea of like how much work that is, 00:15:34.450 --> 00:15:40.370 it is as if you check every signature twice instead of once. That is sort of a 00:15:40.370 --> 00:15:42.290 very rough way of saying it. 00:15:43.310 --> 00:15:48.010 Yeah, so it definitely increases the time you need to verify blocks. But if you 00:15:48.010 --> 00:15:53.430 look at that from the perspective of your node is running, it's already synced, 00:15:53.570 --> 00:15:57.110 and it's just running, then one block comes in every 10 minutes, your node will 00:15:57.110 --> 00:16:01.150 verify that block in a few seconds. So maybe it'll take half a second longer. 00:16:01.650 --> 00:16:06.570 That's fine. The bigger barrier is when you first want to sync the whole node. If 00:16:06.570 --> 00:16:10.070 you want to restore from a backup, things get a little bit more hairy. But I 00:16:10.070 --> 00:16:11.090 think we can get into that later. 00:16:14.320 --> 00:16:18.380 Yeah, that is something actually I would like to get into now, perhaps, because 00:16:18.380 --> 00:16:19.300 so there are… 00:16:19.320 --> 00:16:20.300 Ruben is taking charge. 00:16:21.440 --> 00:16:23.880 Well, I think if we do it later, it's going to be more confusing. 00:16:24.900 --> 00:16:26.960 It's called Bitcoin Explained now. 00:16:27.740 --> 00:16:32.980 Exactly. Yeah. So, There are a couple of things you can do to make this process 00:16:32.980 --> 00:16:37.820 faster. And so as Sjors was saying, once you're at the tip and you're validating 00:16:37.820 --> 00:16:41.380 and a new block comes in, you just have to validate everything. But one of the 00:16:41.380 --> 00:16:44.180 things you can do is there are a couple of things you can do to sort of speed it 00:16:44.180 --> 00:16:49.400 up when you resync a node and you have an address and you want to know if there's 00:16:49.400 --> 00:16:53.920 any outputs that are yours. So the first thing you can do is simply have a 00:16:53.920 --> 00:16:59.780 birthday on your key and say, okay, well, I created this key in, let's say, 2022. 00:17:00.860 --> 00:17:06.740 So let's say January 2022. So from January 2022, I go and I 00:17:06.740 --> 00:17:10.180 check every block. And before that, I don't even bother. So that's one thing you 00:17:10.180 --> 00:17:16.000 can do. Another thing is that this protocol in principle is going 00:17:16.000 --> 00:17:21.960 to only create Taproot outputs. So any transaction that doesn't have any Taproot 00:17:21.960 --> 00:17:25.720 outputs in them can be ignored. And so you don't have to check those 00:17:25.720 --> 00:17:30.750 transactions. Um that is sort of a thing that saves a lot of effort right now 00:17:30.750 --> 00:17:34.870 because we don't have a lot of Taproot transactions yet but you know in time 00:17:34.870 --> 00:17:38.430 eventually everything is going to be a Taproot transaction at least that's the 00:17:38.430 --> 00:17:42.750 hope uh so it's the kind of it's an optimization that helps today but won't help 00:17:42.750 --> 00:17:47.170 tomorrow let's say. Yeah. Um and then the biggest one is that instead of 00:17:47.170 --> 00:17:51.810 validating every transaction from the entire history what you can actually do is 00:17:51.810 --> 00:17:57.140 you can take the UTXO sets and only check those outputs and see if any of those 00:17:57.140 --> 00:18:03.100 outputs correspond to a payment that belongs to you. And the downside of this is 00:18:03.100 --> 00:18:08.040 that you will have no history, so you won't be able to see any outputs that were 00:18:08.040 --> 00:18:13.950 yours and were spent, but you will find all the outputs that were unspent. And it 00:18:13.950 --> 00:18:19.770 also requires a bit more of an additional database that ties 00:18:19.770 --> 00:18:25.750 the inputs that you might require to do this calculation to the UTXO 00:18:25.750 --> 00:18:31.030 and UTXO set. So there's a bit more complexity there, but the benefit there is 00:18:31.030 --> 00:18:35.190 that basically instead of scanning the entire history, you can now just take the 00:18:35.190 --> 00:18:39.450 UTXO set, scan that, and find every unspent output that belongs to you. 00:18:40.780 --> 00:18:46.660 Right, yeah. And then you'd need to somehow get the inputs that... 00:18:47.700 --> 00:18:51.040 That refers to the output. Yeah, okay. 00:18:51.320 --> 00:18:55.780 Yeah, so when you look at how a node is actually built, and Bitcoin Core is built 00:18:55.780 --> 00:18:59.820 in one way, but maybe libbitcoin is built in a very different way, there are 00:18:59.820 --> 00:19:02.820 certain pieces of information that are very easy to access and certain pieces of 00:19:02.820 --> 00:19:06.440 information that are a little bit more work to access, and that can really matter 00:19:06.440 --> 00:19:12.060 with a proposal like this. Because if the information, for example, is sitting in 00:19:12.060 --> 00:19:16.680 your RAM memory, That's very quick to access. If, on the other hand, you need to 00:19:16.680 --> 00:19:21.840 go on a disk, it's very slow to access. And you may have a pruned node. A pruned 00:19:21.840 --> 00:19:25.300 node throws away all blocks. So if you need any information that is in an old 00:19:25.300 --> 00:19:29.440 block, then things get really, really, really slow because either you just can't 00:19:29.440 --> 00:19:32.320 get the information or you'd have to download the block again and then get it. 00:19:33.710 --> 00:19:38.150 So those details matter. And one of the things that I think need to be done when 00:19:38.150 --> 00:19:41.170 you're working on it or you're having other people work on it or you're hoping 00:19:41.170 --> 00:19:42.090 other people work on it… 00:19:42.110 --> 00:19:43.510 There is a pseudonym. 00:19:43.870 --> 00:19:44.830 Is benchmarking. 00:19:45.070 --> 00:19:45.430 Yeah. 00:19:45.570 --> 00:19:48.790 And this benchmarking basically could do things like, okay, we could, you know, 00:19:48.990 --> 00:19:52.590 change the proposal and do a little bit more signature verifications or we could 00:19:52.590 --> 00:19:55.390 change the proposal in some other way, which means we need to do more disk 00:19:55.390 --> 00:19:58.930 reading. And now let's try on the Raspberry Pi, you know, with the real 00:19:58.930 --> 00:20:03.600 blockchain, what performs better, what performs worse. Yeah, that sort of stuff. 00:20:03.600 --> 00:20:09.340 Is this a good time to get into the comparison with the earlier proposals? Yeah. 00:20:09.340 --> 00:20:14.440 Yeah. Okay, so how does this compare to earlier proposals? 00:20:14.440 --> 00:20:20.240 Um, yeah, sure. Um So the the original stealth address proposal 00:20:20.240 --> 00:20:25.940 by uh Peter Todd that one um basically it's quite 00:20:25.940 --> 00:20:31.710 similar but the thing that was different is that because the scanning requirement 00:20:31.710 --> 00:20:37.510 was seen as something that was too much effort. So instead of taking the key from 00:20:37.510 --> 00:20:43.370 the input, the idea was that when you generate a payment, you add an OP_RETURN 00:20:43.370 --> 00:20:46.970 to it. And in the OP_RETURN, you add a key. And then that is the key that is 00:20:46.970 --> 00:20:50.050 being used. And the downside of this... 00:20:50.050 --> 00:20:51.470 Yeah, so in that case... 00:20:53.990 --> 00:20:59.410 The sender's key, in your proposal, the sender's key is actually just the Bitcoin 00:20:59.410 --> 00:21:04.270 key, the one you're using to send money from. In this earlier proposal by Peter 00:21:04.270 --> 00:21:08.530 Todd, there's sort of a special key that's not the same key as the one that's 00:21:08.530 --> 00:21:12.750 used to spend money from, right? And that's included in an OP_RETURN, a bit of 00:21:12.750 --> 00:21:14.550 extra data in the transaction. 00:21:16.120 --> 00:21:21.700 Yeah. And so when you do that, obviously, you add more overhead because now you 00:21:21.700 --> 00:21:27.040 have an OP_RETURN. And the upside from the recipient side, well, it's sort of a 00:21:27.040 --> 00:21:31.210 half upside because one of the upsides is you still have to scan every 00:21:31.210 --> 00:21:33.970 transaction, but now you only have to scan every transaction with an OP_RETURN 00:21:33.970 --> 00:21:34.690 attached to it. 00:21:34.930 --> 00:21:37.070 And you only have to look at that OP_RETURN. 00:21:37.290 --> 00:21:37.530 Yes. 00:21:37.810 --> 00:21:40.890 It's a lot less math than you need to do in your proposal. 00:21:41.170 --> 00:21:45.870 Yeah, and the database lookups and stuff are easier too because you don't have to 00:21:45.870 --> 00:21:51.290 kind of go back and find the input. It's right there in one of the outputs. So 00:21:51.290 --> 00:21:56.660 it's sort of an in-between solution that never really... got popular and I think 00:21:56.660 --> 00:22:00.100 even the BIP itself was never finished, um and I 00:22:00.100 --> 00:22:05.320 Yeah, yeah I guess one of the downsides is it makes transactions bigger because 00:22:05.320 --> 00:22:09.520 now you've got to include an OP_RETURN so you know blocks fill up faster if a lot 00:22:09.520 --> 00:22:11.060 of people do that and fees go up. Yeah. 00:22:11.520 --> 00:22:13.100 There's also a privacy downside. 00:22:13.560 --> 00:22:18.360 Yeah, it's sort of an indicator that it might be a stealth payment, right? 00:22:18.600 --> 00:22:22.520 [unclear] Even though you're not sure, but if it's an indecipherable OP_RETURN, 00:22:22.660 --> 00:22:23.900 then that seems kind of likely. 00:22:24.040 --> 00:22:27.200 Well, it also means that other people looking at the blockchain can see how many 00:22:27.200 --> 00:22:30.980 friends you have. Well, friends, quote unquote. So because the number of 00:22:30.980 --> 00:22:35.410 OP_RETURNs to your stealth address… that's publicly known you know people can 00:22:35.410 --> 00:22:39.050 take can just count them or is it not? But that's only a BIP 47. 00:22:39.050 --> 00:22:42.310 Yeah, yeah, you're you're you're confusing it too now. Yeah, okay, no no, so that 00:22:42.310 --> 00:22:47.150 that's not quite true. Um it is sort of a general you see a bunch of transactions 00:22:47.150 --> 00:22:51.530 without returns and those are all stealth payments but you don't know who those 00:22:51.530 --> 00:22:55.520 payments are going to. And the recipients have to check all those specific 00:22:55.520 --> 00:22:59.460 addresses. So it's sort of an in-between solution where you could say it's sort 00:22:59.460 --> 00:23:04.420 of like my proposal, but instead there's a tag that says, okay, this is a stealth 00:23:04.420 --> 00:23:05.160 payment, right? 00:23:05.660 --> 00:23:07.440 Well, this might be a stealth payment. 00:23:07.540 --> 00:23:11.000 Yeah. Well, I think it's quite obvious, unfortunately. 00:23:11.300 --> 00:23:14.720 Okay, so the OP_RETURN is only indicating that it's a stealth payment and then 00:23:14.720 --> 00:23:17.000 after the OP_RETURN is the shared key? 00:23:17.180 --> 00:23:17.480 Yes. 00:23:17.740 --> 00:23:22.300 Okay. So in that case, you could probably do that with just... combining 00:23:22.300 --> 00:23:28.120 signatures, and then you're pretty much back to your proposal, right? Instead 00:23:28.120 --> 00:23:32.620 of using OP_RETURN, you would just basically use some sort of added, I don't 00:23:32.620 --> 00:23:35.320 know, added key or tweaked key, and you just have to check every key. 00:23:35.860 --> 00:23:39.880 Yeah, yeah, so there's a there's a lot of similarity and I I think the uh the 00:23:39.880 --> 00:23:44.220 stealth address proposal also had the suggestion of adding sort of yet another 00:23:44.220 --> 00:23:48.380 identifier of saying like okay well instead of checking every OP_RETURN we we 00:23:48.380 --> 00:23:53.000 mark it where let's say you know you pick a number between let's say zero and and 00:23:53.000 --> 00:23:58.920 64 or something and so my stealth payment is let's say 64 00:23:58.920 --> 00:24:04.060 exactly so whenever in the OP_RETURN it says number 64 and then there's a public 00:24:04.060 --> 00:24:09.160 key I only check those so it reduces the anonymity set even further but it also 00:24:09.160 --> 00:24:10.600 lowers the scanning requirements. 00:24:11.300 --> 00:24:15.980 Yeah, exactly. Your proposal is a lot of work, but a stealth transaction will 00:24:15.980 --> 00:24:17.940 look exactly the same as any other transaction. 00:24:18.260 --> 00:24:22.100 Yeah. Okay. And then there's, what is it? BIP 47? 00:24:22.420 --> 00:24:23.020 That is correct. 00:24:23.100 --> 00:24:27.660 And that uses the concept of a handshake, I would say. So you publish your 00:24:27.660 --> 00:24:31.840 stealth address or whatever it is, I think. They use a PayNym as a term? 00:24:32.080 --> 00:24:36.180 That is a term that Samourai Wallet uses. And I think Sparrow Wallet has it 00:24:36.180 --> 00:24:39.700 implemented as well. But that is, you know, that's just the implementation. In 00:24:39.700 --> 00:24:40.760 principle, it's BIP 47. 00:24:41.260 --> 00:24:46.580 Yeah. So you publish this potentially public key. And then when you want to send 00:24:46.580 --> 00:24:51.260 somebody money using that, you do an announcement transaction first. So you send 00:24:51.260 --> 00:24:55.760 somebody a simple, you send around a simple, I think you send a OP_RETURN payment 00:24:55.760 --> 00:24:59.700 to that address. Yeah. Something like that that's correct and that all that 00:24:59.700 --> 00:25:04.260 OP_RETURN and address and that OP_RETURN then includes some sort of key uh that 00:25:04.260 --> 00:25:08.640 the recipient now knows okay I now have a new friend and I need to start 00:25:08.640 --> 00:25:12.720 monitoring the following addresses so in this case from one single transaction 00:25:12.720 --> 00:25:17.280 you as the recipient can now generate a whole set of addresses that you just 00:25:17.280 --> 00:25:23.020 monitor as if you got an xpub yeah right and so that's nice the downside 00:25:23.020 --> 00:25:26.800 is in this case of what I said before incorrectly for the other one is now 00:25:26.800 --> 00:25:28.300 everybody can see how many friends you have. 00:25:28.720 --> 00:25:28.800 Yeah. 00:25:28.980 --> 00:25:32.100 Because at this handshake address is going to be a bunch of OP_RETURN 00:25:32.100 --> 00:25:35.060 transactions to that address. So you can count, you know, 00:25:36.400 --> 00:25:39.580 a maximum of the number of friends you have. I guess somebody could pretend that 00:25:39.580 --> 00:25:40.460 they're like five people. 00:25:40.780 --> 00:25:40.980 Right. 00:25:41.340 --> 00:25:43.380 And it adds a little bit of bloat to the blockchain. 00:25:44.270 --> 00:25:49.390 Yeah, so that seems to be the biggest trade-off. Is that right? So your proposal, 00:25:49.550 --> 00:25:55.470 Ruben, doesn't add any extra data to the blockchain. And then the trade-off 00:25:55.470 --> 00:25:59.210 is that the recipient has to do quite a bit of work because it has to check all 00:25:59.210 --> 00:26:04.320 the transactions. While the other proposals in their own ways, they... add more 00:26:04.320 --> 00:26:08.020 data to the blockchain but then it is easier after you've done that and then 00:26:08.020 --> 00:26:09.400 there's more nuances but this is… 00:26:09.400 --> 00:26:12.320 Yeah yeah, well, with the stealth addresses there's still a lot of work to do so 00:26:12.320 --> 00:26:15.240 I think the stealth [unclear] are sort of just old and outdated and I think you 00:26:15.240 --> 00:26:19.660 can just sort of leave those aside but for BIP 47 specifically um yes there is 00:26:19.660 --> 00:26:23.760 not the scanning requirement so so what you said is correct uh for BIP 47 but uh 00:26:23.760 --> 00:26:29.280 to add a little bit to the downsides um so it is also in you know when you create 00:26:29.280 --> 00:26:34.950 this notification transaction you're also spending one of your outputs to create 00:26:34.950 --> 00:26:40.890