WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode.

00:00:07.250 --> 00:00:10.050
<v Aaron van Wirdum>Live from Utrecht, this is the Van Wirdum Sjorsnado.

00:00:10.250 --> 00:00:10.430
<v Sjors Provoost>Hello.

00:00:10.870 --> 00:00:11.290
<v Aaron van Wirdum>Hey, Sjors.

00:00:11.570 --> 00:00:11.770
<v Sjors Provoost>What's up?

00:00:12.110 --> 00:00:12.990
<v Aaron van Wirdum>Happy all-time high.

00:00:13.410 --> 00:00:16.030
<v Sjors Provoost>Yeah, again. Oh, we talked about the market cap high.

00:00:16.030 --> 00:00:19.530
<v Aaron van Wirdum>Yeah, well, that one you weren't celebrating because it didn't affect you

00:00:19.530 --> 00:00:23.670
<v Aaron van Wirdum>individually enough. So I guess this time was party. Party time for Sjors.

00:00:23.910 --> 00:00:28.130
<v Sjors Provoost>But again, we don't know what the dollar did in the meantime. I mean, can I still

00:00:28.130 --> 00:00:30.990
<v Sjors Provoost>buy a bagel for less than $15 in San Francisco?

00:00:31.250 --> 00:00:34.370
<v Aaron van Wirdum>Yeah, it's definitely not an all-time high in purchasing power, is it?

00:00:34.550 --> 00:00:34.770
<v Sjors Provoost>No.

00:00:35.030 --> 00:00:37.870
<v Aaron van Wirdum>So we skipped a week. Last week was Halloween.

00:00:38.130 --> 00:00:38.390
<v Sjors Provoost>Yes.

00:00:38.770 --> 00:00:39.110
<v Aaron van Wirdum>Apparently.

00:00:39.650 --> 00:00:40.030
<v Sjors Provoost>And Thanksgiving.

00:00:40.730 --> 00:00:44.170
<v Aaron van Wirdum>Oh, that's what… that's what was up. Yeah, it was Thanksgiving. When is

00:00:44.170 --> 00:00:46.190
<v Aaron van Wirdum>Halloween? That was a month ago.

00:00:46.370 --> 00:00:47.430
<v Sjors Provoost>I think it was earlier, yeah.

00:00:47.570 --> 00:00:51.870
<v Aaron van Wirdum>Yeah, never mind. All these American holidays. I have no idea. Last week was Halloween.

00:00:52.050 --> 00:00:53.850
<v Sjors Provoost>We don't have holidays. Holidays are socialist.

00:00:54.410 --> 00:00:58.210
<v Aaron van Wirdum>So we just have a boring life over here in the rain. Sjors, do you know what

00:00:58.210 --> 00:00:58.690
<v Aaron van Wirdum>Brink is?

00:00:58.950 --> 00:01:03.070
<v Sjors Provoost>Yes. No, but I've heard of it. Yeah. It's a new initiative by John Newbery, but

00:01:03.070 --> 00:01:04.330
<v Sjors Provoost>you're going to tell me all about it.

00:01:04.530 --> 00:01:09.470
<v Aaron van Wirdum>No, that covers it. I'll tell you one extra detail. One of the things they're

00:01:09.470 --> 00:01:12.410
<v Aaron van Wirdum>doing, well, they're doing two things. So they're issuing grants to developers.

00:01:13.060 --> 00:01:18.150
<v Aaron van Wirdum>Or two projects that are working on Bitcoin stuff, open source projects. And the

00:01:18.150 --> 00:01:22.570
<v Aaron van Wirdum>other thing which is pretty unique well… what… is which is entirely unique is

00:01:22.570 --> 00:01:27.930
<v Aaron van Wirdum>they are… they have a fellowship program. So aspiring

00:01:27.930 --> 00:01:31.970
<v Aaron van Wirdum>Bitcoin developers, Bitcoin Core developers, perhaps Lightning developers,

00:01:32.310 --> 00:01:38.230
<v Aaron van Wirdum>whatever it is, they can join the fellowship at Brink and they'll enjoy a

00:01:38.230 --> 00:01:40.070
<v Aaron van Wirdum>year of training by John Newbery.

00:01:40.230 --> 00:01:43.630
<v Sjors Provoost>So that's like the Chaincode Labs summer, but all year.

00:01:43.710 --> 00:01:44.070
<v Aaron van Wirdum>All year.

00:01:44.310 --> 00:01:45.730
<v Sjors Provoost>In the rain, in London.

00:01:45.750 --> 00:01:49.910
<v Aaron van Wirdum>Yes, in London. That's the downside, I guess, compared to the Chaincode Labs one.

00:01:50.450 --> 00:01:54.050
<v Aaron van Wirdum>Well, the Chaincode, that's in New York. It's not much better. It's not like it's LA.

00:01:54.230 --> 00:01:58.960
<v Sjors Provoost>I would pick London over New York in terms of the weather because it's never

00:01:58.960 --> 00:02:03.140
<v Sjors Provoost>really cold in London. It's never really hot in London. The sun doesn't shine so

00:02:03.140 --> 00:02:04.020
<v Sjors Provoost>it's comfortable.

00:02:04.020 --> 00:02:09.640
<v Aaron van Wirdum>Fair enough. Well so this week they announced their first fellow which is Gloria

00:02:09.640 --> 00:02:10.060
<v Aaron van Wirdum>Zhao.

