WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode. 00:00:03.980 --> 00:00:07.980 Live from Utrecht, this is the Van Wirdum Sjorsnado. 00:00:08.540 --> 00:00:08.860 Hello. 00:00:09.380 --> 00:00:14.220 [imitates tornado warning] That's my impression of a tornado warning. 00:00:14.720 --> 00:00:15.200 Oh, okay. 00:00:15.740 --> 00:00:17.180 That's probably how they sound, right? 00:00:17.360 --> 00:00:18.340 I don't know, I've never heard one. 00:00:18.500 --> 00:00:21.520 Me neither. Sjors, we're going to make a podcast. 00:00:21.940 --> 00:00:22.300 Yes. 00:00:22.760 --> 00:00:26.540 I suggest, since this is our first episode, we first introduce ourselves. 00:00:27.120 --> 00:00:27.480 Sure. 00:00:27.680 --> 00:00:28.420 Who are you, Sjors? 00:00:28.580 --> 00:00:32.600 I'm Sjors. I work on Bitcoin Core and other hobbies. 00:00:34.120 --> 00:00:36.440 I live in Utrecht, as do you. 00:00:37.620 --> 00:00:43.020 Yep, I'm Aaron van Wirdum. I'm the technical editor at Bitcoin Magazine. And what 00:00:43.020 --> 00:00:48.820 we're going to do basically is discuss technical news, technical stuff, Bitcoin 00:00:48.820 --> 00:00:50.120 -related technical stuff. 00:00:50.360 --> 00:00:50.740 Yes. 00:00:51.140 --> 00:00:51.480 Correct? 00:00:52.040 --> 00:00:52.560 Sounds right. 00:00:53.230 --> 00:00:55.550 I think we can just start then. 00:00:55.950 --> 00:00:56.530 All right. 00:00:57.030 --> 00:01:02.640 So we got two topics this episode. See how that goes. First topic is the... 00:01:03.270 --> 00:01:07.250 Well, there wasn't apparently an official name for it or if there was we couldn't 00:01:07.250 --> 00:01:08.830 find it but the Fee Burning Bug? 00:01:09.070 --> 00:01:10.330 Yeah, we call it the Fee Burning Bug. 00:01:10.350 --> 00:01:11.410 That's how we're calling it, right? 00:01:12.700 --> 00:01:17.680 So that was a big issue with hardware wallets in particular. 00:01:18.430 --> 00:01:21.310 It is a bit windy here which is fitting for our name. 00:01:21.690 --> 00:01:24.650 Exactly. I'm trying to keep the wind from the microphone. 00:01:25.040 --> 00:01:30.220 So there was a big issue which related to hardware wallets specifically, I think, 00:01:30.760 --> 00:01:36.100 a new bug, or at least sort of new, and the problem was that 00:01:36.710 --> 00:01:42.590 an unknowing victim could overpay in fees and therefore lose money, right? 00:01:42.890 --> 00:01:44.430 That's the synopsis of it. 00:01:44.590 --> 00:01:49.320 Okay, so let's start from the beginning. What is this bug? How does it happen? 00:01:49.760 --> 00:01:53.060 Well, we can go back a little bit further in history to talk about a similar bug, 00:01:53.260 --> 00:01:58.960 which people thought was completely fixed, but it wasn't. So if you have a 00:01:58.960 --> 00:02:03.440 Bitcoin transaction, it has... a bunch of inputs that you're spending from, and 00:02:03.440 --> 00:02:05.860 it has a bunch of outputs that you're spending to. 00:02:06.460 --> 00:02:10.080 Yeah, so the inputs are basically the addresses, your addresses that you're 00:02:10.080 --> 00:02:13.600 sending the coins from, and the outputs refer to the addresses that you're going to, right? 00:02:13.600 --> 00:02:17.260 Yeah, assuming Luke Dashjr isn't listening to that first part, what you said, but 00:02:17.260 --> 00:02:17.920 basically. 00:02:18.960 --> 00:02:19.380 Right. 00:02:20.960 --> 00:02:23.500 I'm simplifying a bit. That's sort of my job, right? 00:02:23.560 --> 00:02:27.120 But one thing that, you know, if you use a wallet, you'll see in a transaction is 00:02:27.120 --> 00:02:30.880 a fee. But actually, if you look at the transaction on the blockchain, there's no 00:02:30.880 --> 00:02:35.540 such thing as a fee in the transaction. It's just a difference between the inputs 00:02:35.540 --> 00:02:36.080 and the outputs. 00:02:36.440 --> 00:02:39.940 Yeah, so there's more coins going into the transaction than coming out of the 00:02:39.940 --> 00:02:44.580 transaction, essentially. And that difference is something the miner can claim as a fee. 00:02:44.720 --> 00:02:48.930 And the other thing is that a transaction output will say the amount. So the 00:02:48.930 --> 00:02:53.530 transaction output might say, here's one BTC, but an input does not. An input 00:02:53.530 --> 00:02:57.650 just says, take this previous transaction and spend it. And it's up to you, 00:02:57.750 --> 00:03:01.730 again, to figure out how much that was, because it would be a waste of space to 00:03:01.730 --> 00:03:03.570 put the amount in the blockchain twice. 00:03:05.430 --> 00:03:06.190 Here's the problem. 00:03:06.370 --> 00:03:09.410 The amount was already in the blockchain from the previous transaction. You're 00:03:09.410 --> 00:03:12.890 just spending the coins from that transaction, and the only thing you really need 00:03:12.890 --> 00:03:16.470 to know is the new amount, because then the difference, you know, you can just 00:03:16.470 --> 00:03:18.890 look at a previous transaction, usually at least. 00:03:19.150 --> 00:03:23.270 Yeah, and so when you make a new transaction, when you have a wallet, say the 00:03:23.270 --> 00:03:28.810 Bitcoin Core wallet, you enter a destination and an amount, and then what it's 00:03:28.810 --> 00:03:32.790 going to do is it's going to look for coins, those are inputs basically, that add 00:03:32.790 --> 00:03:37.140 up to at least the amount you need to spend, and then it adds a change to go back 00:03:37.140 --> 00:03:40.920 to you. And that's fine because you're doing all the work and your wallet can 00:03:40.920 --> 00:03:45.580 check it. But now let's say you want to be safe and you want to put your private 00:03:45.580 --> 00:03:50.240 keys not on your computer, but you want to put them on a hardware wallet. 00:03:52.590 --> 00:03:56.930 So then what happens is your computer produces a transaction without a signature, 00:03:57.150 --> 00:04:01.520 gives it to the hardware wallet and says, go and sign this thing, please. Now, 00:04:01.600 --> 00:04:06.340 the hardware wallet will look at it and say, okay, these are the outputs. I can 00:04:06.340 --> 00:04:09.580 read that. But what about those inputs? I know nothing about them. 00:04:10.360 --> 00:04:13.700 The hardware wallet has no idea about the inputs because the hardware wallet has 00:04:13.700 --> 00:04:15.260 no idea about the blockchain overall. 00:04:15.640 --> 00:04:17.260 Exactly, unless you tell it about it. 00:04:17.700 --> 00:04:17.840 Right. 00:04:18.120 --> 00:04:24.040 So let's say you just lie to the hardware wallet and say, look, you're spending 00:04:24.040 --> 00:04:26.760 these two inputs. They're just half a Bitcoin. 00:04:28.140 --> 00:04:30.920 And, you know, there's almost no fee on this thing. 00:04:32.310 --> 00:04:36.070 Now, the hardware wallet, there's no way to check that. It used to have no way to 00:04:36.070 --> 00:04:40.470 check that. And so it would just sign the transaction. And then, oops, turns out 00:04:40.470 --> 00:04:45.970 you spent one Bitcoin in fees. That's quite annoying. And maybe some malware on 00:04:45.970 --> 00:04:47.210 your computer was doing that to you. 00:04:48.830 --> 00:04:52.730 So the solution to that is that you give the hardware wallet everything it needs 00:04:52.730 --> 00:04:55.240 to check. And so you give it... 00:04:55.240 --> 00:04:59.360 The reason, to hold on one second, the reason you would overpay in fees in that 00:04:59.360 --> 00:05:04.360 scenario is because there would actually be more coins in your inputs than you're 00:05:04.360 --> 00:05:05.400 telling your hardware wallet. 00:05:05.540 --> 00:05:09.000 Exactly. So you might think you're spending half a Bitcoin, but actually the 00:05:09.000 --> 00:05:10.900 coins that you're spending are worth one Bitcoin. 00:05:11.080 --> 00:05:13.600 Right. And the hardware wallet just didn't know that because you lied to the 00:05:13.600 --> 00:05:14.020 hardware wallet. 00:05:14.120 --> 00:05:16.880 The hardware wallet can't tell the difference, so we'll just sign whatever. 00:05:17.240 --> 00:05:18.100 So that's a problem. 00:05:18.420 --> 00:05:18.680 Yes. 00:05:18.840 --> 00:05:19.340 You don't want that. 00:05:19.340 --> 00:05:24.700 But the signature describes... So you're signing a message, essentially, and the 00:05:24.700 --> 00:05:29.120 message is the transaction. And the transaction, or part of the transaction, and 00:05:29.120 --> 00:05:32.520 the transaction contains the inputs that you're spending, namely the transaction 00:05:32.520 --> 00:05:38.050 hash and the position in that previous transaction. And so now 00:05:38.050 --> 00:05:42.690 you could give the hardware wallet the actual transaction that you're spending from. 00:05:43.110 --> 00:05:44.450 The previous transaction. 00:05:44.590 --> 00:05:48.030 Yes, exactly. And that previous transaction, you can look at it and you can check 00:05:48.030 --> 00:05:52.870 the hash. and you can check that the hash matches what's in the input, and you 00:05:52.870 --> 00:05:56.450 can see what the output amounts are. So now you know that you're probably 00:05:56.450 --> 00:06:00.750 spending an actual transaction that wasn't messed with, and you can check the 00:06:00.750 --> 00:06:04.530 amount yourself. So that's basically how it worked. So you would just give the 00:06:04.530 --> 00:06:09.510 hardware wallet all the inputs, and that's fine if it's small, but maybe you're 00:06:09.510 --> 00:06:15.110 spending from a giant exchange payout. multiple kilobyte transaction and 00:06:15.110 --> 00:06:17.790 you maybe you don't have a USB connection 00:06:17.790 --> 00:06:23.510 but you are sending it through a QR code so space could be an issue. A hardware 00:06:23.510 --> 00:06:28.210 wallet is basically a very weak computer and then you have to load all that 00:06:28.210 --> 00:06:31.670 information into the very weak computer and it's a hassle and it can take a lot 00:06:31.670 --> 00:06:35.890 of time if it's a big transaction or a lot of them so that's not ideal for 00:06:35.890 --> 00:06:36.570 hardware wallets. 00:06:36.670 --> 00:06:40.840 Yeah some of them are really really slow. They're using chips that were designed 00:06:40.840 --> 00:06:43.360 in the dark ages, basically. 00:06:43.660 --> 00:06:45.240 It's not really made for this type of stuff. 00:06:45.440 --> 00:06:47.960 No, absolutely not. Anyhow, 00:06:49.600 --> 00:06:55.380 so in came SegWit, and the idea was to say, okay, let's have the signature of the 00:06:55.380 --> 00:07:00.720 transaction not just cover what coin you're spending, so not just the transaction 00:07:00.720 --> 00:07:06.670 hash and the input number, but also the amount that you're spending. And then the 00:07:06.670 --> 00:07:12.510 idea is that if you sign something, you actually add the amount before you sign 00:07:12.510 --> 00:07:18.410 it. And then if somebody lied about the amount, well, then your transaction is 00:07:18.410 --> 00:07:19.750 just going to be invalid on the blockchain. 00:07:20.130 --> 00:07:20.290 Right. 00:07:20.290 --> 00:07:23.730 So the hardware wallet will just sign it because it just sees an amount and it 00:07:23.730 --> 00:07:26.730 says, okay, whatever. I haven't checked that amount because I haven't looked at 00:07:26.730 --> 00:07:30.530 the previous transaction. But I'm going to sign it anyway because if the amount 00:07:30.530 --> 00:07:32.890 is wrong, it's going to be invalid. So I don't really care. 00:07:33.310 --> 00:07:33.550 Right. 00:07:34.160 --> 00:07:39.980 And that's where the attack comes in that was discussed. And 00:07:39.980 --> 00:07:43.800 it wasn't unknown. It just was considered a little bit contrived. 00:07:45.840 --> 00:07:51.820 But here's what happened. Let's say you give... Well, a transaction has two 00:07:51.820 --> 00:07:57.700 inputs. And one of them is half a Bitcoin and the other is half a Bitcoin. 00:07:58.320 --> 00:08:02.970 But you're actually going to lie. your computer is going to lie to your hardware 00:08:02.970 --> 00:08:05.930 wallet, and it's going to say, well, the first one is half a Bitcoin, and the 00:08:05.930 --> 00:08:08.670 second one is just 0.01 Bitcoin, don't worry about it. 00:08:10.150 --> 00:08:13.290 Yeah, so to be clear, the reason your computer would be lying to your hardware 00:08:13.290 --> 00:08:15.210 wallet is because your computer was compromised. 00:08:15.390 --> 00:08:15.650 Yes. 00:08:15.890 --> 00:08:19.590 So, right, the idea behind hardware wallets sort of is that even if your computer 00:08:19.590 --> 00:08:23.310 is compromised, you should be fine, but in this case... 00:08:23.310 --> 00:08:25.290 Well, that's one way to look at hardware wallets, yeah. 00:08:25.930 --> 00:08:30.360 There's some... There are still some attack factors of which is one and there are others. 00:08:30.720 --> 00:08:34.120 If your computer is compromised, you have a very serious problem. But let's say 00:08:34.120 --> 00:08:38.140 somehow the problem is limited to just this little thing that's going to happen now. 00:08:38.440 --> 00:08:41.520 Right, so then your computer is lying to your hardware wallet. So what's the lie? 00:08:41.940 --> 00:08:45.380 The lie is, here's a transaction with two inputs, and I'm going to tell you the 00:08:45.380 --> 00:08:49.300 truth about the first input, and I'm going to lie about the second one. And then 00:08:49.300 --> 00:08:53.060 you're going to sign it, and you're going to sign both inputs, and you're going 00:08:53.060 --> 00:08:56.640 to trust the amounts that you get from the computer. And now, if you were to 00:08:56.640 --> 00:09:00.260 broadcast that transaction, it would be invalid. Because the blockchain would 00:09:00.260 --> 00:09:02.980 look at the first input and it would say, yeah, that's valid. And it would look 00:09:02.980 --> 00:09:08.640 at the second input and say, no, no, no, that's not 0.01 Bitcoin, that's 0.5 00:09:08.640 --> 00:09:13.120 Bitcoin. So I'm not going to do anything with the transaction. But here's the 00:09:13.120 --> 00:09:18.000 problem. What if you send the hardware wallet another transaction, which is the 00:09:18.000 --> 00:09:22.060 opposite, where the first input is a lie. And the second input is actually true. 00:09:22.520 --> 00:09:26.400 And now the hardware wallet will diligently sign that one. And now you can 00:09:26.400 --> 00:09:30.320 actually combine the first and the second transaction, because you can just 00:09:30.320 --> 00:09:33.460 combine, take the input from one, put it on to the other. 00:09:33.800 --> 00:09:38.380 Yeah, so there's two transactions with two inputs. Both are really yours. 00:09:38.820 --> 00:09:44.800 However, your computer is lying to your hardware wallet twice, telling you only 00:09:44.800 --> 00:09:45.740 one of them is yours. 00:09:45.920 --> 00:09:46.220 Exactly. 00:09:46.700 --> 00:09:48.300 The opposite one in both cases. 00:09:48.680 --> 00:09:48.820 Yeah. 00:09:49.810 --> 00:09:54.370 Both times the outcome is an invalid transaction, because the 00:09:54.370 --> 00:09:58.570 input you're being lied about doesn't match what's happening on the blockchain. 00:09:59.130 --> 00:10:03.990 However, with the two invalid transactions, you can both times take the valid 00:10:03.990 --> 00:10:08.490 one, an attacker can both times take the valid half, combine these, and then all 00:10:08.490 --> 00:10:09.910 of a sudden have a valid transaction. 00:10:10.290 --> 00:10:14.490 Yes. So that's how you're circumventing the amount restriction. Yeah, and now the 00:10:14.490 --> 00:10:18.930 question is, how would this lying take place? Well, it would just tell you... 00:10:19.590 --> 00:10:24.230 After you sign the first one, it would say, hey, there's a problem, please try 00:10:24.230 --> 00:10:30.160 again. And it would show the other one. And so that's a very mean trick. So 00:10:30.160 --> 00:10:34.520 then the question is, how do you solve that problem? Well, you go back to 00:10:34.520 --> 00:10:39.820 basically what we had before. You just give it the inputs. Because now the 00:10:39.820 --> 00:10:44.560 hardware wallet sees the actual input transactions and can calculate the hash and 00:10:44.560 --> 00:10:45.500 say, hey, the amounts are... 00:10:45.500 --> 00:10:49.700 Just to be clear about the problem before we move on to the new solution. The 00:10:49.700 --> 00:10:55.410 problem here is that in theory at least because we used a very simplified example 00:10:55.410 --> 00:11:00.610 here with two transactions and half both times but essentially if you really 00:11:00.610 --> 00:11:05.880 pull this attack to the limits you can drain someone's hardware wallet completely 00:11:05.880 --> 00:11:08.040 just with one transaction right? 00:11:08.140 --> 00:11:09.240 Yeah, I guess you could do it three times. 00:11:08.660 --> 00:11:13.380 and just just all inputs are just become a huge fee, and it's all paid as a huge 00:11:13.380 --> 00:11:18.700 fee, and yeah you know it kind of disappears into the blockchain to the miners 00:11:18.700 --> 00:11:19.220 somewhere. 00:11:19.220 --> 00:11:19.640 Yeah. 00:11:20.730 --> 00:11:25.690 So the only way to benefit from this attack is if you are a miner, correct? Like 00:11:25.690 --> 00:11:28.630 you need to be a miner because that's the only way you can get the fee. 00:11:29.030 --> 00:11:33.470 Maybe, or maybe you can blackmail somebody in saying like, okay, now I have this 00:11:33.470 --> 00:11:33.970 transaction. 00:11:34.430 --> 00:11:34.750 Right. 00:11:35.050 --> 00:11:36.930 But I won't send it to the blockchain just yet. 00:11:37.150 --> 00:11:41.210 You better pay me X amount or I'll broadcast this to the network and you'll lose your money. 00:11:41.210 --> 00:11:42.590 Yeah, exactly. Something like that. 00:11:44.100 --> 00:11:48.860 So you never know. In general, there's something called defense in depth. So just 00:11:48.860 --> 00:11:52.960 because you cannot think of a way that this could go wrong, you still want to deal with it. 00:11:53.940 --> 00:11:55.920 Yeah, it's a weakness you want to take care of. 00:11:56.140 --> 00:11:56.300 Yeah. 00:11:57.250 --> 00:11:58.630 Okay, so the solution. 00:11:59.010 --> 00:12:04.050 Well, the solution is we're back to the old story where you have to give all the 00:12:04.050 --> 00:12:07.390 inputs. all the input transactions so you can perform 00:12:07.390 --> 00:12:10.390 you have to you have to provide the previous transactions like before 00:12:10.390 --> 00:12:14.570 yeah so now there is a difference between this in the past in the past before 00:12:14.570 --> 00:12:20.490 SegWit you could fool a wallet with just a single attempt there was no need to to 00:12:20.490 --> 00:12:23.650 ask would you like to try again because you could just lie about the entire 00:12:23.650 --> 00:12:27.590 transaction and right now you have to do this weird trick where you tell the user 00:12:27.590 --> 00:12:32.710 oh something went wrong please sign again right and and so you know 00:12:33.200 --> 00:12:37.800 things weren't as bad as they were before but with this you know the way most 00:12:37.800 --> 00:12:41.340 hardware wallets have fixed this or at least some have fixed this we're kind of 00:12:41.340 --> 00:12:43.500 back in the old situation where you just need to give it the inputs 00:12:43.500 --> 00:12:47.840 yeah so we solved the problem but then it turned out it wasn't really solved it 00:12:47.840 --> 00:12:53.060 was just made a little bit harder to abuse and then to solve it again we're sort 00:12:53.060 --> 00:12:54.520 of back to the original situation 00:12:54.520 --> 00:12:54.940 yes 00:12:54.940 --> 00:12:59.930 all right so now there was some I don't know if controversy is the right word, 00:13:00.010 --> 00:13:01.210 but there was some... 00:13:01.210 --> 00:13:04.650 We can first talk about the even better solution. 00:13:05.310 --> 00:13:06.170 Okay, go on. 00:13:06.890 --> 00:13:10.930 So there is a new proposal called Taproot, which I'm sure we'll talk about in 00:13:10.930 --> 00:13:15.750 another episode. And part of what Taproot will do is, for every input, you have 00:13:15.750 --> 00:13:21.410 to sign the amount, not just of that input, but also of all the other inputs. And 00:13:21.410 --> 00:13:25.490 so, yeah, you can't lie about one input but not lie about the other input. 00:13:25.710 --> 00:13:26.210 I see. 00:13:26.390 --> 00:13:28.870 And I think it's not just the amount. It's a whole bunch of things you're signing 00:13:28.870 --> 00:13:32.250 for about that previous transaction. So you really don't have to provide it anymore. 00:13:32.690 --> 00:13:36.590 So with that approach, you'd sign way more information about this transaction in general. 00:13:37.010 --> 00:13:39.870 I mean, in general, with transaction signing, it's kind of a weird concept 00:13:39.870 --> 00:13:43.890 because the signature is in the transaction. So how does that work? You can't 00:13:43.890 --> 00:13:47.070 sign before you have the signature. So what you do before you sign the 00:13:47.070 --> 00:13:51.750 transaction is where the signature goes, you put a dotted line, so to speak, and 00:13:51.750 --> 00:13:57.670 you sign everything or you sign some parts of it. And you can change 00:13:57.670 --> 00:14:01.600 that scheme a little bit, add a little bit more to it or move things from it. So 00:14:01.600 --> 00:14:03.140 that's what Taproot plans to do. 00:14:03.340 --> 00:14:08.780 But right now, I guess we're sort of drifting in a different topic now, but 00:14:08.780 --> 00:14:14.470 that's fine by me. So right now you indicate which part of the transaction you're 00:14:14.470 --> 00:14:16.290 going to sign, right? With the SIGHASH flag? 00:14:16.590 --> 00:14:16.730 Yes. 00:14:16.890 --> 00:14:20.350 So would Taproot actually make that less flexible then? 00:14:20.830 --> 00:14:25.930 No, I think it just changes the meaning. So SIGHASH_ALL is what most transactions 00:14:25.930 --> 00:14:30.650 use, which is pretty much signing everything about the transaction. And I think, 00:14:30.830 --> 00:14:36.450 so what SegWit added is you're not just signing the content of your own 00:14:36.450 --> 00:14:39.910 transaction, you're also signing something about the inputs, namely the amount. 00:14:40.380 --> 00:14:44.340 And so what Taproot changes would be to sign not just the amount of the previous 00:14:44.340 --> 00:14:48.100 transaction, but a bunch of other things. Probably the script as well. I haven't read it. 00:14:48.360 --> 00:14:53.240 And was this done to solve this specific problem, or are there other problems it solves? 00:14:53.460 --> 00:14:58.100 Maybe. So that comes into why did this thing become an issue again, because this 00:14:58.100 --> 00:15:03.400 was known since 2017. And so I'm not sure. This problem was brought up again on 00:15:03.400 --> 00:15:07.900 the mailing list. And this Taproot solution was brought up on the mailing list. 00:15:09.010 --> 00:15:14.810 My theory is that bringing up the solution for Taproot 00:15:14.810 --> 00:15:18.770 reminded people of the original problem, made other people look at that original 00:15:18.770 --> 00:15:23.670 problem and not agree that it's innocent. They would feel more strongly about it. 00:15:23.910 --> 00:15:29.350 Yeah, because this issue isn't new in itself. Like you said, it was around for 00:15:29.350 --> 00:15:32.630 years. And you think it was just rediscovered? 00:15:33.230 --> 00:15:38.660 Yeah, it was either rediscovered or it was... like somebody proposes this 00:15:38.660 --> 00:15:42.500 solution, and you think, hey, what are you actually solving? Oh, I didn't know 00:15:42.500 --> 00:15:47.300 about that problem. So something like that might have happened. But I'm sure you 00:15:47.300 --> 00:15:52.400 can look it up in the archives. Now, it should be noted that if you can trick a 00:15:52.400 --> 00:15:57.680 user to sign twice, you can also just make them send different funds. 00:15:58.460 --> 00:16:00.400 So even with this fix... 00:16:01.640 --> 00:16:07.560 If I can trick the hardware wallet into signing again, I can just make them 00:16:07.560 --> 00:16:11.220 sign as many transactions as I want. But I can't lie about the amounts of each of 00:16:11.220 --> 00:16:11.840 those transactions. 00:16:13.140 --> 00:16:16.340 But you can still drain somebody's wallet. It's like, try again. Why don't you 00:16:16.340 --> 00:16:21.080 try again? And then you cannot rack up the fees. You would just have them pay you 00:16:21.080 --> 00:16:25.560 twice or pay somebody else twice. So perhaps that's less useful as an attack. 00:16:28.890 --> 00:16:34.070 If you can't lie about anything... then you're sending money to an exchange, and 00:16:34.070 --> 00:16:37.510 now you're sending it to the exchange twice. Well, if it's not the exchange 00:16:37.510 --> 00:16:42.210 that's trying to scam you, but some random malware, the malware doesn't really 00:16:42.210 --> 00:16:45.010 have any benefit from you sending to the exchange twice. 00:16:45.650 --> 00:16:46.170 Right. 00:16:46.430 --> 00:16:48.350 So it's perhaps a less useful attack. 00:16:49.220 --> 00:16:52.020 Right. But it would be sending different coins still. 00:16:52.100 --> 00:16:57.630 Yes. You would just have a brand new transaction. New inputs. different change 00:16:57.630 --> 00:17:00.610 address maybe even. But your hardware wallet only says, would you like to send 00:17:00.610 --> 00:17:05.490 this much to this address? And if it says that twice, you might just click OK 00:17:05.490 --> 00:17:06.990 twice. You don't even think about it. 00:17:07.150 --> 00:17:12.740 Yeah, yeah. Right, I see. So there was some incompatibility with 00:17:12.740 --> 00:17:15.020 some wallets after this upgrade, right? 00:17:15.180 --> 00:17:20.580 Especially BTCPay Server. They have a way to receive money on hardware wallets. 00:17:20.760 --> 00:17:24.660 That's not affected. But they also have a way to then send money from your 00:17:24.660 --> 00:17:29.240 hardware wallet using BTCPay Server. And the problem is, if you need to provide 00:17:29.240 --> 00:17:32.840 the actual input transactions, you need to still have those input transactions. 00:17:33.120 --> 00:17:38.540 And BTCPay Server doesn't have them. So it would have to... Basically, those 00:17:38.540 --> 00:17:42.400 transactions are sitting somewhere in the blockchain, and BTCPay Server at the 00:17:42.400 --> 00:17:46.100 moment doesn't have a way to just go in and get an arbitrary transaction from the blockchain. 00:17:46.300 --> 00:17:46.540 Right. 00:17:46.720 --> 00:17:49.940 But not all wallets have that problem. For example, the Bitcoin Core wallet, I 00:17:49.940 --> 00:17:54.320 believe it keeps the transactions that it cares about inside the wallet itself. 00:17:54.320 --> 00:17:55.220 Even if it's pruned. 00:17:55.300 --> 00:17:55.960 Even if it's pruned. 00:17:56.060 --> 00:17:56.260 Right. 00:17:56.380 --> 00:18:02.360 Exactly. And web-based wallets, they will just ask the server to please give that 00:18:02.360 --> 00:18:03.840 transaction, so that's not a problem either. 00:18:04.240 --> 00:18:08.380 So it's mainly a problem for pruned types of wallets, because they need previous 00:18:08.380 --> 00:18:10.320 transactions, which they don't have in order. 00:18:10.320 --> 00:18:15.860 Yeah, I would say it's a problem for not wallets, basically, so they aren't used 00:18:15.860 --> 00:18:21.280 to holding on to information. They just try to serve the wallet, sign things on 00:18:21.280 --> 00:18:25.360 the fly. They're key managers, but they don't hold on to transactions, maybe. 00:18:26.100 --> 00:18:29.680 It's not fundamentally unsolvable, but I can imagine it's painful. 00:18:29.960 --> 00:18:31.180 It's unsolved, at least. 00:18:31.460 --> 00:18:33.530 Yeah, I mean... At least for BTCPay Server. 00:18:33.550 --> 00:18:34.950 There's no solution ready yet. 00:18:35.650 --> 00:18:36.870 At least not for BTCPay Server. 00:18:37.590 --> 00:18:37.730 Right. 00:18:38.010 --> 00:18:42.530 But in principle it could be fixable because if BTCPay Server uses Bitcoin Core 00:18:42.530 --> 00:18:47.310 indirectly and Bitcoin Core has a transaction index turned on, it'll just work. 00:18:47.770 --> 00:18:51.770 Or if you store the block height, that also helps. 00:18:52.350 --> 00:18:54.370 So do you think the fix was worth it? 00:18:57.140 --> 00:18:58.320 What's your opinion, Sjors? 00:18:58.480 --> 00:19:04.060 The problem is slightly overrated, but it's other people's money too. And so... 00:19:04.220 --> 00:19:07.840 The problem, of course, is if you're using a hardware wallet and you don't like 00:19:07.840 --> 00:19:12.480 this choice, but you've upgraded the hardware wallet, you're kind of screwed. But 00:19:12.480 --> 00:19:15.240 not really, because at least with Trezor, you can downgrade it. 00:19:16.480 --> 00:19:19.960 If you don't like the solution, of course, you don't get any of the other fixes. 00:19:20.460 --> 00:19:24.440 In fact, it's open source, so you can even just take their latest firmware 00:19:24.440 --> 00:19:27.860 release and undo that one change. And maybe they could add a setting where you 00:19:27.860 --> 00:19:28.940 can turn it off if you want to. 00:19:29.480 --> 00:19:31.780 Or you can just not upgrade, of course. 00:19:32.250 --> 00:19:37.470 But if you were using Trezor with Bitcoin Core and HWI, that's all still 00:19:37.470 --> 00:19:41.790 experimental. But that would break until the new version of Bitcoin Core, which 00:19:41.790 --> 00:19:45.850 compensates for this change. So it's not the end of the world. 00:19:45.950 --> 00:19:48.950 The upcoming version for Bitcoin Core will have a fix for this included. 00:19:49.070 --> 00:19:54.370 Yes. At least if it gets merged, but I think so. So that's either 0.21, which 00:19:54.370 --> 00:19:59.470 comes out November-ish, or 0.20.1, which just comes out randomly. 00:20:00.310 --> 00:20:00.510 Yeah. 00:20:02.330 --> 00:20:03.970 All right, anything else on this topic? 00:20:04.230 --> 00:20:09.330 There's one other way that you could deal with this problem as a hardware wallet, 00:20:09.470 --> 00:20:14.250 which is to remember the inputs you've already signed and warn the user, hey, 00:20:14.410 --> 00:20:20.010 wait a minute, I've seen this input before, but that requires a fair memory on 00:20:20.010 --> 00:20:20.450 the device. 00:20:21.820 --> 00:20:25.660 But maybe if you only remember the last 10 inputs that you signed, maybe it's not 00:20:25.660 --> 00:20:28.560 too bad. It depends on how much memory the device has. Some have very little. 00:20:29.090 --> 00:20:32.530 Yeah, you mean the hardware wallets, right? So hardware would have to remember 00:20:32.530 --> 00:20:33.650 transactions then. 00:20:33.730 --> 00:20:36.550 Would have to remember some of the recent inputs they've signed and say, hey, you 00:20:36.550 --> 00:20:40.130 signed this before, are you sure you want this? 00:20:40.390 --> 00:20:40.690 Right. 00:20:40.990 --> 00:20:42.590 And by the way, the amount changed. 00:20:43.770 --> 00:20:46.250 Yeah, so that would require more memory. 00:20:46.290 --> 00:20:50.390 Perhaps, or at least it requires another software change. There might be ways to 00:20:50.390 --> 00:20:52.990 fool the hardware wallet with that kind of thing, so it's more complexity. 00:20:54.720 --> 00:20:56.980 All right, Sjors, you want to move on to the next topic? 00:20:57.380 --> 00:20:59.660 Yes, let's talk about our favorite topic. 00:21:00.640 --> 00:21:06.480 RBF. Replace by fee. RBF. There was a news blitz in the 00:21:06.480 --> 00:21:11.980 crypto media this week about RBF and how there was a 00:21:11.980 --> 00:21:15.600 vulnerability, major weakness. Bitcoin was hacked. 00:21:15.960 --> 00:21:19.320 Yes, Bitcoin was hacked. That's what we all read. Completely destroyed. Miner 00:21:19.320 --> 00:21:22.010 death spiral to come. End of the world. 00:21:23.070 --> 00:21:27.950 There were news stories about RBF. So let's get into what was this news story 00:21:27.950 --> 00:21:30.370 about. Or maybe we should start with RBF. 00:21:30.470 --> 00:21:31.550 Let's start with RBF. 00:21:31.630 --> 00:21:33.070 What is RBF? What is replace by fee? 00:21:33.170 --> 00:21:39.110 Okay. So basically, when you create a transaction, you don't put it in 00:21:39.110 --> 00:21:42.950 the blockchain. That's not how that goes. You actually send it to other Bitcoin 00:21:42.950 --> 00:21:46.590 nodes. And they send it to other Bitcoin nodes. And everybody sends it to each 00:21:46.590 --> 00:21:51.820 other in a happy circle. And eventually a miner... puts your transaction in a block. 00:21:52.140 --> 00:21:52.460 Hopefully. 00:21:53.300 --> 00:21:58.760 Yeah, or not. And then it's confirmed. Now, the reason why they might want to do 00:21:58.760 --> 00:22:03.270 that is not just because they're nice. it's because they want to make money. 00:22:03.370 --> 00:22:04.710 Most of them are nice, though, aren't they? 00:22:04.930 --> 00:22:08.110 Yeah, I would say so, because in the beginning, transactions paid very little 00:22:08.110 --> 00:22:10.610 fees, pretty much not worth the electricity. 00:22:10.670 --> 00:22:12.850 True, for the first couple of years, yes. 00:22:13.630 --> 00:22:17.870 So yes, miners also have some incentive to keep the network useful, but 00:22:17.870 --> 00:22:22.430 ultimately it's nice if you pay them. And the other thing is, let's say you have 00:22:22.430 --> 00:22:25.630 a lot of transactions, and they're competing for space, and now a block is full. 00:22:27.660 --> 00:22:31.680 Or, it's not full, but basically the miner has more transactions to choose from 00:22:31.680 --> 00:22:37.550 than he can fit in the block. What do you do? Well, if transactions 00:22:37.550 --> 00:22:41.630 pay fees, you just start with the highest fee and you work your way down. It's a 00:22:41.630 --> 00:22:44.130 little bit more complicated than that because transactions might depend on each 00:22:44.130 --> 00:22:47.870 other. But basically, that's the rational thing to do. Take the highest paying 00:22:47.870 --> 00:22:51.210 transactions, put them in the block and leave the rest out. 00:22:51.570 --> 00:22:54.670 Yeah, it's a bidding war between transactions in that case. 00:22:54.930 --> 00:22:57.770 Well, yeah, but the bidding is, you know, it's just one bid. 00:22:58.010 --> 00:22:58.350 Right. 00:22:58.650 --> 00:23:02.540 So then the question is, can we make that a little bit smarter? And so you might 00:23:02.540 --> 00:23:06.420 think it's a very quiet day, I'm going to pay the absolute minimum fee, one 00:23:06.420 --> 00:23:10.680 satoshi per byte, and I'm going to send that transaction around, and then all of 00:23:10.680 --> 00:23:15.720 a sudden, I don't know, BitMEX pays its daily user base, 00:23:16.060 --> 00:23:21.660 and the mempool is full, or it's busy, and 00:23:21.660 --> 00:23:25.680 actually your transaction is not going to confirm for hours and hours, and you're 00:23:25.680 --> 00:23:30.810 like, oh, okay, what am I going to do? You increase the fee. Now, this is always 00:23:30.810 --> 00:23:34.590 possible. It's always possible to increase the fee and to send it to other peers 00:23:34.590 --> 00:23:37.970 and to give it to a miner. And then they may or may not... 00:23:37.970 --> 00:23:41.230 To be technically accurate, what you're really doing is creating a new 00:23:41.230 --> 00:23:45.770 transaction, spending the same coins to the same addresses, but with a higher fee this time. 00:23:45.870 --> 00:23:46.170 Exactly. 00:23:46.490 --> 00:23:46.730 Basically, right? 00:23:46.910 --> 00:23:50.910 Yes. You're creating a new transaction that spends the same coins. 00:23:51.070 --> 00:23:53.570 So it sort of overwrites your previous transaction. 00:23:53.850 --> 00:23:57.350 Well, it's different than your previous transaction. And now the question is, why 00:23:57.350 --> 00:24:01.380 would other nodes and miners care about that? Now, other nodes might not care 00:24:01.380 --> 00:24:05.400 about it at all. And so initially, I think the default was that they would just 00:24:05.400 --> 00:24:09.780 ignore it. Because for them, other nodes, there's nothing in it to relay your 00:24:09.780 --> 00:24:13.900 transactions. It's just using their bandwidth. So they're not going to do that. 00:24:14.680 --> 00:24:18.380 but you could send it directly to a miner, and the miner might look at this and 00:24:18.380 --> 00:24:21.520 say, well, this new transaction you're sending me pays me more than the other 00:24:21.520 --> 00:24:25.100