WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode. 00:00:07.220 --> 00:00:11.420 Live from Utrecht, this is the Van Wirdum Sjorsnado. 00:00:11.640 --> 00:00:11.960 Hello. 00:00:13.040 --> 00:00:14.480 Sjors, I have amazing news. 00:00:14.660 --> 00:00:15.960 You have amazing news. Tell me. 00:00:16.180 --> 00:00:17.040 Are you ready for this? 00:00:17.220 --> 00:00:18.080 I don't know. 00:00:19.520 --> 00:00:23.980 The Van Wirdum Sjorsnado now has its own feed. 00:00:24.220 --> 00:00:25.800 Its own RSS feed. 00:00:25.960 --> 00:00:31.480 Yes. So, in your own podcast app, you can find the Van Wirdum Sjorsnado. 00:00:31.860 --> 00:00:36.200 Or maybe not yet. I think it usually takes a few days for these things to pop up. 00:00:36.360 --> 00:00:39.680 Longer than you would expect. Like it could take up to two weeks maybe even. 00:00:39.700 --> 00:00:45.220 Well, I already signed up for it a week ago. So I think it exists, but I had the URL. 00:00:45.540 --> 00:00:49.740 Yeah, but that's the RSS feed because you're a technical wizard. Most people just 00:00:49.740 --> 00:00:52.080 click subscribe in their podcast app. 00:00:52.280 --> 00:00:53.400 I did it in iTunes. 00:00:53.900 --> 00:00:54.460 Oh, it's there? 00:00:54.720 --> 00:00:55.540 I subscribe directly to the podcast feed. 00:00:55.660 --> 00:00:58.880 Yep. It's there? Okay, it's not in my app yet, but it will show up soon. So we 00:00:58.880 --> 00:01:04.650 have our own... feed this is also for our listeners yep ladies and gentlemen the 00:01:04.650 --> 00:01:07.510 Van Wirdum Sjorsnado has its own feed for you to subscribe to 00:01:07.510 --> 00:01:08.470 yes sir 00:01:09.340 --> 00:01:13.340 Sjors, how do you like reusing addresses 00:01:13.340 --> 00:01:16.120 I love reusing addresses it's amazing 00:01:16.120 --> 00:01:18.300 it's so convenient isn't it 00:01:18.300 --> 00:01:22.000 yeah it just makes you feel like you know your exchange if you're sending the 00:01:22.000 --> 00:01:26.140 money they know everything about you And they like that, right? 00:01:26.360 --> 00:01:29.960 It's so convenient. It's so easy. Nothing to complain about here. 00:01:30.560 --> 00:01:30.920 Absolutely. 00:01:31.180 --> 00:01:32.400 So that was our episode. 00:01:32.680 --> 00:01:33.880 Thank you for listening. 00:01:34.870 --> 00:01:39.090 Okay. Actually, I think everyone will know reusing addresses is a horrible idea. 00:01:39.310 --> 00:01:42.910 Absolutely. You're giving away all your privacy. I guess that's the main problem, 00:01:43.030 --> 00:01:46.250 right? You're just giving away your privacy. I guess in the long run, there's 00:01:46.250 --> 00:01:50.770 maybe some sort of quantum risk, but we mostly care about privacy. You're giving 00:01:50.770 --> 00:01:55.310 away your own privacy and also you're giving away, you're compromising the 00:01:55.310 --> 00:01:58.690 privacy of everyone you're interacting with because if you give away your 00:01:58.690 --> 00:02:03.170 privacy, that means everyone who's paying you, you know, blockchain analysts can 00:02:03.170 --> 00:02:06.990 figure out that they're paying you and do the other way around if you're paying 00:02:06.990 --> 00:02:12.890 people. So it's compromising everyone's privacy. So while it's very 00:02:12.890 --> 00:02:16.580 convenient, it's something we shouldn't be doing. 00:02:16.740 --> 00:02:22.550 Exactly. So that's why most wallets have a button called get new address. And 00:02:22.550 --> 00:02:26.590 some good wallets will actually automatically make a new address whenever you 00:02:26.590 --> 00:02:28.590 even click on receive. Some wallets don't. 00:02:29.780 --> 00:02:34.120 All right. So that works. We need to generate a new address for each payment we 00:02:34.120 --> 00:02:38.260 receive. However, this is a little bit inconvenient as well, isn't it? 00:02:38.620 --> 00:02:39.440 It can be. 00:02:40.890 --> 00:02:46.210 Here's the solution. We need an account system for Bitcoin. Or at least it's 00:02:46.210 --> 00:02:49.410 possible to create an account system on Bitcoin. And it could be useful. 00:02:49.670 --> 00:02:55.550 I think the word account has some negative connotations. But it'd be nice if you 00:02:55.550 --> 00:03:00.550 knew one thing about the other party. And then you can keep sending the money 00:03:00.550 --> 00:03:04.430 while automatically using a new address. I think that's what we want. 00:03:04.990 --> 00:03:10.960 Right. So José Femenías Cañuelo. That's probably 00:03:10.960 --> 00:03:16.720 a severe mispronunciation of his name. But Spanish developer José 00:03:16.720 --> 00:03:21.920 Femenías Cañuelo, he also believes so. He believes Bitcoin would benefit from an 00:03:21.920 --> 00:03:27.620 account system. It's called Easypaysy, which is short for Easy Payment 00:03:27.620 --> 00:03:33.150 System, I think. Easypaysy, and that's what we're going to... discuss today all 00:03:33.150 --> 00:03:38.970 right okay so it's pretty clever and we'll get to possible downsides later but 00:03:38.970 --> 00:03:40.890 let's first just explain how it works yeah 00:03:40.890 --> 00:03:43.910 yeah how does it work because this time you're going to explain how this thing 00:03:43.910 --> 00:03:49.530 works i'm going to do most of the explaining this time all right so To generate 00:03:49.530 --> 00:03:54.850 an account, one of the clever things about this proposal is that it 00:03:54.850 --> 00:03:59.750 uses nothing outside of the Bitcoin blockchain itself, necessarily. There's 00:03:59.750 --> 00:04:05.530 options to that, but we can do it all without any outside of blockchain thing. 00:04:05.830 --> 00:04:10.270 Well, by thing, you don't mean wallets, but you mean there's no communication 00:04:10.270 --> 00:04:14.230 protocol. You don't have to run a server to communicate with the other person. 00:04:14.550 --> 00:04:19.330 Exactly, we generate the account on the Bitcoin blockchain itself, and people can 00:04:19.330 --> 00:04:22.110 find the account on the Bitcoin blockchain itself. 00:04:22.310 --> 00:04:23.930 Okay, so how do I generate an account? 00:04:24.130 --> 00:04:29.670 Right, so an account is basically a transaction. That's in this proposal what an 00:04:29.670 --> 00:04:35.590 account is. And this transaction consists of one input, so 00:04:35.590 --> 00:04:41.300 one address where coins are sent from, but this one input is a 00:04:41.300 --> 00:04:47.080 multisig input, so it has two public keys. It also has one output, which is a... 00:04:47.080 --> 00:04:52.500 What's it called? No... OP_RETURN, sorry. So one OP_RETURN output. 00:04:52.760 --> 00:04:57.280 So you're sending some money from a multisig address that you control yourself 00:04:57.280 --> 00:04:58.400 to... 00:04:58.400 --> 00:05:03.580 vacuum. You're basically sending no money, but you do need to pay a fee. So 00:05:03.580 --> 00:05:06.980 that's the only money that's involved in this transaction. You're not actually... 00:05:07.110 --> 00:05:10.690 spending anything to anyone but you need a little bit of funds to have it 00:05:10.690 --> 00:05:15.370 confirmed so the inputs the input does need to send some money which is the fee 00:05:15.370 --> 00:05:17.390 and then the output receives nothing right 00:05:17.390 --> 00:05:22.430 right and so the reason why we need a Two of two multisig is... 00:05:22.430 --> 00:05:27.090 Yeah, okay. So there's two public keys in there. So these are basically your 00:05:27.090 --> 00:05:30.910 public keys at this point. When you're making this transaction, you're announcing 00:05:30.910 --> 00:05:36.570 to the world, these are my two public keys. One public key is your 00:05:36.570 --> 00:05:42.100 identity public key or... yeah so well one of them is for communication 00:05:42.100 --> 00:05:45.800 anyways I forget there's a term for it which i'm which slipping my mind right now 00:05:45.800 --> 00:05:49.180 but one of them is for communication so if you want to send me some kind of 00:05:49.180 --> 00:05:53.220 message you use this public key which I think is the first of the two like it's 00:05:53.220 --> 00:05:57.560 just in order the first one is for communication and then the second one is for 00:05:57.560 --> 00:06:03.060 value one of the reasons there's two or I think the main reason there's two is 00:06:03.060 --> 00:06:08.870 that one is even more important than the other like if you 00:06:08.870 --> 00:06:13.700 lose your communication key that's a problem, but at least you're not losing 00:06:13.700 --> 00:06:17.380 money. Well, if you lose the value key, you're actually losing money. So what you 00:06:17.380 --> 00:06:22.580 can do is you can put the value key in cold storage in a safe somewhere secure 00:06:22.580 --> 00:06:27.520 while you can still talk with people, communicate with people. So that way, even 00:06:27.520 --> 00:06:32.440 if your computer is compromised and only your communication is compromising, you 00:06:32.440 --> 00:06:35.440 still keep your funds. So that's why there's two, basically. 00:06:35.720 --> 00:06:38.880 Yeah, and it might be worth reminding the listener that, so what you're doing 00:06:38.880 --> 00:06:42.370 here is you're funding your own Or like putting a trivial amount in your own 00:06:42.370 --> 00:06:46.170 multisig address and then immediately spending from that multisig address. And 00:06:46.170 --> 00:06:50.950 the reason you have to do the latter is because you reveal the keys when you're 00:06:50.950 --> 00:06:55.010 spending, not when you're receiving. So in order for the rest of the world to see 00:06:55.010 --> 00:06:57.330 what your keys are, you have to spend from it. 00:06:57.720 --> 00:07:02.180 Right, yeah, that's a good addition. Indeed, when you're spending two, well, 00:07:02.220 --> 00:07:04.200 anyway, no need to repeat. You're right. 00:07:04.780 --> 00:07:08.620 Okay, so then the OP_RETURN message that's in the outputs of this transaction can 00:07:08.620 --> 00:07:11.120 communicate any other piece of information to the world. 00:07:11.810 --> 00:07:15.930 Yeah, you can basically communicate text in this output. So the text we're 00:07:15.930 --> 00:07:21.650 communicating here is a JSON message, and it includes the instructions 00:07:21.650 --> 00:07:26.580 for how to pay to this account. That's the main thing it includes. 00:07:26.940 --> 00:07:28.660 Yeah, I doubt it's actually JSON. 00:07:29.360 --> 00:07:30.420 I thought it was JSON. 00:07:30.680 --> 00:07:34.760 Well, it's some sort of serialized format, probably, that you can convert to JSON. 00:07:36.030 --> 00:07:37.650 Because otherwise it would be very inefficient. 00:07:37.790 --> 00:07:42.570 What José told me is it's a small JSON document. You think that's probably a 00:07:42.570 --> 00:07:43.090 simplification? 00:07:43.390 --> 00:07:47.690 Well, I don't know. I didn't read it in that level of detail. So there's only 80 00:07:47.690 --> 00:07:52.490 bytes available in OP_RETURN. So you could use those 80 bytes to write ASCII 00:07:52.490 --> 00:07:57.010 characters, you know, with an opening bracket and colons and all this stuff. But 00:07:57.010 --> 00:08:00.590 you can also agree on a serialization format that could put way more information 00:08:00.590 --> 00:08:01.590 in a smaller space. 00:08:02.730 --> 00:08:07.970 But you don't need to communicate a lot of data. You just need to... tell people 00:08:07.970 --> 00:08:10.990 which kinds of transactions you're accepting on this account. 00:08:11.270 --> 00:08:15.010 Sure, you can do it inefficient if there's not much data. But if you want more 00:08:15.010 --> 00:08:16.430 data, you can do it more efficiently. 00:08:16.930 --> 00:08:21.210 Okay, fair enough. Well, anyway, so there's three ways of receiving funds on 00:08:21.210 --> 00:08:26.850 these accounts. The first way is not recommended. It's to receive 00:08:26.850 --> 00:08:31.870 payments on your value public key. So now we're back to reusing addresses. We 00:08:31.870 --> 00:08:34.530 don't actually want that, but it's an option. 00:08:35.080 --> 00:08:39.100 it's it's even worse than that I guess because you're announcing hey this is 00:08:39.100 --> 00:08:42.920 where the money is going to the whole world and then it's reusing addresses with 00:08:42.920 --> 00:08:45.640 everyone that you receive money from 00:08:47.100 --> 00:08:50.340 Plus everyone you're not even receiving money from because you've published it. 00:08:50.440 --> 00:08:55.540 It's bad. It's in there because it's just an option for people to use. You can 00:08:55.540 --> 00:09:00.600 choose not to use it, but if we're making this protocol, that was Jose's 00:09:00.600 --> 00:09:06.000 reasoning. We might as well include it for people who do want to use it. It's a 00:09:06.000 --> 00:09:10.660 little bit like donation addresses. Some people do use a donation address which 00:09:10.660 --> 00:09:14.740 is just one address they post on our website somewhere. And anyone can pay to 00:09:14.740 --> 00:09:20.340 this address. So while it's not ideal, it's an option for people that insist on 00:09:20.340 --> 00:09:24.780 compromising their privacy. Okay, what's the other option? Okay, so the one I 00:09:24.780 --> 00:09:29.000 just described was, that's type one. That's how José called it. Then type, no, 00:09:29.080 --> 00:09:34.280 that was type zero, sorry. And then type one is the next option, which uses the 00:09:34.280 --> 00:09:39.970 communication key basically to request 00:09:39.970 --> 00:09:41.330 an address. 00:09:43.000 --> 00:09:44.660 Okay. How do you request an address? 00:09:44.800 --> 00:09:48.840 There's different ways of doing it. You can do it through mail. This is not 00:09:48.840 --> 00:09:49.880 specified in the protocol. 00:09:50.060 --> 00:09:52.520 Okay. So this is where you do need some back and forth communication. 00:09:52.780 --> 00:09:57.300 Yes. Yes. This one is interactive. Yeah. So you can request it through email or 00:09:57.300 --> 00:10:01.440 maybe Signal or maybe some other, maybe, I don't know, snail mail, however you want. 00:10:01.620 --> 00:10:05.360 Okay. But this to me sounds like what we're already doing. We're giving people 00:10:05.360 --> 00:10:06.040 unique addresses. 00:10:06.690 --> 00:10:10.450 Yeah, this is pretty similar to that indeed. So this is just one of the options 00:10:10.450 --> 00:10:13.170 in the account system. It's not all groundbreaking. 00:10:13.530 --> 00:10:18.690 So tell me about this groundbreaking third option before I fall asleep. No, just 00:10:18.690 --> 00:10:19.310 kidding. Keep going. 00:10:20.290 --> 00:10:25.030 Well, one of the... Interesting things here, I would argue, is that you're still 00:10:25.030 --> 00:10:28.930 signing it with your communication key to sort of prove that it's you who's 00:10:28.930 --> 00:10:32.090 requesting the payment, which can come in handy later on. 00:10:32.270 --> 00:10:32.550 Okay. 00:10:32.690 --> 00:10:38.150 Okay, so that was type one. And then type two, this closely resembles stealth 00:10:38.150 --> 00:10:43.290 addresses. So this is where it gets a little bit more complicated. This is where 00:10:43.290 --> 00:10:48.670 the sender of the transaction takes the 00:10:48.670 --> 00:10:54.330 recipient's, so the account holder's value key, And the sender himself 00:10:54.330 --> 00:11:00.190 generates a public key and a private key. He uses his key pair in 00:11:00.190 --> 00:11:05.490 combination with the recipients, the account holder's public key, to generate a 00:11:05.490 --> 00:11:11.310 new key pair. And then he sends the funds to the public key 00:11:11.310 --> 00:11:17.170 or to the address that corresponds to this newly generated key pair. So the money 00:11:17.170 --> 00:11:23.080 is going there. In this transaction, he also includes another OP_RETURN 00:11:23.360 --> 00:11:29.340 in which the public key is included the 00:11:29.340 --> 00:11:34.800 public key he generated himself and with this public key the 00:11:35.280 --> 00:11:41.280 account holder can use this public key to regenerate the new key pair 00:11:41.280 --> 00:11:47.250 and thereby he can spend the funds okay so the way 00:11:47.250 --> 00:11:52.130 this works if you're an account holder is you need to know that this transaction 00:11:52.130 --> 00:11:57.030 happened There's two ways of figuring that out. One of them is that the sender 00:11:57.030 --> 00:12:01.230 just tells you like, hey, I sent you some money, look at that transaction and you 00:12:01.230 --> 00:12:06.170 can use it with the information in the OP_RETURN to generate a private key, which 00:12:06.170 --> 00:12:10.810 you can use to spend the money. Or the account holder just needs to scan the 00:12:10.810 --> 00:12:15.980 blockchain to see if there are any transactions with an OP_RETURN in there. And 00:12:15.980 --> 00:12:20.480 if there is, see if there's information in there that he can use to generate this 00:12:20.480 --> 00:12:24.440 new key pair that actually matches and that actually lets him spend the coins. In 00:12:24.440 --> 00:12:27.540 which case, you know, he just finds money on the blockchain basically. So he 00:12:27.540 --> 00:12:31.360 knows he's been paid. This is a little bit of a hassle, of course, because, you 00:12:31.360 --> 00:12:34.960 know, it requires scanning of the blockchain and all of that. But it is very 00:12:34.960 --> 00:12:40.180 private because even though it's relatively private, because even though the 00:12:40.180 --> 00:12:45.750 value key was revealed in his account, This new money isn't sent to anything that 00:12:45.750 --> 00:12:49.650 anyone can link to the account by just looking at the blockchain. It's sent to a 00:12:49.650 --> 00:12:52.870 completely new address, which even the recipient, the account holder, didn't know 00:12:52.870 --> 00:12:57.310 at first and had to figure out. So therefore, it does offer nice privacy features. 00:12:57.610 --> 00:13:01.250 Yeah, I'd say that's quite nice. The privacy gotcha there that I would think 00:13:01.250 --> 00:13:07.230 about is that when you, as the recipient, you first publish your identifier, 00:13:07.810 --> 00:13:08.610 your account. 00:13:08.850 --> 00:13:13.860 Yeah, so shall I first explain that? And then you get to the privacy gotcha. Like 00:13:13.860 --> 00:13:15.460 what the identifier is. 00:13:16.500 --> 00:13:19.020 Oh, what the identifier is. Yeah, sure. You can do that. 00:13:19.220 --> 00:13:24.180 Right. So how do people find your account? As mentioned, it's just a transaction. 00:13:24.180 --> 00:13:28.580 It's a Bitcoin transaction that's going to be included in the blockchain. So the 00:13:28.580 --> 00:13:32.340 place where it is included in the blockchain, that is the identifier. 00:13:32.660 --> 00:13:35.320 For example, the block height plus the place in the block. 00:13:35.500 --> 00:13:39.640 That's exactly what it is. Not for example, that's exactly what it is. So the 00:13:39.640 --> 00:13:41.420 block height is, I don't know, 00:13:42.940 --> 00:13:44.520 578,000. 00:13:46.160 --> 00:13:47.800 331. I'm just making something up. 00:13:47.940 --> 00:13:51.560 You're one of those old schoolers that still remembers blocks in the 500,000 range. 00:13:52.160 --> 00:13:55.940 No, I think that's what I used in my article when I wrote this. So that's why 00:13:55.940 --> 00:13:59.240 it's still sort of stuck in my hand. I didn't use this exact number, but 00:13:59.240 --> 00:14:03.580 somewhere in the 500k range, I think. Yeah, and then it's like the 00:14:03.580 --> 00:14:09.280 738th in the blockchain, and then... the 00:14:09.280 --> 00:14:14.920 actual account identifier is if I'm recalling correctly it starts with the 00:14:14.920 --> 00:14:20.080 actual actual blockchain so if it's Bitcoin it's like BTC at 00:14:20.780 --> 00:14:26.420 500 whatever number I just used in the 500k range dot 00:14:26.420 --> 00:14:31.240 and then 700 whichever one I just used and then I think there's a slash and 00:14:31.240 --> 00:14:37.180 there's a checksum right so then you have There's an 00:14:37.180 --> 00:14:41.660 identifier, which is based on the place in the blockchain. There are ways where 00:14:41.660 --> 00:14:44.420 you can revert. That's not the right word. 00:14:44.960 --> 00:14:48.920 I think what you were going to say is it's going to convert to some nice mnemonic 00:14:48.920 --> 00:14:51.940 style. So a couple of words like rabbit, big. 00:14:53.820 --> 00:14:57.900 Exactly. Right now I was unable to remember the exact numbers I used, but if I 00:14:57.900 --> 00:15:03.220 would have used a mnemonic in the first place, rabbit, fish, I already forgot. 00:15:03.300 --> 00:15:06.920 Yeah, rabbit, big fish. Whatever it was, that's much easier to remember. 00:15:07.360 --> 00:15:08.080 Yeah, that makes sense. 00:15:08.240 --> 00:15:12.600 So then you can remember it and you can tell people and you don't forget. It's 00:15:12.600 --> 00:15:13.420 much easier to remember. 00:15:13.580 --> 00:15:17.950 And you can go on TV and say, remember, rabbit, big fish. And then people can 00:15:17.950 --> 00:15:21.050 send money to RabbitBigFish. And maybe that's slightly easier than giving them an 00:15:21.050 --> 00:15:26.290 address. Though I'm a little skeptical whether that short name is such a big 00:15:26.290 --> 00:15:30.250 deal. But this is kind of where we get privacy. And also the stealth address 00:15:30.250 --> 00:15:31.090 part. 00:15:31.310 --> 00:15:31.830 Let's hear it. 00:15:33.130 --> 00:15:38.490 The first time you're using this as a recipient, so you're going to create an 00:15:38.490 --> 00:15:43.070 account, you're going to put a transaction on the blockchain. If then later on 00:15:43.070 --> 00:15:47.330 you receive coins, we're going to assume you use this third methodology, the nice 00:15:47.330 --> 00:15:50.950 privacy thing. It's going to arrive on different addresses, so that's very nice. 00:15:51.590 --> 00:15:57.020 But if you're stupid, or if your wallet is stupid, it's going to combine coins 00:15:57.020 --> 00:16:01.230 that are related to that first transaction. The first transaction itself is not 00:16:01.230 --> 00:16:04.750 spendable because it's an OP_RETURN, but maybe it comes from another coin. 00:16:04.930 --> 00:16:05.370 Sure. 00:16:05.650 --> 00:16:08.890 And now you start combining coins and somebody can link your identity to 00:16:08.890 --> 00:16:13.070 everything you received. So you still need to be very wary of this cluster 00:16:13.070 --> 00:16:17.530 analysis. A risk. A new wallet could avoid that and warn you about it. 00:16:17.790 --> 00:16:21.470 No, that's true. You have coins in your wallet which you're going to use to pay 00:16:21.470 --> 00:16:26.210 the fee. You probably have more in your wallet than just the fee. So you have 00:16:26.210 --> 00:16:29.790 change and it's then sort of linked to your account. 00:16:31.820 --> 00:16:36.540 After which the coins can be linked to even the coins you received privately. 00:16:37.940 --> 00:16:40.500 That's something to be aware of, sure. 00:16:40.780 --> 00:16:44.320 So I think it's this initial step where you have to announce something on the 00:16:44.320 --> 00:16:48.280 blockchain that creates this liability almost. Now for some parties, that's 00:16:48.280 --> 00:16:51.640 actually kind of a feature, or at least they can manage it. If you're an 00:16:51.640 --> 00:16:54.840 exchange, you know what you're doing, you're not going to make those privacy 00:16:54.840 --> 00:16:57.560 mistakes. And one of the cool things is that you can... 00:16:59.070 --> 00:17:04.550 Add a DNS record is one of the suggestions so that people can verify that, 00:17:04.890 --> 00:17:10.630 hey, this DNS record matches this big fish thing. And 00:17:10.630 --> 00:17:14.810 that's a nice way to double check. I could imagine hardware wallets could also 00:17:14.810 --> 00:17:19.710 embed some of these well-known codes so that if you're sending to Kraken or 00:17:19.710 --> 00:17:22.790 whatever, Your hardware wallet could say, oh yeah, that's actually an address 00:17:22.790 --> 00:17:26.810 that belongs to that exchange. At least the last time we updated the firmware to 00:17:26.810 --> 00:17:31.170 know these accounts. It's kind of nice against clipboard attacks and that sort of 00:17:31.170 --> 00:17:35.750 stuff. But that's for these schemes in general. I don't think you need to have 00:17:35.750 --> 00:17:39.450 this announcement into blockchain specifically. So if you go to stealth 00:17:39.450 --> 00:17:44.710 addresses, which I believe is BIP47, the mechanism there was slightly different, 00:17:44.870 --> 00:17:48.910 though I might remember it incorrectly. But the idea there is that you generate a 00:17:48.910 --> 00:17:52.390 payment code. which is longer, but it's not something you have to put in the 00:17:52.390 --> 00:17:56.550 blockchain. And so you can give that code to somebody else and that's your 00:17:56.550 --> 00:18:00.170 identity. Right. But that identity is not tied to anything in the blockchain. And 00:18:00.170 --> 00:18:05.290 then you do the same magic trick with somebody takes their own key and adds it 00:18:05.290 --> 00:18:09.790 and does a bunch of math and then sends it to an address. And then I think there 00:18:09.790 --> 00:18:13.330 is an announcement on the blockchain, but it's done by the sender. 00:18:14.950 --> 00:18:15.790 So when... 00:18:15.790 --> 00:18:19.870 It's always done by the sender. Well, at least the payment is... Oh, there's a 00:18:19.870 --> 00:18:21.670 separate announcement from the payment? 00:18:21.890 --> 00:18:25.690 So in the scheme we just talked about in Easypaysy, it's the recipient who has to 00:18:25.690 --> 00:18:28.890 announce their identity on the blockchain essentially once. But then when you 00:18:28.890 --> 00:18:34.070 want to send to them, there's some back and forth. But here in the Stealth 00:18:34.070 --> 00:18:38.790 Addresses scheme, it is the sender that needs to make an announcement on the 00:18:38.790 --> 00:18:43.350 blockchain saying... To a standard address, hey, so they get a payment code and 00:18:43.350 --> 00:18:47.820 they send one transaction to a standardized address, which is always the same 00:18:47.820 --> 00:18:53.620 thing, as a handshake. And then using the handshake, that's how you come up with 00:18:53.620 --> 00:18:58.410 the unique addresses that you're actually going to use. So the recipient will 00:18:58.410 --> 00:19:02.670 watch the handshake address, and every time it sees a transaction on the 00:19:02.670 --> 00:19:06.250 handshake address, it then knows what other addresses it should be watching. 00:19:07.200 --> 00:19:11.990 Right. Okay, so that does require more. blockchain transactions then? 00:19:12.530 --> 00:19:16.890 I don't know about the number of blockchain transactions maybe a little bit but 00:19:16.890 --> 00:19:22.190 the nice thing is that it's the senders that are sort of sacrificing their 00:19:22.190 --> 00:19:26.790 privacy but only really to the recipient and they're doing that anyway because 00:19:26.790 --> 00:19:30.990 they're paying the recipient rather than the recipient revealing it, you know, 00:19:31.070 --> 00:19:35.680 lowering its privacy. But I don't think it's a huge deal and all of these schemes 00:19:35.680 --> 00:19:39.840 you can choose to just do more off-chain. You can just have an identifier that 00:19:39.840 --> 00:19:45.640 you sent via email. And yeah, it's not a short, that's a downside, but it's just 00:19:45.640 --> 00:19:48.080 a public key in that case and you can do fun things with it. 00:19:48.420 --> 00:19:51.320 Right. Well, you want to get into the benefits of this system? 00:19:51.660 --> 00:19:56.720 Well, we did some benefits and some downsides. I would like to remind the 00:19:56.720 --> 00:20:00.220 listeners of a chicken egg problem that was brought up by the infamous 00:20:00.220 --> 00:20:05.940 ZmnSCPxj. Z-man. Z-man, or as the Canadians 00:20:05.940 --> 00:20:06.700 say, Zed-man. 00:20:08.700 --> 00:20:12.440 If you're a new Bitcoin user and you want to use this system, you don't have 00:20:12.440 --> 00:20:18.200 coins to send anywhere. So that's a problem, but there 00:20:18.200 --> 00:20:20.740 might be ways around it, especially if you're buying coins from an exchange. 00:20:20.740 --> 00:20:22.080 Maybe they can help you set it up. 00:20:22.960 --> 00:20:27.920 I want to get into more benefits. I think we skipped over the benefits a little bit. 00:20:28.180 --> 00:20:30.140 I mentioned a few, but give me more. 00:20:30.840 --> 00:20:32.460 Recurring payments. Did we mention that one? 00:20:32.660 --> 00:20:34.000 No, we haven't mentioned that. That's a good one. 00:20:34.220 --> 00:20:38.690 Yeah, so recurring payments. So you want to pay rents every month. So your 00:20:38.690 --> 00:20:42.130 landlord would have to generate a new address every month. 00:20:43.590 --> 00:20:45.510 And wait, why is this a problem? 00:20:46.130 --> 00:20:49.910 Well, you could say it's annoying for the landlord to have to send you an email 00:20:49.910 --> 00:20:51.030 with an address every month. 00:20:51.210 --> 00:20:51.730 Right, exactly. 00:20:52.030 --> 00:20:54.810 And then it's nice if you can generate, if you can predict these addresses 00:20:54.810 --> 00:21:00.550 yourself. Right. But I would immediately say there's a downside to that. Because 00:21:00.550 --> 00:21:06.490 if let's say my landlord has this magic box that he receives his Bitcoin on 00:21:06.490 --> 00:21:11.030 and then his magic box breaks, but he can't give you a phone call to say, hey, 00:21:11.390 --> 00:21:16.570 yo, don't send me any more Bitcoins. Then your rent just goes into the ether. 00:21:17.530 --> 00:21:18.870 Pardon the pun. Yeah. 00:21:19.350 --> 00:21:22.050 He can call you, right? He knows where you live. 00:21:22.600 --> 00:21:24.040 He does know where you live. 00:21:24.400 --> 00:21:25.280 Yeah, he probably does. 00:21:25.400 --> 00:21:30.220 But maybe the postal service is down because of some election issue. So, you 00:21:30.220 --> 00:21:36.040 know, it can be tricky. And more generally, let's say you are a 00:21:36.040 --> 00:21:40.460 very sophisticated recipient of these Bitcoins. Maybe you are a landlord. And 00:21:40.460 --> 00:21:43.940 initially you just have a, you know, you have one tenant that pays rent that way. 00:21:44.100 --> 00:21:48.680 And you just use your little hardware wallet and you generate these addresses 00:21:48.680 --> 00:21:52.390 that way. all is good and well, then you have lots of customers and you have a 00:21:52.390 --> 00:21:57.510 lot of money. Maybe you want to set up a multi-sig cold storage. Oh, but now you 00:21:57.510 --> 00:22:02.890 have to tell all your clients, all your renters to basically use this new payment 00:22:02.890 --> 00:22:08.190 code. So it's nice if you can just give a new address every month, then the 00:22:08.190 --> 00:22:11.270 customer doesn't have to care how you generate that address. You can do it 00:22:11.270 --> 00:22:15.030 yourself. You can have all the sophisticated... address generation methods you want 00:22:15.030 --> 00:22:19.050 sure but here's the thing I think your your argument doesn't hold up because I 00:22:19.050 --> 00:22:24.970 think the idea is that if you're the landlord you can request payment 00:22:24.970 --> 00:22:30.520 each month you just send a message hey, pay me. And then your 00:22:30.520 --> 00:22:35.300 wallets can be programmed to allow this once a month for up to whatever your pay 00:22:35.300 --> 00:22:39.260 is. That way your wallet doesn't need to know all of the addresses into the 00:22:39.260 --> 00:22:44.360 future. It just needs to know, okay, it's okay to pay this amount to this account 00:22:44.360 --> 00:22:46.640 each month whenever they request it. 00:22:46.760 --> 00:22:50.140 But then we really don't need anything in this scheme. Because now what you're 00:22:50.140 --> 00:22:53.380 talking about is saying, okay, our landlord has some sort of public key 00:22:53.380 --> 00:22:58.790 identifier that you somehow... trust on maybe trust on first use could be a PGP 00:22:58.790 --> 00:23:03.490 key or could be some other just a Bitcoin key that your wallet and then there's a 00:23:03.490 --> 00:23:07.790 protocol where your wallet you know where they can request payments from you 00:23:07.790 --> 00:23:12.850 whether that's push based or pull based maybe your wallet is running and it's 00:23:12.850 --> 00:23:16.830 pulling the landlord server every day to say hey do you have an invoice for me do 00:23:16.830 --> 00:23:20.450 you have an invoice for me and then based on some rules you automatically pay it 00:23:20.450 --> 00:23:24.920 I don't I don't think this scheme makes that easier The biggest complication 00:23:24.920 --> 00:23:28.680 there is just the, okay, what does the server look like that you're going to 00:23:28.680 --> 00:23:32.280 ping? What's expected from a wallet? Should it ping every day, every week, every 00:23:32.280 --> 00:23:36.630 month? What if it doesn't? So that is an interesting problem to solve, but I 00:23:36.630 --> 00:23:39.110 think that's almost perpendicular to this. 00:23:39.490 --> 00:23:43.190 Okay, then I think the other big benefit is non-repudiation. 00:23:43.750 --> 00:23:46.830 Tell me, what is repudiation and what is non-repudiation? 00:23:47.470 --> 00:23:51.630 So I don't know what repudiation is, but I can perfectly explain what non 00:23:51.630 --> 00:23:55.910 -repudiation is. So I guess repudiation will be the opposite of that. It means 00:23:55.910 --> 00:24:01.050 that once you've paid someone, you can prove that you've paid someone. 00:24:01.680 --> 00:24:02.200 Okay. 00:24:02.460 --> 00:24:08.120 So you make some sort of order. I don't know. You order to buy a laptop 00:24:08.120 --> 00:24:13.180 or a tea kettle. I'm just pointing at stuff on your desk right now. 00:24:13.420 --> 00:24:14.100 Yeah, a teapot. 00:24:14.740 --> 00:24:19.220 Oh, yeah, that's what it is. That's what you're ordering. And then the seller 00:24:19.220 --> 00:24:24.460 receives the money and after it doesn't ship the order. And then when you 00:24:24.460 --> 00:24:27.380 complain, he says, hey, I never received any money. I don't know what you're 00:24:27.380 --> 00:24:32.000 talking about. I don't know who you are. Go away. At that point, now with 00:24:32.000 --> 00:24:36.300 Bitcoin, once you've sent it to a regular Bitcoin address, you have no way to 00:24:36.300 --> 00:24:38.420 prove that you actually did pay this guy. 00:24:38.700 --> 00:24:40.360 Depending on how you got the address, right? 00:24:41.100 --> 00:24:42.220 I guess, I guess. 00:24:42.240 --> 00:24:44.760 If you got the address on a website and then... 00:24:44.760 --> 00:24:48.900 But I want to solve it on the Bitcoin blockchain. So now we're solving it on the 00:24:48.900 --> 00:24:49.380 Bitcoin blockchain. 00:24:49.380 --> 00:24:51.540 Why do you want to do everything on the blockchain? You sound like an Ethereum 00:24:51.540 --> 00:24:52.000 person. 00:24:53.740 --> 00:24:58.760 I'm trying to make you hear me out because I want to finish my story. Yeah. At 00:24:58.760 --> 00:25:02.720 this point, normally when you're sending an address, that guy can just ignore you 00:25:02.720 --> 00:25:08.580 and claim that he never received a payment. Now, thanks to the brilliance 00:25:08.580 --> 00:25:14.560 of non repudiation, I can take it to court and I can prove to court, look, 00:25:14.680 --> 00:25:19.880 this is his account. Look, I actually made a payment to this account. I can prove 00:25:19.880 --> 00:25:25.140 it. He signed it with this communication key. or this is the stealth address. I 00:25:25.140 --> 00:25:28.920 can prove it in all sorts of ways. And at that point, there's no way for him to 00:25:28.920 --> 00:25:34.100 deny that he got the payment. So now the judge can order him to finally give me 00:25:34.100 --> 00:25:35.700 that laptop or tea kettle. 00:25:36.080 --> 00:25:39.420 Right, or less radical. You can use it in your accounting software. So there's a 00:25:39.420 --> 00:25:43.720 little bit of an extra check that payments actually happened where you think they happened. 00:25:43.900 --> 00:25:45.380 So you do agree there's a benefit now? 00:25:45.560 --> 00:25:50.620 I think in general, there's a benefit of having... receipts, essentially. And 00:25:50.620 --> 00:25:56.380 basically, when somebody sends you an invoice, you really need to have some 00:25:56.380 --> 00:26:01.150 evidence that you really got that invoice. So normally if you send an invoice by 00:26:01.150 --> 00:26:04.890 PDF or via email, it should have the address in it. And that email should be 00:26:04.890 --> 00:26:09.750 signed by something, maybe just the standard email, DKIM, whatever stuff. And 00:26:09.750 --> 00:26:14.310 then the proof of payment really is just that address now has money. But okay, so 00:26:14.310 --> 00:26:15.610 that's all cool. Great. 00:26:16.110 --> 00:26:17.870 Yeah. But there's more. 00:26:18.070 --> 00:26:18.890 There's more, tell me. 00:26:19.130 --> 00:26:22.990 Okay, so actually I got an email from José earlier this month. There's updates to 00:26:22.990 --> 00:26:23.410 the protocol. 00:26:23.770 --> 00:26:27.290 Right, because just for the listener, this protocol was announced in December. 00:26:27.870 --> 00:26:30.090 Then there were some distractions in the world, I guess. 00:26:30.410 --> 00:26:31.190 Oh, last December? 00:26:31.470 --> 00:26:33.750 Yeah. Okay. Now he's back on it. 00:26:33.870 --> 00:26:35.330 I'm going to read the updates to you. 00:26:35.610 --> 00:26:35.810 Okay. 00:26:36.190 --> 00:26:40.310 Okay. Update A. Radical simplification. 00:26:41.620 --> 00:26:46.120