00:02:10.060 --> 00:02:11.060
<v Sjors Provoost>Congratulations.

00:02:11.060 --> 00:02:16.360
<v Aaron van Wirdum>Congratulations Gloria. She's gonna work on something pretty specific which is

00:02:16.360 --> 00:02:17.380
<v Aaron van Wirdum>called package relay.

00:02:17.380 --> 00:02:18.400
<v Sjors Provoost>Oh no.

00:02:18.400 --> 00:02:20.400
<v Aaron van Wirdum>Why do you say oh no?

00:02:20.400 --> 00:02:21.920
<v Sjors Provoost>Because it's a can of worms.

00:02:21.920 --> 00:02:26.990
<v Aaron van Wirdum>Yeah, you mentioned that before. Let's explain what it is and then after our

00:02:26.990 --> 00:02:30.470
<v Aaron van Wirdum>explanation, you can get into why it's a can of worms. Does that sound good?

00:02:30.610 --> 00:02:31.330
<v Sjors Provoost>That sounds excellent.

00:02:31.590 --> 00:02:36.430
<v Aaron van Wirdum>Okay. So it is an upgrade, a proposed upgrade to

00:02:36.430 --> 00:02:39.390
<v Aaron van Wirdum>basically to Bitcoin's mempool policy.

00:02:40.120 --> 00:02:41.620
<v Sjors Provoost>And peer-to-peer network.

00:02:41.900 --> 00:02:47.360
<v Aaron van Wirdum>Yes. Yeah, but it all comes down to improving how mempools work, I guess, right?

00:02:47.520 --> 00:02:50.900
<v Aaron van Wirdum>And the relay policy is in support of that.

00:02:52.420 --> 00:02:56.080
<v Aaron van Wirdum>But what's a mempool? I was just going to ask you, Sjors, what's a mempool?

00:02:56.360 --> 00:02:57.500
<v Sjors Provoost>I thought you were going to answer that.

00:02:57.760 --> 00:02:58.420
<v Aaron van Wirdum>I can answer it.

00:02:58.600 --> 00:03:04.500
<v Sjors Provoost>So the mempool is basically a bunch of memory on your node that is dedicated

00:03:04.500 --> 00:03:07.800
<v Sjors Provoost>to keeping track of transactions that are not yet in a block.

00:03:08.560 --> 00:03:12.860
<v Aaron van Wirdum>Yeah, so transactions are transmitted over Bitcoin's peer-to-peer network before

00:03:12.860 --> 00:03:15.960
<v Aaron van Wirdum>they are included in a block. Just whenever you send a transaction, it's

00:03:15.960 --> 00:03:20.620
<v Aaron van Wirdum>forwarded from node to node, from peer to peer. And all of these nodes keep a

00:03:20.620 --> 00:03:25.000
<v Aaron van Wirdum>collection of these transactions. And if you're a miner, you use this collection

00:03:25.000 --> 00:03:29.840
<v Aaron van Wirdum>of transactions to form a block. That's right. So how big is a mempool?

00:03:30.140 --> 00:03:34.420
<v Sjors Provoost>Well, that's up to you, up to the node runner. You can allocate as little or as

00:03:34.420 --> 00:03:38.000
<v Sjors Provoost>much memory as you want to. Keeping track of those transactions, but by default

00:03:38.000 --> 00:03:39.440
<v Sjors Provoost>it is 300 megabytes,

00:03:39.440 --> 00:03:40.460
<v Aaron van Wirdum>In Bitcoin Core.

00:03:40.460 --> 00:03:44.360
<v Sjors Provoost>It's 300 megabytes or 300,000 kilobytes if you're nitpicky.

00:03:44.360 --> 00:03:49.360
<v Aaron van Wirdum>Yeah so apparently that's actually not 300 megabytes of transactions it's much

00:03:49.360 --> 00:03:54.000
<v Aaron van Wirdum>less than that, I learned while writing this article about Brink's first

00:03:54.000 --> 00:03:54.520
<v Aaron van Wirdum>fellowship.

00:03:54.520 --> 00:03:59.020
<v Sjors Provoost>Oh, that could very well be true. Yeah, there's a lot of database overhead in there.

00:03:59.020 --> 00:04:04.960
<v Aaron van Wirdum>Yeah, a lot, apparently, because Gloria told me it's like 75… 75 megabytes of

00:04:04.960 --> 00:04:08.900
<v Aaron van Wirdum>transactions for a 300 megabyte mempool. That seems like a big difference to me.

00:04:09.200 --> 00:04:13.360
<v Aaron van Wirdum>So that's like 100,000 to 140,000 transactions.

00:04:14.120 --> 00:04:18.500
<v Sjors Provoost>Yeah, it wouldn't surprise me. For one thing, a transaction, I think a raw

00:04:18.500 --> 00:04:24.180
<v Sjors Provoost>transaction might be 140 bytes or something or 200 bytes. And then

00:04:24.180 --> 00:04:30.380
<v Sjors Provoost>the hash of a transaction is… Is it 64 bytes or 32 bytes?

00:04:30.640 --> 00:04:32.600
<v Aaron van Wirdum>You're looking at me as if I know this stuff.

00:04:32.820 --> 00:04:36.500
<v Sjors Provoost>Oh, you know that. I think it's 32. But then the transaction is pointing to other

00:04:36.500 --> 00:04:40.940
<v Sjors Provoost>transactions. So it has to, inside the database, next to the raw transaction, it

