WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode. 00:00:05.550 --> 00:00:08.190 Live from Utrecht, this is the Van Wirdum Sjorsnado. 00:00:08.510 --> 00:00:08.730 Hello. 00:00:09.550 --> 00:00:12.130 Sjors, I heard Bitcoin is broken. 00:00:12.310 --> 00:00:12.950 It is. 00:00:13.110 --> 00:00:13.270 Again. 00:00:13.570 --> 00:00:14.690 Yeah, it was absolutely terrible. 00:00:14.990 --> 00:00:16.030 A double spend happened. 00:00:16.350 --> 00:00:17.050 Yep, ruined. 00:00:17.190 --> 00:00:21.540 And this is because a fatal flaw in the Bitcoin protocol. 00:00:22.140 --> 00:00:22.320 Yep. 00:00:23.150 --> 00:00:25.750 That's how it was reported, I think, in Bloomberg. 00:00:26.640 --> 00:00:30.220 Yeah, I couldn't find the original report by Bloomberg. I think Cointelegraph 00:00:30.220 --> 00:00:33.700 reported it more or less in that way, and then Bloomberg referred to it. 00:00:33.840 --> 00:00:35.240 Oh, yeah, I think that's what happened. 00:00:35.460 --> 00:00:39.280 But at least more recent articles I saw from Bloomberg were saying, oh, noobs 00:00:39.280 --> 00:00:41.780 thought it was broken, and they were all Googling double spends. 00:00:42.140 --> 00:00:43.220 Oh, they corrected it? 00:00:43.360 --> 00:00:47.700 I wouldn't say corrected it. They were more like, you know, going meta on it. 00:00:48.180 --> 00:00:49.700 On their own mistake. 00:00:50.450 --> 00:00:54.230 So I don't know if it was their own mistake because I've only seen the haters 00:00:54.230 --> 00:00:57.090 basically saying that they made that mistake. 00:00:57.550 --> 00:01:01.710 Fair enough. Okay. So to be clear, Bitcoin is not actually broken. 00:01:02.070 --> 00:01:04.820 Nope. It's working as expected. 00:01:05.040 --> 00:01:09.660 It's working exactly as expected. Now we could get into a discussion on whether 00:01:09.660 --> 00:01:12.600 or not the double spend happened or not. And that gets into the definition of 00:01:12.600 --> 00:01:14.740 double spend, but we're not going to do that. Sjors. 00:01:15.000 --> 00:01:15.120 No. 00:01:15.400 --> 00:01:20.930 Instead, we're going to explain what was sort of this alleged. fatal flaw in the 00:01:20.930 --> 00:01:24.310 protocol which was replace by fee RBF 00:01:24.310 --> 00:01:24.810 yes 00:01:24.810 --> 00:01:29.650 that was sort of why this alleged double spend could have happened 00:01:30.170 --> 00:01:31.910 Yeah, it could have happened even without that. 00:01:32.430 --> 00:01:35.870 Sure, yeah. And I guess that's the sort of stuff we're going to discuss in this 00:01:35.870 --> 00:01:37.030 great podcast today. 00:01:37.330 --> 00:01:39.890 Exactly. So stay with us and you'll learn more. 00:01:40.190 --> 00:01:45.850 Okay, first of all, this thing is called replace by fee. Just in brief terms, 00:01:45.850 --> 00:01:47.510 what does it mean? What is replace by fee? 00:01:47.730 --> 00:01:52.010 So it means you have a transaction that might be going from A to B and you're 00:01:52.010 --> 00:01:57.810 paying a fee to the miners and you decide it's taking too long because 00:01:57.810 --> 00:02:03.290 miners... We'll mine the biggest fee first, generally. And so you can send the 00:02:03.290 --> 00:02:07.590 new transaction with the same origin, same destination, if you like, and you 00:02:07.590 --> 00:02:11.530 increase the fee. And then that gets propagated to your peers. 00:02:11.870 --> 00:02:17.190 Yeah, well, now you've already sort of described the use case. If we want to put 00:02:17.190 --> 00:02:22.430 it in more abstract terms, it basically means that if there are conflicting 00:02:22.430 --> 00:02:25.630 transactions, the miner will pick the highest one, right? 00:02:25.970 --> 00:02:29.130 Exactly. So conflicting transactions means spending the same input. 00:02:29.330 --> 00:02:33.030 I said highest one. I mean the transaction with the highest transaction fee. 00:02:33.410 --> 00:02:33.990 Yes, that's right. 00:02:34.230 --> 00:02:39.090 Yeah. So you just described one use case. You're sending a transaction and it's 00:02:39.090 --> 00:02:42.950 taking too long to confirm. So you send a new transaction with a higher fee. 00:02:43.250 --> 00:02:48.170 Yeah. And that's a very reasonable use case. You're sending a transaction with 00:02:48.170 --> 00:02:51.710 maybe one Satoshi per byte because you're not in a hurry. But then after a couple 00:02:51.710 --> 00:02:55.610 of days, you're like, okay, this is ridiculous. And you bump it to 100 Satoshi 00:02:55.610 --> 00:02:57.530 per byte, and it goes in the next block. 00:02:57.790 --> 00:02:59.130 Yeah, or after a month. 00:03:00.070 --> 00:03:03.290 Right now we have transactions in the mempool that have been there for a month 00:03:03.290 --> 00:03:06.370 that pay one satoshi. This is the first time ever I think this has happened. 00:03:06.710 --> 00:03:12.390 Okay. So fee market is working, which is the next point I want to make. This is 00:03:12.390 --> 00:03:18.010 another argument in favor of replace by fee. Is that it actually allows for more 00:03:18.010 --> 00:03:20.110 effective fee markets to happen? 00:03:20.430 --> 00:03:25.430 Yeah, that's right. Because in 2017, what we saw is that because people did not 00:03:25.430 --> 00:03:30.190 use replace by fee. They saw the mempool was quite full. They thought, okay, 00:03:30.350 --> 00:03:34.890 currently the fees might be 50 satoshi per byte, but I can't change it anymore. 00:03:34.890 --> 00:03:38.710 So I'm just going to be safe and I'm going to set it to 100 satoshi per byte. And 00:03:38.710 --> 00:03:42.170 then the next person would say, oh, well, that looks really expensive. Let's make 00:03:42.170 --> 00:03:45.870 it 200 satoshi per byte. So people were really bidding up against each other much 00:03:45.870 --> 00:03:47.110 more than was necessary. 00:03:47.510 --> 00:03:53.230 Exactly. With replace by fee, they could have instead paid, say, one satoshi. And 00:03:53.230 --> 00:03:57.050 then keep an eye on the mempool maybe and see, okay, you know what? It looks like 00:03:57.050 --> 00:04:00.730 my one Satoshi transaction isn't going to confirm in the next block. So you know 00:04:00.730 --> 00:04:04.310 what? I'm going to bump it to five. And then sort of keep an eye on the mempool 00:04:04.310 --> 00:04:09.890 or wait, you know, half an hour, however much in a hurry they are. And in that 00:04:09.890 --> 00:04:15.560 way, sort of make sure that transaction confirms fast enough, but not overpay to 00:04:15.560 --> 00:04:16.180 make sure. 00:04:16.870 --> 00:04:17.930 exactly yeah 00:04:17.930 --> 00:04:22.330 so we've got two benefits already one of the benefits is your transaction gets 00:04:22.330 --> 00:04:27.130 stuck you want to get it unstuck the second benefit is it allows for better fee 00:04:27.130 --> 00:04:32.290 markets yeah there's a third interesting benefit and I think there are more 00:04:32.290 --> 00:04:37.930 if we want to get into the into the details but what one pretty obvious one is 00:04:37.930 --> 00:04:42.770 that with replace by fee you can make more efficient use of the Bitcoin 00:04:42.770 --> 00:04:48.710 blockchain so for example I'm paying you, Sjors, and then next 00:04:48.710 --> 00:04:53.870 I'm paying Ruben, who's not here today, but I'm also paying Ruben. And the way I 00:04:53.870 --> 00:04:58.730 could do that with Replace by Fee is I send you one transaction first, and after 00:04:58.730 --> 00:05:02.690 that I decide that I want to send Ruben a transaction. So now I create a 00:05:02.690 --> 00:05:08.150 transaction that pays you both. and then include a good fee in that. So now 00:05:08.150 --> 00:05:12.630 instead of using two different transactions, I can use one transaction, which is 00:05:12.630 --> 00:05:14.650 more efficient block space-wise. 00:05:14.890 --> 00:05:18.890 Yeah, and exchanges can do this at a much larger scale, right? So they have lots 00:05:18.890 --> 00:05:23.300 of customers that they need to pay out, and so they create one transaction. And 00:05:23.300 --> 00:05:27.640 that's going to be in a mempool for a while. And so every time another user 00:05:27.640 --> 00:05:31.020 withdraws coins, they just expand that transaction. And then whichever gets in 00:05:31.020 --> 00:05:34.060 the block gets in the block and the rest will just make a new transaction. 00:05:34.480 --> 00:05:38.220 Exactly. They can sort of keep updating this transaction by including more and 00:05:38.220 --> 00:05:38.920 more recipients. 00:05:39.320 --> 00:05:43.980 Yeah, which also, again, means more efficient use of the blockchain. So you get 00:05:43.980 --> 00:05:45.850 more value for your vbytes. 00:05:45.910 --> 00:05:49.990 So there are three pretty good benefits. One of them is getting transactions 00:05:49.990 --> 00:05:55.610 unstuck. The second one is allowing for a more effective fee market. And the 00:05:55.610 --> 00:05:58.010 third one is more block space efficiency. 00:05:58.330 --> 00:06:02.170 Yeah, and I can mention a fourth one that will actually create a nice bridge to 00:06:02.170 --> 00:06:06.810 the downside. Which is, let's say you make a one Satoshi per byte transaction to 00:06:06.810 --> 00:06:11.390 an exchange, and that exchange is called Mt. Gox. And you read on Twitter that 00:06:11.390 --> 00:06:15.450 this is maybe not a very good exchange. So you're like, okay, maybe I don't want 00:06:15.450 --> 00:06:19.230 to do this anymore. And so you can cancel a transaction because you can create a 00:06:19.230 --> 00:06:22.350 transaction with a higher fee that just goes back to you. 00:06:22.730 --> 00:06:27.390 Right, yeah. So you're describing it as a benefit now. But like you said, this is 00:06:27.390 --> 00:06:33.310 what critics of Replace by Fee would consider a detriment. And it is, 00:06:33.390 --> 00:06:38.530 of course. In a way, there aren't that many critics of RBF anymore, I think. But 00:06:38.530 --> 00:06:43.970 yeah, the detriment, the downside is that it allows for double spending 00:06:43.970 --> 00:06:49.330 if the recipient isn't going to wait for confirmations. So it's easier to double 00:06:49.330 --> 00:06:52.030 spend unconfirmed transactions with RBF. 00:06:52.230 --> 00:06:56.790 Yeah, and this was, of course, a big discussion, say, in 2015, 2016, when this, 00:06:56.950 --> 00:07:00.030 what we're going to talk about was introduced. You know, a lot of merchant 00:07:00.030 --> 00:07:04.470 applications would... like to be able to just have an instant confirmation 00:07:04.470 --> 00:07:09.950 essentially but it wouldn't be confirmed so that's that's inherently risky but as 00:07:09.950 --> 00:07:14.910 I guess we'll explain by default if everybody played reasonably nice it wasn't 00:07:14.910 --> 00:07:19.610 very risky but of course in Bitcoin we think long term and we don't want to rely 00:07:19.610 --> 00:07:21.910 on something that just requires too much kumbaya 00:07:21.910 --> 00:07:27.410 yeah so that was indeed a big discussion on whether or not we should allow RBF in 00:07:27.410 --> 00:07:33.000 the Protocol, I'm saying protocol, but to be clear, either way, it's not actually 00:07:33.000 --> 00:07:34.140 a consensus rule. 00:07:34.480 --> 00:07:38.380 Yeah, so there's a difference between consensus as in what is allowed inside of a 00:07:38.380 --> 00:07:42.740 block. So if you see a block with something in it that's not consensus 00:07:42.740 --> 00:07:46.280 compatible, you will not accept the block. And so the miners won't get their 00:07:46.280 --> 00:07:47.520 reward and it's really bad. 00:07:47.720 --> 00:07:49.780 It's just an invalid transaction, invalid block. 00:07:49.980 --> 00:07:54.340 Yeah, but there's all sorts of rules that pertain to how the network works. 00:07:54.560 --> 00:07:58.640 Things that... which transactions a node will relay or which ones it will reject 00:07:58.640 --> 00:08:03.040 and those rules are you know they're written in the code so if you run the code 00:08:03.040 --> 00:08:07.960 as it comes it'll do that but there's not really any enforcement other than that 00:08:07.960 --> 00:08:11.550 you can change the code or change the setting and it will behave differently. 00:08:11.850 --> 00:08:14.530 Yeah, these are like peer-to-peer layer rules. 00:08:14.810 --> 00:08:15.190 Yeah. 00:08:15.450 --> 00:08:19.870 And importantly, this is also for miners. This is how they decide which 00:08:19.870 --> 00:08:21.390 transactions they include in blocks. 00:08:21.950 --> 00:08:25.090 Yeah, but there it's even more important to realize that miners, of course, are 00:08:25.090 --> 00:08:29.230 very conscious of their revenue. So they will probably change something if the 00:08:29.230 --> 00:08:33.130 code does something that's not favorable for them economically and they can get 00:08:33.130 --> 00:08:34.790 away with it, they will do it. 00:08:34.910 --> 00:08:39.050 right presumably if it's like not some edge case yeah so the reason it was sort 00:08:39.050 --> 00:08:43.150 of controversial at all in the first place is because it was going to be the 00:08:43.150 --> 00:08:47.350 discussion was on whether or not RBF replace by fee was to be included in Bitcoin 00:08:47.350 --> 00:08:52.790 Core and most Bitcoin nodes on the network are Bitcoin Core so 00:08:52.790 --> 00:08:58.480 if all Bitcoin Core nodes would for example reject replace by fee transactions, 00:08:58.580 --> 00:09:03.880 then it would actually be very hard to get your replace by fee transaction to a 00:09:03.880 --> 00:09:06.460 miner because nodes wouldn't relay it over the network. 00:09:06.640 --> 00:09:10.040 Right, so you'd have to know who the miner is or there'd have to be some nodes 00:09:10.040 --> 00:09:11.700 that would relay it anyway. 00:09:11.920 --> 00:09:15.500 Yeah, or you'd have to be a miner or something like that, yeah. So by including 00:09:15.500 --> 00:09:21.400 replace by fee in Bitcoin Core, by including it, that's how it would become a bit 00:09:21.400 --> 00:09:24.980 more easy to make an unconfirmed double spend. 00:09:25.350 --> 00:09:25.790 Yes. 00:09:26.090 --> 00:09:30.410 Okay, so that's sort of the argument against replace by fee. Now let's debunk 00:09:30.410 --> 00:09:32.370 that argument, Sjors. Can we? 00:09:32.670 --> 00:09:33.110 Go ahead. 00:09:33.840 --> 00:09:36.700 Well, I will first mention, 00:09:36.980 --> 00:09:41.060 did we? Well, we at least brought up the point that we don't want to rely on 00:09:41.060 --> 00:09:43.500 people being nice and people using default settings. 00:09:43.780 --> 00:09:47.800 Sure, that's the most obvious argument that it's possible whether you like it or 00:09:47.800 --> 00:09:51.540 not. But like I said, whether it's included in Bitcoin Core kind of makes a 00:09:51.540 --> 00:09:53.000 difference on how easy it's going to be. 00:09:53.260 --> 00:09:53.360 Yeah. 00:09:53.760 --> 00:09:58.580 Okay. Well, I will mention, first of all, there's a thing called first seen safe 00:09:58.580 --> 00:10:02.800 replace by fee, which people were discussing back in like 2015, 16. 00:10:03.290 --> 00:10:04.170 Okay, how does that work? 00:10:04.270 --> 00:10:09.490 The idea behind first seen safe replace by fee is that you can only 00:10:09.490 --> 00:10:14.850 replace transactions if the outputs, if the recipients 00:10:14.850 --> 00:10:19.730 get at least the same amount of money. So that way, even an unconfirmed 00:10:19.730 --> 00:10:24.240 transaction is relatively safe under this context what we're talking about. 00:10:24.480 --> 00:10:29.260 Because the transaction can be replaced, but only by adding even more recipients. 00:10:29.840 --> 00:10:34.320 Yeah, but there's a huge problem with that, which is that the, Blockchain has no 00:10:34.320 --> 00:10:38.650 idea who the change address is. So normally what happens is... 00:10:38.650 --> 00:10:39.870 Well, there's no change address at all. 00:10:40.070 --> 00:10:44.210 Well, yeah, but that's already a problem with replace by fee. But let's say I'm 00:10:44.210 --> 00:10:49.530 sending you 0.1 Bitcoin and I use a coin worth 0.2 Bitcoin. 00:10:49.670 --> 00:10:53.670 Oh, sorry. There is a change address. There isn't a fee address. I was confused. 00:10:53.990 --> 00:10:57.770 Exactly. So yeah, so that's good to remind the listener. There is no fee address. 00:10:58.010 --> 00:11:01.710 There is just how much I'm sending you and then how much I'm sending myself as 00:11:01.710 --> 00:11:03.910 change. And the difference between that is the fee. 00:11:04.130 --> 00:11:04.290 Right. 00:11:04.530 --> 00:11:10.250 The problem is, if I sent you 0.1 using a 0.2 coin, the change is going to be 0 00:11:10.250 --> 00:11:14.410 .1. And then if I want to raise the fee, well, normally what I would do is I would 00:11:14.410 --> 00:11:18.290 just lower the change amount. But with this rule that you just explained, you 00:11:18.290 --> 00:11:21.310 can't lower the change amount because the blockchain doesn't know. They might 00:11:21.310 --> 00:11:25.370 think I'm actually cheating the intended recipient rather than myself. 00:11:25.570 --> 00:11:26.550 Right, that's a good point. 00:11:26.710 --> 00:11:31.150 So that means you have to add another input. every time you want to bump the 00:11:31.150 --> 00:11:35.890 transaction fee. But that actually uses more block space, so it gets really 00:11:35.890 --> 00:11:36.890 expensive really fast. 00:11:37.030 --> 00:11:42.010 Well, it could still work in the situation we described where an exchange adds 00:11:42.010 --> 00:11:44.750 new recipients in the payout address, for example. 00:11:45.250 --> 00:11:50.130 No, they would have the same problem. Every time they add a new recipient, they 00:11:50.130 --> 00:11:51.230 would have to add a new input. 00:11:51.370 --> 00:11:51.870 But that's fine. 00:11:52.050 --> 00:11:55.810 Well, they'd have to have like a Sahara Desert of Dust to be able to keep doing 00:11:55.810 --> 00:12:00.970 that. Because if they want to pay a thousand people, they need a thousand inputs. 00:12:01.210 --> 00:12:04.130 I guess you're right. So it does not sound very practical. 00:12:04.410 --> 00:12:08.630 I've never seen this proposal myself. I was not very active in the... I was not 00:12:08.630 --> 00:12:12.510 active at all in Bitcoin Core when this played out. So maybe this argument has 00:12:12.510 --> 00:12:13.430 been mentioned, maybe not. 00:12:13.730 --> 00:12:18.610 Maybe I hadn't heard it actually, but you're right. Then there is opt-in replace 00:12:18.610 --> 00:12:22.050 by fee. Okay. This is what's actually in Bitcoin Core, right? 00:12:22.590 --> 00:12:22.970 That's right. 00:12:23.390 --> 00:12:28.530 So opt-in replace by fee is replace by fee. Well, what it means is 00:12:28.530 --> 00:12:33.560 the only way Bitcoin Core nodes will replace a transaction, 00:12:33.990 --> 00:12:39.890 if it includes a higher fee, is if the first transaction includes a special flag. 00:12:40.130 --> 00:12:41.470 So a sign. 00:12:42.840 --> 00:12:47.560 that tells these nodes it's fine to replace this transaction if it has a higher fee. 00:12:47.800 --> 00:12:52.360 Right. And so this is still a way to be nice, basically. But if you're a merchant 00:12:52.360 --> 00:12:57.780 and you're relying on this zero confirmation, if you see this flag, you know that 00:12:57.780 --> 00:13:02.340 this thing might disappear from under you. And Bitcoin Core nodes won't try to 00:13:02.340 --> 00:13:02.780 stop that. 00:13:02.950 --> 00:13:07.850 Yeah, so the most practical sort of use case for this is if you are a merchant 00:13:07.850 --> 00:13:13.210 like BitKassa in the Netherlands, I think they will accept an unconfirmed 00:13:13.210 --> 00:13:17.290 transaction. So if you're at a bar and you're buying a beer, they have a payment 00:13:17.290 --> 00:13:22.610 terminal and they will accept unconfirmed transactions unless it has a RBF 00:13:22.610 --> 00:13:26.810 flag. Because in that case, they're just going to say, we're not sure enough that 00:13:26.810 --> 00:13:31.130 this transaction is not going to be replaced. This is a rejection from us. 00:13:31.250 --> 00:13:35.930 Yeah, and they have to do that in addition to checking the fee. Because if you're 00:13:35.930 --> 00:13:39.690 sending a transaction with a very low fee, then it might also never get confirmed 00:13:39.690 --> 00:13:45.210 and you have a lot of time to try and replace it. So it's still a can of worms, I 00:13:45.210 --> 00:13:48.930 think, as a merchant to do this. It's fine for small amounts, I guess. But then 00:13:48.930 --> 00:13:54.030 if it's fine for small amounts, why worry about RBF? But also, I guess the 00:13:54.030 --> 00:13:58.530 discussion now is... Not as critical as it was then because now we have Lightning 00:13:58.530 --> 00:14:03.550 and we have pretty user-friendly wallets to the point where if you really want to 00:14:03.550 --> 00:14:08.400 accept something fast, Lightning is just much safer and better privacy too. so 00:14:08.400 --> 00:14:11.280 definitely back then that wasn't ready yet right so 00:14:11.280 --> 00:14:16.160 yeah there are still some proponents of full RBF as well I think Peter Todd is an 00:14:16.160 --> 00:14:19.980 obvious example and i'm sure there are more I probably would consider myself one 00:14:19.980 --> 00:14:25.120 I I vaguely remember a mailing list post maybe a year ago where somebody 00:14:25.120 --> 00:14:28.280 suggested just turning on full RBF 00:14:28.280 --> 00:14:28.780 right 00:14:28.780 --> 00:14:33.340 at some point in the future I think that didn't end up happening. 00:14:33.700 --> 00:14:38.380 Right, yeah. His arguments, Peter Todd's arguments from... I don't know if these 00:14:38.380 --> 00:14:42.500 arguments have changed because it's been a couple of years since I wrote this 00:14:42.500 --> 00:14:47.340 article and spoke with him about this. But his argument was that the way these 00:14:47.340 --> 00:14:53.040 types of merchants... can be relatively sure that a double spend isn't going to 00:14:53.040 --> 00:14:57.920 happen with an unconfirmed transaction is monitoring the network. So checking, 00:14:58.560 --> 00:15:02.120 you know, having nodes on different parts of the network and see if there are any 00:15:02.120 --> 00:15:07.060 conflicting transactions going on. And this is in itself a problem that they feel 00:15:07.060 --> 00:15:12.880 the need to do this because for one, it's bad for privacy, 00:15:13.040 --> 00:15:16.980 arguably. Well, that's his argument anyways, because these nodes now have a 00:15:16.980 --> 00:15:22.180 better idea of where transactions originated. And two, it's requiring resources 00:15:22.180 --> 00:15:27.000 from nodes on the network because, you know, these spying nodes or whatever you 00:15:27.000 --> 00:15:30.740 want to call them, these double spend checking nodes, they have to get blocks and 00:15:30.740 --> 00:15:34.160 transactions from different nodes on network. So, you know, they're sort of 00:15:34.160 --> 00:15:35.140 wasting resources. 00:15:35.600 --> 00:15:35.800 Yeah. 00:15:36.000 --> 00:15:40.480 So it would be better, Peter Todd would argue, to just go for full RBF to make 00:15:40.480 --> 00:15:42.660 this kind of practices useless. 00:15:43.280 --> 00:15:46.840 Yeah, but then those practices don't seem to be happening at a scale that's 00:15:46.840 --> 00:15:48.820 problematic. As far as I know, 00:15:50.060 --> 00:15:54.440 So I don't know whether you want to change it or not. The other thing is now that 00:15:54.440 --> 00:15:57.660 everybody's running Lightning nodes, those nodes will have pretty much all of the 00:15:57.660 --> 00:16:02.920 same problems that you just described. They have to make sure that... you know 00:16:02.920 --> 00:16:07.100 nobody's trying to close the channel on them etc does anything fancy so I think 00:16:07.100 --> 00:16:09.460 we're already at the place where you really need to pay attention to what's 00:16:09.460 --> 00:16:10.180 happening in the mempool 00:16:10.180 --> 00:16:15.240 right okay so there is now a version of opt-in RBF in Bitcoin Core 00:16:15.240 --> 00:16:15.560 yep 00:16:15.560 --> 00:16:19.780 and by the way mentioning Peter Todd I think he still maintains like a bunch of 00:16:19.780 --> 00:16:22.140 nodes that do full RBF 00:16:22.500 --> 00:16:26.560 Yeah, he used to have a separate release that was full RBF. And if you were sure 00:16:26.560 --> 00:16:30.080 that he wasn't trying to hack you, then I don't know if he released binaries or 00:16:30.080 --> 00:16:32.540 just code. It's just a one line change. 00:16:32.800 --> 00:16:37.240 Right. And the idea was there that people could still use full RBF if they want 00:16:37.240 --> 00:16:40.800 to. And I'm pretty sure that some miners actually do use full RBF. 00:16:41.060 --> 00:16:41.420 Yeah. 00:16:41.750 --> 00:16:45.370 Which makes sense because it's incentive compatible for them to do so. They make 00:16:45.370 --> 00:16:49.530 the most money if they do so. So anyways, but in Bitcoin Core, there is the opt 00:16:49.530 --> 00:16:53.990 -in RBF version. And I think you have some more details about what it actually does. 00:16:54.470 --> 00:16:59.210 Yeah, so I guess it's fun to describe it in a little bit more detail. So given a 00:16:59.210 --> 00:17:03.210 transaction, like I said, I sent you money and I have some change back to myself. 00:17:03.390 --> 00:17:07.430 There are five rules that Bitcoin Core will check if I want to replace that 00:17:07.430 --> 00:17:11.890 transaction. And this has been the case since 0.12. So it's quite a while. 00:17:12.070 --> 00:17:12.690 Like five years ago? 00:17:13.170 --> 00:17:14.690 Something like that. Yeah, 00:17:15.010 --> 00:17:15.870 2016. 00:17:16.870 --> 00:17:21.390 So if a transaction spends one or more of the same inputs, that's the first 00:17:21.390 --> 00:17:23.280 condition. Remember that. 00:17:23.340 --> 00:17:25.320 That's what makes it RBF in the first place. 00:17:25.480 --> 00:17:31.320 Yeah, because I can spend twice. That's a bad idea. I could send you 0 00:17:31.320 --> 00:17:34.660 .1 Bitcoin and have a fee and then create a new transaction that uses different 00:17:34.660 --> 00:17:38.140 inputs. Then, of course, the blockchain will just mine both of them and I have a 00:17:38.140 --> 00:17:44.000 problem. So I have to replace the input. And if I do that, then first 00:17:44.000 --> 00:17:49.110 of all, I have to opt into this thing with the flag that we talked about. That's 00:17:49.110 --> 00:17:54.500 rule number one. And then the rule is the replacement transaction may only 00:17:54.500 --> 00:17:58.620 include an unconfirmed input if that input was included in one of the original 00:17:58.620 --> 00:18:03.960 transactions, which is a kind of a roundabout way of saying the opposite. I can 00:18:03.960 --> 00:18:07.260 add new inputs to this new transaction because maybe I want to increase the fee, 00:18:07.280 --> 00:18:12.100 so I need some extra inputs or I want to add other people. But this input has to 00:18:12.100 --> 00:18:13.860 be confirmed if it's a new one. 00:18:15.260 --> 00:18:19.840 And my guess is that this is just to prevent a can of worms where I have a 00:18:19.840 --> 00:18:25.780 transaction that is unconfirmed and I'm sending it across all the nodes and 00:18:25.780 --> 00:18:30.780 it doesn't depend on any unconfirmed inputs. And now I bump it, but now it does 00:18:30.780 --> 00:18:33.880 depend on all sorts of unconfirmed inputs. And now I'm forcing everybody to 00:18:33.880 --> 00:18:38.440 figure out where those unconfirmed inputs are and maybe they have a super low fee 00:18:38.440 --> 00:18:40.620 and I guess it's too complicated to implement. 00:18:41.320 --> 00:18:43.580 Right, yeah. I can see that. 00:18:44.730 --> 00:18:48.430 Because, you know, think about what this code looks like on the Bitcoin Core end. 00:18:48.710 --> 00:18:52.810 You have to write, you see this new transaction and what are you going to do? Oh, 00:18:52.930 --> 00:18:56.290 now some of these dependencies are unconfirmed. I have to traverse that whole 00:18:56.290 --> 00:18:59.230 tree. I don't want to think about that. I only want to think about my descendants. 00:19:00.420 --> 00:19:05.300 Yeah, it would basically allow for types of denial of service attacks, I guess, 00:19:05.440 --> 00:19:06.080 where you just... 00:19:06.080 --> 00:19:09.520 Yeah, I think it's... My guess is it's both for denial of service, but also just 00:19:09.520 --> 00:19:13.240 to make the code easier to implement for anybody who writes this kind of node 00:19:13.240 --> 00:19:18.270 software. Then rule number three, the replacement transaction pays an absolute 00:19:18.270 --> 00:19:24.090 fee of at least the sum of the original transactions. Because you can replace 00:19:24.090 --> 00:19:29.610 one transaction plus a bunch of its descendants, the things spending from that. 00:19:30.320 --> 00:19:33.880 But the absolute fee has to be the same. So if I paid... 00:19:33.880 --> 00:19:34.420 Or higher. 00:19:34.780 --> 00:19:39.720 Yeah, the same or higher. Exactly. Which also means that if I paid you and then 00:19:39.720 --> 00:19:42.420 you paid somebody else and I want to replace my transaction, 00:19:44.140 --> 00:19:47.320 The transaction that you paid to somebody else, I have to at least pay the same 00:19:47.320 --> 00:19:52.200 fee that was in there. It's kind of a disincentive for me to reorg from under 00:19:52.200 --> 00:19:55.400 you. Because that's one of the annoying things with RBF, right? I'm paying you, 00:19:55.560 --> 00:20:00.530 you're paying somebody else. Now I bump the fee. Oh, oops. The transaction you 00:20:00.530 --> 00:20:01.770 paid to somebody else is now gone. 00:20:01.990 --> 00:20:02.190 Right. 00:20:02.610 --> 00:20:06.890 And, well, I would have to really deliberately do that because I would have to 00:20:06.890 --> 00:20:11.170 increase the fee on my own transaction by enough that it also covers that 00:20:11.170 --> 00:20:12.870 transaction of yours that I just destroyed. 00:20:14.380 --> 00:20:18.040 So in practice, this wouldn't happen. We would either both agree to send a new 00:20:18.040 --> 00:20:21.040 transaction and somehow package them or not. 00:20:21.600 --> 00:20:25.980 Yeah, there are probably very little, if any, sort of real-world examples where 00:20:25.980 --> 00:20:30.820 an RBF transaction would have a lower fee. So it's just to prevent weird 00:20:30.820 --> 00:20:32.660 attacks and complications. 00:20:32.660 --> 00:20:37.110 It is an annoying rule, and maybe we'll get to it, but it's probably necessary. 00:20:37.390 --> 00:20:42.290 And then the fourth rule is it has to increase the fee rate. 00:20:43.080 --> 00:20:44.660 by the minimum relay fee 00:20:44.660 --> 00:20:45.040 sure 00:20:45.040 --> 00:20:50.480 so usually at least one satoshi per byte but if a mempool is full then the 00:20:50.480 --> 00:20:51.940 minimum relay fee is going to be higher 00:20:53.190 --> 00:20:56.710 So if the mempools are very full, then you cannot bump by just one satoshi per 00:20:56.710 --> 00:20:58.890 byte. You may have to bump by 10 satoshi per byte. 00:20:59.090 --> 00:21:02.950 Right. This could differ from node to node. If they have different mempools for 00:21:02.950 --> 00:21:06.610 whatever reason, then they might have a different idea of what the minimum relay 00:21:06.610 --> 00:21:12.050 fee is. So it might make its way through parts of the network, but not others. 00:21:12.070 --> 00:21:15.990 It's possible. Yeah, this is a tricky bit, right? Because you know from your own 00:21:15.990 --> 00:21:20.770 node how much is in the mempool. And so you have to estimate what the minimum fee 00:21:20.770 --> 00:21:22.390 rate is that still goes into your mempool. 00:21:23.650 --> 00:21:28.650 But if you just start your node after stopping it, the mempool might be 00:21:28.650 --> 00:21:33.310 incomplete. And so you might be more optimistic about how low the fee increment 00:21:33.310 --> 00:21:37.810 can be. So it's kind of annoying. But it does make sense that you don't want 00:21:37.810 --> 00:21:40.070 people to spam the network and you want to keep. 00:21:40.290 --> 00:21:40.470 Yep. 00:21:40.750 --> 00:21:46.470 So, and the fifth rule is the number of original transactions to be replaced and 00:21:46.470 --> 00:21:51.310 their transcendent transactions will be evicted from mempool must not exceed a 00:21:51.310 --> 00:21:52.610 total of 100 transactions. 00:21:53.860 --> 00:21:57.720 So I guess a simple way to say is that if you do something convoluted that 00:21:57.720 --> 00:22:02.540 touches more than 100 transactions, it's not going to work. And another caveat 00:22:02.540 --> 00:22:07.940 that I don't think is in these rules, but it is there, is that if you replace a 00:22:07.940 --> 00:22:13.580 transaction, it has to opt into it. Every one of its inputs has to opt into 00:22:13.580 --> 00:22:19.080 allowing this fee bump. But also for all the descendants, this has to be true. So 00:22:19.080 --> 00:22:24.190 if I... send a transaction to you and you send to somebody else, but your 00:22:24.190 --> 00:22:28.110 transaction does not opt into RBF, then I can't replace my own. 00:22:28.310 --> 00:22:28.630 Right. 00:22:28.850 --> 00:22:34.370 And also I can opt out of RBF. I can bump the fee once and then I can say, now 00:22:34.370 --> 00:22:36.910 it's final. So I opt out in the last bump. 00:22:37.130 --> 00:22:38.250 Oh, that's actually possible? 00:22:38.510 --> 00:22:38.670 Yeah. 00:22:39.150 --> 00:22:39.370 Right. 00:22:39.670 --> 00:22:43.170 And this is probably also why there's so many problems because we could talk 00:22:43.170 --> 00:22:43.690 about problems. 00:22:44.190 --> 00:22:45.490 Oh, there are problems? 00:22:45.770 --> 00:22:51.150 There are problems. [unclear]. Especially... Well, let's start with a simple 00:22:51.150 --> 00:22:56.590 problem that I don't think I've seen a solution for. Let's say I'm sending you a 00:22:56.590 --> 00:23:00.230 transaction, but I'm also sending Ruben a transaction. I think we mentioned that 00:23:00.230 --> 00:23:05.190 example. And those are two separate transactions. But now I think, oh my God, 00:23:05.450 --> 00:23:08.730 what if I combine those transactions? Because that would be more efficient. 00:23:08.910 --> 00:23:09.490 It would be. 00:23:09.790 --> 00:23:15.530 Yeah. But because maybe I can use fewer inputs in particular. 00:23:15.670 --> 00:23:20.030 Because I have one input. that goes to you. And I have one input that goes to 00:23:20.030 --> 00:23:24.530 Ruben. And if I combine them, then they go to both of you. So that saves me a 00:23:24.530 --> 00:23:28.490 number of bytes. But we talked about rule number three. So I don't think we can do that. 00:23:28.890 --> 00:23:31.510 Oh, because it has a lower absolute fee in that case? 00:23:31.650 --> 00:23:31.770 Yeah. 00:23:31.950 --> 00:23:35.150 Right. So there actually is a normal example where it would be handy. 00:23:35.470 --> 00:23:39.870 Yeah, exactly. So because I've increased the fee rate, right? Because I have to 00:23:39.870 --> 00:23:43.670 increase the fee rate. But unless I double the fee rate, or I don't know what the 00:23:43.670 --> 00:23:46.510 factor is, because I've made the transaction smaller, the absolute fee is going 00:23:46.510 --> 00:23:50.750 to be lower. So generally merging two transactions is not, yeah, it's not going to work. 00:23:50.850 --> 00:23:51.010 Right. 00:23:51.130 --> 00:23:52.030 The current RBF rules. 00:23:52.150 --> 00:23:56.810 So yeah, the way to go then would be my solution to just make, not make two 00:23:56.810 --> 00:24:00.830 separate transactions, but the second one would have already, needs to already be 00:24:00.830 --> 00:24:01.590 the RBF one. 00:24:01.750 --> 00:24:02.830 The downside of that one. 00:24:03.030 --> 00:24:04.150 Needs to already combine the two. 00:24:04.450 --> 00:24:07.510 Yeah. The downside of that is it needs to, you need to track a little bit more 00:24:07.510 --> 00:24:13.230 things of what's going on. Because in the example I gave you is either, if one of 00:24:13.230 --> 00:24:18.230 them confirms, so if the one, If the one with the combined one, if it confirms, 00:24:18.490 --> 00:24:24.130 then you're done. If one of the original two confirms, then the combined one 00:24:24.130 --> 00:24:29.370 won't happen. So it's more clear which one you need to bump. But if you start 00:24:29.370 --> 00:24:33.770 combining things, you need to track, I guess, because one of those versions will 00:24:33.770 --> 00:24:37.070 confirm you need to remember which ones to add. But you probably have to do 00:24:37.070 --> 00:24:39.110 something like that anyway. And a wallet can automate it. 00:24:40.600 --> 00:24:45.180 Yeah. And this is not really a consumer use case that often because, you know, 00:24:45.380 --> 00:24:50.400 you might send more than one transaction per unit of time, but usually it'll 00:24:50.400 --> 00:24:52.800