00:04:40.940 --> 00:04:44.480
<v Sjors Provoost>has to have all these pointers to the other transactions that probably take up space.

00:04:45.280 --> 00:04:46.620
<v Aaron van Wirdum>Right. Lots of overhead.

00:04:47.210 --> 00:04:50.970
<v Sjors Provoost>And then some way to quickly find them. Yeah, yeah, I mean, this thing was

00:04:50.970 --> 00:04:55.970
<v Sjors Provoost>designed, I don't know when the 300 megabyte was chosen, but probably when blocks

00:04:55.970 --> 00:04:56.390
<v Sjors Provoost>were tiny.

00:04:56.830 --> 00:05:01.850
<v Aaron van Wirdum>I remember being that… I remember when that was chosen, I think, I think that was

00:05:01.850 --> 00:05:05.670
<v Aaron van Wirdum>included in one of my Bitcoin Core release articles. I just don't remember which

00:05:05.670 --> 00:05:10.620
<v Aaron van Wirdum>one. It was probably a while ago, but I remember that it was… included at some

00:05:10.620 --> 00:05:11.220
<v Aaron van Wirdum>point, I think.

00:05:11.560 --> 00:05:16.060
<v Sjors Provoost>But as far as I know, the last time the mempool was that full was in 2017.

00:05:16.560 --> 00:05:17.520
<v Aaron van Wirdum>Yeah, but it happened.

00:05:18.040 --> 00:05:20.160
<v Sjors Provoost>Yeah, it did. It overflowed.

00:05:20.150 --> 00:05:24.500
<v Aaron van Wirdum>And that creates some really weird things. That's my next question, Sjors. So

00:05:24.500 --> 00:05:28.540
<v Aaron van Wirdum>we're all happily forwarding transactions to one another on the peer-to-peer

00:05:28.540 --> 00:05:34.040
<v Aaron van Wirdum>network. And then at some point, some mempools get full. But there are even more

00:05:34.040 --> 00:05:35.600
<v Aaron van Wirdum>transactions coming in. What happens then?

00:05:36.600 --> 00:05:41.130
<v Sjors Provoost>Well… Basically, nodes don't want to waste too much of their own resources and

00:05:41.130 --> 00:05:44.130
<v Sjors Provoost>too much of the network resources. So they try to reason, okay, which

00:05:44.130 --> 00:05:49.370
<v Sjors Provoost>transactions are the most viable. So it's like a triage. And basically, well, the

00:05:49.370 --> 00:05:52.630
<v Sjors Provoost>transactions with the highest fees are probably going to be mined by miners

00:05:52.630 --> 00:05:56.530
<v Sjors Provoost>because they care about high fees. So the nodes do the same thing. They look at

00:05:56.530 --> 00:06:00.090
<v Sjors Provoost>the new transaction and say, hey, is this higher than any of the other

00:06:00.090 --> 00:06:03.650
<v Sjors Provoost>transactions I have in my pool? And they kick out the transactions with the

00:06:03.650 --> 00:06:07.570
<v Sjors Provoost>lowest fees and put the higher fee in there. And if the transaction arrives as a

00:06:07.570 --> 00:06:10.810
<v Sjors Provoost>lower fee than anything they already have, like, well, come back later.

00:06:11.700 --> 00:06:17.500
<v Aaron van Wirdum>Right. Well, Sjors, you say that, but there is a subtle difference in how miners

00:06:17.500 --> 00:06:20.300
<v Aaron van Wirdum>actually pick their transactions, isn't it? That's what we're getting to.

00:06:20.540 --> 00:06:24.980
<v Sjors Provoost>Well, at least how they could pick it, because, yeah, it would be very naive, or

00:06:24.980 --> 00:06:28.220
<v Sjors Provoost>at least a little bit naive, to only sort them by fee.

00:06:28.440 --> 00:06:31.380
<v Aaron van Wirdum>You mean when miners pick their transactions to include in a block?

00:06:31.560 --> 00:06:31.760
<v Sjors Provoost>Yeah.

00:06:31.980 --> 00:06:34.340
<v Aaron van Wirdum>Yeah. So what do they do instead?

00:06:34.640 --> 00:06:37.220
<v Sjors Provoost>Well, the problem is there could be multiple transactions that depend on each

00:06:37.220 --> 00:06:39.250
<v Sjors Provoost>other. And so…

00:06:39.250 --> 00:06:40.750
<v Aaron van Wirdum>What does that mean exactly?

00:06:41.330 --> 00:06:47.170
<v Sjors Provoost>So one transaction is me paying to Bob, and then Bob paying to Alice, and Alice

00:06:47.170 --> 00:06:51.530
<v Sjors Provoost>paying to John. Those could all be unconfirmed transactions in a chain. And now

00:06:51.530 --> 00:06:56.940
<v Sjors Provoost>maybe when I paid you, I was super stingy and I used one Satoshi per byte. So if

00:06:56.940 --> 00:06:59.940
<v Sjors Provoost>the miner sees that transaction, they might think, well, it's just one Satoshi

00:06:59.940 --> 00:07:03.540
<v Sjors Provoost>per byte. I'm going to put that in the back of the line. But when you paid to

00:07:03.540 --> 00:07:09.120
<v Sjors Provoost>Alice, you were paying 1,000 Satoshi per byte. It was very generous. But that

00:07:09.120 --> 00:07:12.600
<v Sjors Provoost>transaction cannot get into the… would not get into the block if the miner was

00:07:12.600 --> 00:07:16.510
<v Sjors Provoost>this naive. So if the miner is a little bit smarter, they'll look at your

00:07:16.510 --> 00:07:20.870
<v Sjors Provoost>transaction and say, hey, this is a very profitable transaction. Okay, but I also

00:07:20.870 --> 00:07:24.750
<v Sjors Provoost>need to include this very stingy transaction. And so the miner might include very

00:07:24.750 --> 00:07:28.210
<v Sjors Provoost>stingy transactions in order to get the very profitable ones if their algorithm

00:07:28.210 --> 00:07:32.490
<v Sjors Provoost>is smart enough. I don't know if that's actually the case, but we care about the

00:07:32.490 --> 00:07:33.890
<v Sjors Provoost>longer term game theory here.

00:07:34.430 --> 00:07:37.310
<v Aaron van Wirdum>Why do you say… this is what happens now, isn't it?

00:07:37.760 --> 00:07:39.200
<v Sjors Provoost>I don't know. Have you checked?

00:07:39.400 --> 00:07:41.820
<v Aaron van Wirdum>Yes. Well, I mean, I haven't checked the code, but…

00:07:41.820 --> 00:07:47.720
<v Sjors Provoost>Have you checked in 2017 when the mempool was actually full or that high fee

00:07:47.720 --> 00:07:51.720
<v Sjors Provoost>transactions were included that were building on top of low fee transactions?

00:07:52.820 --> 00:07:57.040
<v Aaron van Wirdum>Sure. So we're just talking about… We're not talking about the mempool yet. We're

00:07:57.040 --> 00:07:59.580
<v Aaron van Wirdum>just talking about the miner policy. Yes.

00:07:59.900 --> 00:08:04.190
<v Sjors Provoost>I don't know. I haven't checked. So I don't know if miners actually do this, what

00:08:04.190 --> 00:08:04.790
<v Sjors Provoost>I just proposed.

00:08:05.340 --> 00:08:08.800
<v Aaron van Wirdum>Oh, I'm sure they do. I mean, I haven't checked the code, like I said, but I'm

00:08:08.800 --> 00:08:09.980
<v Aaron van Wirdum>sure this is what they do.

00:08:10.120 --> 00:08:13.380
<v Sjors Provoost>I don't know. It sounds like you have to write a lot of code to do that. Or you

00:08:13.380 --> 00:08:14.020
<v Sjors Provoost>could just be lazy.

00:08:14.380 --> 00:08:16.140
<v Aaron van Wirdum>No, I'm sure this is in Bitcoin Core.

00:08:16.640 --> 00:08:17.080
<v Sjors Provoost>Is it?

00:08:17.220 --> 00:08:18.080
<v Aaron van Wirdum>Yes, for sure.

00:08:18.280 --> 00:08:20.040
<v Sjors Provoost>And when you make a block with Bitcoin Core, you mean?

00:08:20.540 --> 00:08:20.860
<v Aaron van Wirdum>Yes.

00:08:21.220 --> 00:08:25.100
<v Sjors Provoost>So that's the… Okay. But I don't know if miners used Bitcoin Core in order to

00:08:25.100 --> 00:08:28.340
<v Sjors Provoost>create blocks. So there is some logic in Bitcoin Core that can help you generate

00:08:28.340 --> 00:08:30.860
<v Sjors Provoost>blocks, but I'm not sure if miners actually used it.

00:08:31.530 --> 00:08:36.710
<v Aaron van Wirdum>I'm fairly sure. Okay. I think so. I'm pretty confident that they use this.

00:08:36.930 --> 00:08:40.310
<v Sjors Provoost>Well, either way, either they do or they don't. They should or they should not.

00:08:40.530 --> 00:08:43.850
<v Sjors Provoost>You know, it makes sense to, as we just described, not consider individual

00:08:43.850 --> 00:08:45.690
<v Sjors Provoost>transactions, but consider them as a package.

00:08:46.030 --> 00:08:50.270
<v Aaron van Wirdum>Yeah. So one of the nice things about this logic is that you can actually use it

00:08:50.270 --> 00:08:54.750
<v Aaron van Wirdum>yourself. So for example, you're sending me a payment. I don't want to wait until

00:08:54.750 --> 00:08:59.390
<v Aaron van Wirdum>it confirms, even though you included a very low fee. So what I can do is… take

00:08:59.390 --> 00:09:03.350
<v Aaron van Wirdum>the coin from the payment, just take the output, spend it to myself in a new

00:09:03.350 --> 00:09:06.890
<v Aaron van Wirdum>transaction, which includes a higher fee, and therefore a miner will pick them up

00:09:06.890 --> 00:09:08.570
<v Aaron van Wirdum>both and I'll have a faster confirmation.

00:09:09.170 --> 00:09:09.310
<v Sjors Provoost>Yeah.

00:09:10.410 --> 00:09:15.710
<v Aaron van Wirdum>This is especially important in some scenarios, most notably something like

00:09:15.710 --> 00:09:17.150
<v Aaron van Wirdum>Lightning, right?

00:09:17.570 --> 00:09:18.150
<v Sjors Provoost>Yes.

00:09:18.350 --> 00:09:23.950
<v Aaron van Wirdum>Because in Lightning, your channel partner can cheat on you by transmitting an

00:09:23.950 --> 00:09:29.870
<v Aaron van Wirdum>older… version of the channel, an older balance, which issues that

00:09:29.870 --> 00:09:35.310
<v Aaron van Wirdum>channel partner more funds than the latest channel balance should actually grant

00:09:35.310 --> 00:09:39.970
<v Aaron van Wirdum>him, right? So he can try to cheat on you. The way to solve that in Lightning is

00:09:39.970 --> 00:09:42.930
<v Aaron van Wirdum>that you have something called a penalty transaction or a justice transaction

00:09:42.930 --> 00:09:48.670
<v Aaron van Wirdum>which you've created with your channel partner earlier which allows you to

00:09:48.670 --> 00:09:54.360
<v Aaron van Wirdum>claim all of the funds from the channel. It's built on the cheating

00:09:54.360 --> 00:09:58.700
<v Aaron van Wirdum>transaction, basically. You now get to claim all the funds. However, this penalty

00:09:58.700 --> 00:10:03.340
<v Aaron van Wirdum>transaction needs to confirm within a certain amount of time after this cheating

00:10:03.340 --> 00:10:07.120
<v Aaron van Wirdum>transaction was transmitted. The channel partner can't spend the coins in the

00:10:07.120 --> 00:10:11.480
<v Aaron van Wirdum>meantime, so he will have to wait, let's say, a day or whatever it is. But then

00:10:11.480 --> 00:10:14.900
<v Aaron van Wirdum>it is very important that you actually get your penalty transaction included

00:10:14.900 --> 00:10:19.380
<v Aaron van Wirdum>within a day, because otherwise your channel partner runs off with the funds.

00:10:19.600 --> 00:10:19.720
<v Sjors Provoost>Yeah.

00:10:20.430 --> 00:10:24.130
<v Aaron van Wirdum>So in this case, if you're transmitting this penalty transaction or justice

00:10:24.130 --> 00:10:29.070
<v Aaron van Wirdum>transaction, and it has a low fee, which is very possible because you created a

00:10:29.070 --> 00:10:34.170
<v Aaron van Wirdum>transaction, who knows, weeks ago, possibly, it has a low fee, it's not

00:10:34.170 --> 00:10:38.050
<v Aaron van Wirdum>confirming, then you can actually use this trick to get a penalty transaction

00:10:38.050 --> 00:10:39.150
<v Aaron van Wirdum>confirmed faster.

00:10:39.330 --> 00:10:39.530
<v Sjors Provoost>Yeah.

00:10:39.790 --> 00:10:43.250
<v Aaron van Wirdum>Right? This is called Child Pays for Parent. Did we mention that?

00:10:43.350 --> 00:10:44.430
<v Sjors Provoost>I'm not sure, but that's what it's called.

00:10:44.570 --> 00:10:47.630
<v Aaron van Wirdum>That's what it's called. Okay, now we get to the problem.

00:10:47.890 --> 00:10:52.980
<v Sjors Provoost>Yes. I received a memo from my time machine. And it was a note from the future

00:10:52.980 --> 00:10:57.200
<v Sjors Provoost>that I recorded after the podcast or something. And it basically says that Child

00:10:57.200 --> 00:11:03.080
<v Sjors Provoost>Pays for Parent has been in Bitcoin Core mining support since 0.13. So

00:11:03.080 --> 00:11:07.520
<v Sjors Provoost>a while. Basically around the time when SegWit was introduced in the code.

00:11:08.270 --> 00:11:12.970
<v Aaron van Wirdum>Yeah, that sounds about right to me. Yeah, I remember that. Okay. Oh, before we

00:11:12.970 --> 00:11:16.770
<v Aaron van Wirdum>move on, I gave the Lightning example. It's not just useful for Lightning. It's

00:11:16.770 --> 00:11:22.470
<v Aaron van Wirdum>for any sort of these smart contracts setups where you need to have a transaction

00:11:22.470 --> 00:11:28.070
<v Aaron van Wirdum>confirmed before some sort of time lock expires. There are several of these kinds

00:11:28.070 --> 00:11:33.090
<v Aaron van Wirdum>of things, but Lightning is the best known one, I would say. Okay, moving on.

00:11:34.470 --> 00:11:35.170
<v Aaron van Wirdum>Ready to move on?

00:11:35.410 --> 00:11:35.990
<v Sjors Provoost>Yeah, I'm ready.

00:11:36.270 --> 00:11:41.970
<v Aaron van Wirdum>Okay, so here's the problem. The problem, Sjors, is that child pays for

00:11:41.970 --> 00:11:47.670
<v Aaron van Wirdum>parent works very well as long as the mempool isn't full.

00:11:48.550 --> 00:11:52.950
<v Aaron van Wirdum>There's a problem if the mempools are filling up and transactions are being

00:11:52.950 --> 00:11:58.660
<v Aaron van Wirdum>rejected because they have too low of a fee. Because in that scenario, you

00:11:58.660 --> 00:12:03.760
<v Aaron van Wirdum>might send this child pays for parents transaction, which has a high fee to

00:12:03.760 --> 00:12:08.400
<v Aaron van Wirdum>compensate for the previous low fee. But if the mempools are filling up and the

00:12:08.400 --> 00:12:13.380
<v Aaron van Wirdum>low fee transaction was actually rejected from the mempool or ejected from the

00:12:13.380 --> 00:12:19.110
<v Aaron van Wirdum>mempool, then the high fee child pays for parents follow up won't actually be

00:12:19.110 --> 00:12:22.890
<v Aaron van Wirdum>accepted in the mempool either because it's not referring to any previous

00:12:22.890 --> 00:12:28.010
<v Aaron van Wirdum>transaction. Yeah. So your child pays for parent trick to save your money from

00:12:28.010 --> 00:12:32.210
<v Aaron van Wirdum>being stolen on Lightning network, for example, is not going to work if mempools

00:12:32.210 --> 00:12:33.450
<v Aaron van Wirdum>are filling up, potentially.

00:12:33.450 --> 00:12:37.570
<v Sjors Provoost>Right, and that you know assumes that there's a big difference in fees in general

00:12:37.570 --> 00:12:40.330
<v Sjors Provoost>between the punishment transaction and you spending it.

00:12:41.200 --> 00:12:45.260
<v Aaron van Wirdum>Yeah, I guess there's several scenarios where something like this could happen,

00:12:45.420 --> 00:12:50.860
<v Aaron van Wirdum>Either a difference in fees or maybe the attacker in the channel is actually a

00:12:50.860 --> 00:12:56.400
<v Aaron van Wirdum>miner, him or herself, that includes the attack transaction at first, or

00:12:56.400 --> 00:13:02.040
<v Aaron van Wirdum>they know a miner, or there's an out-of-band payment, or I don't know. There's a

00:13:02.040 --> 00:13:07.160
<v Aaron van Wirdum>couple of scenarios, I guess, where this attack on Lightning network would work

00:13:07.160 --> 00:13:11.570
<v Aaron van Wirdum>if child pays for parent isn't working as intended on the base layer.

00:13:11.870 --> 00:13:15.290
<v Sjors Provoost>Yeah, and even outside Lightning, it's very annoying if child pays for parent

00:13:15.290 --> 00:13:18.290
<v Sjors Provoost>doesn't work when fees are really high, because that's exactly when you need it.

00:13:19.010 --> 00:13:23.670
<v Aaron van Wirdum>Yeah, I mean, there is also, of course, RBF replace by fee, but that's only

00:13:23.670 --> 00:13:27.950
<v Aaron van Wirdum>something the sender can use. While child pays for parents is also something the

00:13:27.950 --> 00:13:33.610
<v Aaron van Wirdum>recipients can use. Okay. So, we're getting to the solution. The solution

00:13:33.610 --> 00:13:36.970
<v Aaron van Wirdum>is package relay. This is what Gloria is going to be working on.

00:13:37.290 --> 00:13:40.070
<v Sjors Provoost>Yes. Well, the solution is called package relay.

00:13:40.670 --> 00:13:41.110
<v Aaron van Wirdum>Yes.

00:13:41.270 --> 00:13:45.250
<v Sjors Provoost>Whatever the solution is going to be, but it's not really solved yet. But

00:13:45.250 --> 00:13:48.510
<v Sjors Provoost>whatever it will be, it's going to be called package relay.

00:13:48.770 --> 00:13:53.310
<v Aaron van Wirdum>Yeah. Okay. So do you want to explain package relay? I think you can probably

00:13:53.310 --> 00:13:54.750
<v Aaron van Wirdum>explain it a little bit better than I can.

00:13:55.150 --> 00:14:00.370
<v Sjors Provoost>Well, I think you've done a good job, too. It's relaying transactions in a

00:14:00.370 --> 00:14:05.350
<v Sjors Provoost>package. So rather than saying, here is one transaction, and then a little bit

00:14:05.350 --> 00:14:10.160
<v Sjors Provoost>while later, here is one transaction, at… which, you know, if the second

00:14:10.160 --> 00:14:12.780
<v Sjors Provoost>transaction pays more fee, but you don't really explain the relation with the

00:14:12.780 --> 00:14:16.080
<v Sjors Provoost>first transaction, then you're going to have the problems we just described. But

00:14:16.080 --> 00:14:21.600
<v Sjors Provoost>if you say, look, here's two transactions, one is not paying a lot of fees, but

00:14:21.600 --> 00:14:25.860
<v Sjors Provoost>wait, there's more. This other one does pay enough fees. Please consider them

00:14:25.860 --> 00:14:30.880
<v Sjors Provoost>both in your mempool. Don't just eject the first one. Then the mempool will say,

00:14:31.120 --> 00:14:34.260
<v Sjors Provoost>oh, well, yeah, collectively they pay enough. I'm going to collectively keep

00:14:34.260 --> 00:14:35.120
<v Sjors Provoost>track of this thing.

00:14:35.480 --> 00:14:40.820
<v Aaron van Wirdum>Yeah. So I think here we get into… just to clarify this, so yeah,

00:14:40.980 --> 00:14:44.440
<v Aaron van Wirdum>instead of sending individual transactions, now we're sending packages of

00:14:44.440 --> 00:14:48.920
<v Aaron van Wirdum>transactions that bundle transactions together that are dependent on each other, right?

00:14:49.100 --> 00:14:49.220
<v Sjors Provoost>Yeah.

00:14:49.800 --> 00:14:53.200
<v Aaron van Wirdum>But I think, Sjors, is this where we get into the can of worms?

00:14:54.070 --> 00:14:58.170
<v Sjors Provoost>Well, we can, yeah, slowly enter this can of worms, yes.

00:14:58.990 --> 00:15:02.410
<v Aaron van Wirdum>Let's get into the kind of worms. What are the challenges here? What are the

00:15:02.410 --> 00:15:05.050
<v Aaron van Wirdum>problems that need to be solved for this to actually become reality?

00:15:06.290 --> 00:15:10.610
<v Sjors Provoost>Well, as with everything, you need to think about the ways this could be abused.

00:15:11.580 --> 00:15:17.060
<v Sjors Provoost>So it depends on how you would do it, right? So one proposal is by Suhas, which I

00:15:17.060 --> 00:15:23.050
<v Sjors Provoost>think is that the recipient… if you receive a transaction, so you consider it for

00:15:23.050 --> 00:15:27.010
<v Sjors Provoost>your mempool, but you don't know anything about its parents, so to you it looks

00:15:27.010 --> 00:15:30.550
<v Sjors Provoost>like… this standalone transaction, then you can call the peer that sent it to you

00:15:30.550 --> 00:15:35.670
<v Sjors Provoost>and say, hey, do you have, you know, a package for me that you know, gives me all

00:15:35.670 --> 00:15:39.350
<v Sjors Provoost>the transactions that precede this thing so that I can consider it as a whole?

00:15:39.910 --> 00:15:43.210
<v Sjors Provoost>Because if I just look at this one transaction, it doesn't look very appealing to

00:15:43.210 --> 00:15:47.520
<v Sjors Provoost>me, but maybe you can convince me otherwise. And then the original node can say,

00:15:47.640 --> 00:15:52.340
<v Sjors Provoost>okay, here's a whole package. But that could lend itself to abuse because you

00:15:52.340 --> 00:15:57.620
<v Sjors Provoost>could send me a transaction and say, yeah, you know, there's more. And I ask you

00:15:57.620 --> 00:16:00.520
<v Sjors Provoost>for more and you sent me a whole bunch of junk. And I'm like, no, this is

00:16:00.520 --> 00:16:04.720
<v Sjors Provoost>nonsense. Try again. And you sent me a whole bunch of junk again. So there's all

00:16:04.720 --> 00:16:09.580
<v Sjors Provoost>this back and forth. But perhaps that's not a big deal because [unclear]

00:16:09.580 --> 00:16:13.680
<v Sjors Provoost>misbehaving that way, you just disconnect it. And you could have some limits,

00:16:13.680 --> 00:16:17.820
<v Sjors Provoost>like, okay, give me everything that leads to this transaction. You could send me

00:16:17.820 --> 00:16:21.360
<v Sjors Provoost>two gigabytes of unconfirmed transactions and say, here's two gigabytes, go

00:16:21.360 --> 00:16:24.360
<v Sjors Provoost>consider them all. And they're like super complicated transactions and I have to

00:16:24.360 --> 00:16:27.400
<v Sjors Provoost>consider them all. And then the last one is like, nope, sorry, it's invalid, try

00:16:27.400 --> 00:16:31.800
<v Sjors Provoost>again. So these kind of things you need to worry about and also where to store

00:16:31.800 --> 00:16:36.650
<v Sjors Provoost>all it. And then I guess the other part of the can of worms is now they are in

00:16:36.650 --> 00:16:40.850
<v Sjors Provoost>the mempool. When are you going to evict transactions? Because when you want to

00:16:40.850 --> 00:16:45.450
<v Sjors Provoost>kick them out of the mempool, you also need to consider the package. So that

00:16:45.450 --> 00:16:50.950
<v Sjors Provoost>probably means you need to refactor the way this mempool works right now in

00:16:50.950 --> 00:16:51.430
<v Sjors Provoost>Bitcoin Core.

00:16:51.770 --> 00:16:55.510
<v Aaron van Wirdum>Well, it would probably be similar to how miners select transactions now, right?

00:16:56.170 --> 00:17:00.390
<v Aaron van Wirdum>That would basically be the same logic, I would assume. It's just on a bigger scale.

00:17:00.650 --> 00:17:05.870
<v Sjors Provoost>It could be, but it's not a trivial problem. I think the way miners do this

00:17:05.870 --> 00:17:10.340
<v Sjors Provoost>selection is… I don't know if it's NP-hard, but it's hard. There's lots of

00:17:10.340 --> 00:17:14.660
<v Sjors Provoost>different ways you can do it. And you're not making money running a node, so you

00:17:14.660 --> 00:17:19.650
<v Sjors Provoost>don't want to waste a whole bunch of CPU power trying to optimize the mempool and

00:17:19.650 --> 00:17:22.350
<v Sjors Provoost>have your computer boil just because it's trying to optimize the mempool.

00:17:22.730 --> 00:17:28.290
<v Aaron van Wirdum>Right. So I think you took a quick look at Gloria's proposal work so far?

00:17:28.630 --> 00:17:32.790
<v Sjors Provoost>Yeah, so she's taking one little step at a time because one of the problems with

00:17:32.790 --> 00:17:37.270
<v Sjors Provoost>this is we look at the problem, we as Core developers, I haven't actually

00:17:37.270 --> 00:17:42.650
<v Sjors Provoost>personally looked at the problem, and… we say, yeah, this is really hard. And

00:17:42.650 --> 00:17:46.110
<v Sjors Provoost>there's so many things we need to change. Oh man, there's all these possible

00:17:46.110 --> 00:17:49.670
<v Sjors Provoost>things that could go wrong. Let's just take this can down the road and not think

00:17:49.670 --> 00:17:53.570
<v Sjors Provoost>about it. So it's good that some people say, no, you know what? Let's just take

00:17:53.570 --> 00:17:58.740
<v Sjors Provoost>the absolute minimum first step that we can take. And I believe what Gloria is

00:17:58.740 --> 00:18:03.260
<v Sjors Provoost>doing as the very first step, and she has a whole year to work on this stuff, is

00:18:03.260 --> 00:18:07.600
<v Sjors Provoost>to say, okay, what if you have your own node and you can talk to it through RPC?

00:18:07.920 --> 00:18:11.930
<v Sjors Provoost>So not through the peer-to-peer network, but just directly to it. And instead of

00:18:11.930 --> 00:18:15.850
<v Sjors Provoost>giving it one transaction to consider, not even to broadcast, just to consider,

00:18:16.030 --> 00:18:20.710
<v Sjors Provoost>because there's a special method that says testmempoolaccept that just says, hey,

00:18:20.810 --> 00:18:23.790
<v Sjors Provoost>is this transaction valid based on the mempool? And it says yes or no or

00:18:23.790 --> 00:18:28.070
<v Sjors Provoost>something complicated. And instead of giving it one transaction, let's be able to

00:18:28.070 --> 00:18:32.590
<v Sjors Provoost>give it more than one transaction. So you can actually now give your own node a

00:18:32.590 --> 00:18:37.570
<v Sjors Provoost>package of transactions. And from what I just glanced at, I think the first

00:18:37.570 --> 00:18:41.490
<v Sjors Provoost>version of that is is very simple. It just takes that package and considers them

00:18:41.490 --> 00:18:45.630
<v Sjors Provoost>one by one, so it doesn't do any overarching considerations. That gives you an

00:18:45.630 --> 00:18:49.590
<v Sjors Provoost>idea of the little baby steps we try to take to get this thing underway.

00:18:50.270 --> 00:18:52.310
<v Aaron van Wirdum>Yeah, and then the next step would be?

00:18:52.650 --> 00:18:56.850
<v Sjors Provoost>Well, the next step would be, I would guess, to say, okay, is this package as a

00:18:56.850 --> 00:19:01.310
<v Sjors Provoost>whole acceptable? So instead of considering them one by one, you would look at

00:19:01.310 --> 00:19:05.870
<v Sjors Provoost>the whole package. And I think one of the steps there is to sort the package so

00:19:05.870 --> 00:19:11.700
<v Sjors Provoost>that they come in in order of whose parent is who. And I guess then you

00:19:11.700 --> 00:19:16.810
<v Sjors Provoost>have to look at the total fees for it and see if it's still acceptable. Then once

00:19:16.810 --> 00:19:20.810
<v Sjors Provoost>you've done that, I think the next step is to say, okay, let's actually put that

00:19:20.810 --> 00:19:25.290
<v Sjors Provoost>package into the mempool, which might, I don't know, require rewriting the whole

00:19:25.290 --> 00:19:28.790
<v Sjors Provoost>mempool. I don't know. And then if that works, then at least your own node

00:19:28.790 --> 00:19:32.730
<v Sjors Provoost>understands packages. Now the question is, can we add this to the peer-to-peer

00:19:32.730 --> 00:19:37.250
<v Sjors Provoost>protocol? And that's really where the DoS vulnerabilities are the most important

00:19:37.250 --> 00:19:40.950
<v Sjors Provoost>to think about. Because what you do with your own node, you can't really break

00:19:40.950 --> 00:19:46.030
<v Sjors Provoost>it. But once you start chatting over the network, you want to be careful. And if

00:19:46.030 --> 00:19:49.790
<v Sjors Provoost>your rules are too complicated, you might accidentally get nodes banned, even

00:19:49.790 --> 00:19:52.430
<v Sjors Provoost>though they didn't do anything wrong intentionally, and that might split the

00:19:52.430 --> 00:19:54.870
<v Sjors Provoost>network. So it just gets hairy from there.

00:19:55.250 --> 00:19:57.650
<v Aaron van Wirdum>Well, Gloria, if you're listening, good luck with that.

00:19:57.830 --> 00:19:58.350
<v Sjors Provoost>Yeah, have fun.

00:19:59.490 --> 00:20:01.410
<v Aaron van Wirdum>I think this is our episode. Is it not, Sjors?

00:20:01.590 --> 00:20:05.990
<v Sjors Provoost>Yeah, I think so. We can do a quick shout out to the Chaincode guys for their

00:20:05.990 --> 00:20:10.830
<v Sjors Provoost>podcast. They did one with Murch talking about deterministic builds, which is a

00:20:10.830 --> 00:20:11.690
<v Sjors Provoost>huge can of worms.

00:20:11.930 --> 00:20:12.270
<v Aaron van Wirdum>Okay.

00:20:12.450 --> 00:20:14.570
<v Sjors Provoost>If you're into can of worms, deterministic builds.

00:20:14.890 --> 00:20:18.570
<v Aaron van Wirdum>Speaking of shout outs, Gloria's fellowship is going to be sponsored by Square

00:20:18.570 --> 00:20:22.070
<v Aaron van Wirdum>Crypto and the Human Rights Foundation. That's probably worth a mention, right?

00:20:22.390 --> 00:20:23.530
<v Sjors Provoost>Yeah, it's pretty cool that they're doing that.

00:20:23.710 --> 00:20:23.830
<v Aaron van Wirdum>Yep.

00:20:24.110 --> 00:20:27.190
<v Sjors Provoost>All right. I think that's it. So thank you for listening to the

00:20:27.190 --> 00:20:28.310
<v Sjors Provoost>Van Wirdum Sjorsnado.

00:20:28.930 --> 00:20:29.630
<v Aaron van Wirdum>There you go.