WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode. 00:00:08.720 --> 00:00:11.440 Live from Utrecht, this is Van Wirdum Sjorsnado. 00:00:11.660 --> 00:00:12.900 Hello, welcome back. 00:00:13.440 --> 00:00:14.440 Thank you, Sjors. 00:00:15.600 --> 00:00:16.240 Was it warm? 00:00:16.980 --> 00:00:18.300 Yeah, it's warm here as well. 00:00:18.480 --> 00:00:19.000 Was it fun? 00:00:19.300 --> 00:00:20.180 It was a lot of fun. 00:00:20.360 --> 00:00:20.500 Cool. 00:00:20.740 --> 00:00:24.580 Yeah, Bitcoin 2021 was a lot of fun. I recommend it. 00:00:24.860 --> 00:00:25.180 All right. 00:00:25.400 --> 00:00:26.440 I recommend going, Sjors. 00:00:26.980 --> 00:00:27.800 I'll think about it. 00:00:27.860 --> 00:00:28.660 Check it out next time. 00:00:29.020 --> 00:00:32.020 Yeah, I think I FOMO bought the 2022 ticket. 00:00:32.260 --> 00:00:36.180 Yeah, actually, so I think you read that, but we're thinking of, well, we're not 00:00:36.180 --> 00:00:40.900 just thinking about it. We're going to wrap up some kind of deal for open source 00:00:40.900 --> 00:00:46.500 developers. Details to be announced and to be figured out, I think. But we're 00:00:46.500 --> 00:00:51.160 we're playing… on planning… on some sort of I don't know, access for… 00:00:51.340 --> 00:00:55.560 So now I have a short Bitcoin position for no good reason. Okay, awesome. 00:00:56.370 --> 00:01:01.990 Yeah, but yeah, being back in the Netherlands is nice. It's just as hot here as 00:01:01.990 --> 00:01:02.670 it was in Miami. 00:01:03.050 --> 00:01:04.310 Yep, except no air conditioning. 00:01:04.590 --> 00:01:09.150 Except, yeah, that's the big difference. At least in Miami, at least in the 00:01:09.150 --> 00:01:12.130 United States, if you're inside somewhere, then it's cool. But in the 00:01:12.130 --> 00:01:14.510 Netherlands, you're just going to be sweating inside all day long. 00:01:14.930 --> 00:01:15.150 Yep. 00:01:16.570 --> 00:01:21.010 The other thing that happened last week, besides me returning to the great 00:01:21.010 --> 00:01:23.330 country of the Netherlands, is Sjors? 00:01:23.970 --> 00:01:24.450 Taproot. 00:01:24.610 --> 00:01:25.310 Taproot locks in. 00:01:25.700 --> 00:01:28.520 And not just locked in, but locked underscore in. 00:01:28.720 --> 00:01:29.480 We did it. 00:01:29.680 --> 00:01:32.760 We did. Well, we didn't, but people did. 00:01:34.430 --> 00:01:37.930 Sure, sure. We're going to discuss Taproot. We're going to discuss Taproot one 00:01:37.930 --> 00:01:42.850 more time, I think. This is going to be the last time we've discussed Taproot 00:01:42.850 --> 00:01:48.410 itself. We've then had, I think, two or maybe even three episodes on 00:01:48.410 --> 00:01:51.430 soft fork activation, Taproot activation. 00:01:51.850 --> 00:01:52.030 Yep. 00:01:52.570 --> 00:01:58.510 Two probably right? And… or maybe one on Speedy Trial. Anyways a bunch of 00:01:58.510 --> 00:02:04.500 them. And now we're gonna do one more on Taproot lock in. So 00:02:04.820 --> 00:02:09.240 let's let's start at the beginning. What does Taproot lock in mean? Recap a 00:02:09.240 --> 00:02:13.440 little bit for our listeners that maybe missed previous episodes. What does it 00:02:13.440 --> 00:02:14.780 mean that Taproot has locked in? 00:02:14.780 --> 00:02:20.490 Right, so for every soft fork there is at least as of you know the last six seven 00:02:20.490 --> 00:02:25.970 years, there is this mechanism, BIP 9, BIP 8, it kind of varies. But the idea is 00:02:25.970 --> 00:02:30.810 that a soft fork can be in multiple states. It's a state machine. And the first 00:02:30.810 --> 00:02:34.230 state it would be in is defined, defined… And defined just means this soft fork 00:02:34.230 --> 00:02:39.570 exists. We know about it. Then there's a soft fork state called started. 00:02:39.890 --> 00:02:44.910 And that means that miners could… can signal for it. And so that means that when 00:02:44.910 --> 00:02:49.340 a soft fork is started, all nodes are paying attention to that signal. And then 00:02:49.340 --> 00:02:49.920 the... 00:02:49.920 --> 00:02:53.640 And the signal is just a bit of data in a Bitcoin block, in the Bitcoin block they mine. 00:02:54.020 --> 00:02:58.120 Yeah, in the header, there's just a bit, yeah, a bit is flagged. 00:02:58.220 --> 00:03:01.420 So nodes start counting miner signaling, yep. 00:03:01.600 --> 00:03:07.280 Yeah, and if they're signaling, you know, that way before a BIP is, sorry, 00:03:07.380 --> 00:03:12.860 before a soft fork is in the started state, then that signal is just noise, it's 00:03:12.860 --> 00:03:17.580 ignored. But there are some nodes might look at that and say, hey, I'm seeing 00:03:17.580 --> 00:03:20.800 some signaling. I don't understand what this is. And they might warn the user 00:03:20.800 --> 00:03:25.400 saying that there might be a soft fork that you don't know about. Anyway, this 00:03:25.400 --> 00:03:29.920 signaling took place. It crossed a certain threshold. And then it went into the 00:03:29.920 --> 00:03:34.320 next state, which is called locked in. And it's going to remain in that state 00:03:34.320 --> 00:03:37.740 until block number 709,632. 00:03:38.630 --> 00:03:42.930 Yeah, so we used the Speedy Trial activation mechanism, which we discussed 00:03:42.850 --> 00:03:47.730 discussed in the previous episode, which meant that miners had about three months 00:03:47.730 --> 00:03:53.530 to signal support. And if 90% of miners would signal support within within one 00:03:53.530 --> 00:03:57.710 difficulty period, that means the soft fork would be locked in, which means it 00:03:57.710 --> 00:04:02.550 would activate later. So that happened last week. Taproot got locked in. And like 00:04:02.550 --> 00:04:05.150 you said, that means it's going to activate at block [unclear]… 00:04:06.980 --> 00:04:13.100 709,632, which is scheduled to be mined in November of this year. 00:04:13.280 --> 00:04:16.540 Well, it's not scheduled, but it's expected to be mined in November of this year. 00:04:16.660 --> 00:04:21.420 Right. The other thing I guess is worth noting because, you know, we also had the 00:04:21.420 --> 00:04:25.720 episode about the different activation mechanisms and sort of the alternative 00:04:25.720 --> 00:04:30.860 clients that did... something very similar but slightly different, without 00:04:30.860 --> 00:04:35.500 getting into the details of that one, we can just safely say at this point that 00:04:35.500 --> 00:04:41.270 will also activate Taproot at this same block presumably in 00:04:41.270 --> 00:04:41.670 November. 00:04:41.670 --> 00:04:46.230 Yes, so I would assume that at this point there's no point in running that 00:04:46.230 --> 00:04:47.430 alternative client anymore. 00:04:47.970 --> 00:04:52.830 Yeah, I tend to agree with that. At this point, it's probably better to just run 00:04:52.830 --> 00:04:58.390 Bitcoin Core 0.21.1 or any newer Bitcoin Core release that's 00:04:58.390 --> 00:04:59.010 upcoming. 00:04:59.570 --> 00:05:00.530 Yes, exactly. 00:05:01.280 --> 00:05:05.480 Um and that's that's basically for those that don't know that because I've seen 00:05:05.480 --> 00:05:09.520 some questions about that, um you know people asking how to prepare for Taproot 00:05:09.520 --> 00:05:14.140 or how to get ready. That's basically as simple as it is: upgrades to Bitcoin 00:05:14.140 --> 00:05:20.000 Core 0.21.1 or a newer version of Bitcoin Core or potentially if 00:05:20.000 --> 00:05:24.760 that's what you're into some alternative um client or implementation that also 00:05:24.760 --> 00:05:27.200 enforces Taproot, but I don't know which ones these… 00:05:27.200 --> 00:05:32.820 Yeah, I think at the moment none do. I know that libbitcoin is working on it. 00:05:31.160 --> 00:05:34.520 Well, apart from the alternative activation client then. Yeah, 00:05:34.740 --> 00:05:40.700 Exactly. So I think libbitcoin and btcd are working on Taproot, but they 00:05:40.700 --> 00:05:44.780 haven't done it yet. So you can't run their code yet to check for Taproot rules. 00:05:45.740 --> 00:05:50.480 So at this point, basically just upgrade to Bitcoin Core 0.21.1. I guess it's 00:05:50.480 --> 00:05:52.660 our... That's the way to do it. 00:05:52.780 --> 00:05:56.000 And if you really want to use the cool features that are going to be in Taproot, 00:05:56.260 --> 00:05:59.460 like wallet support, we'll get to that later. But then you're going to need 00:05:59.460 --> 00:06:05.060 Bitcoin Core version 22, which will come out later. But you don't have to do that. 00:06:06.360 --> 00:06:09.760 I think I could just finish the list of states because we were talking about it. 00:06:09.940 --> 00:06:13.540 So it starts with defined, then it's started, then it's locked in, which is where 00:06:13.540 --> 00:06:17.920 we're now. Then it becomes active. And active just means what what you think it 00:06:17.920 --> 00:06:19.580 means. It means the rules apply. 00:06:21.290 --> 00:06:24.510 And, well, that's good. That's what's going to happen. And it's going to stay 00:06:24.510 --> 00:06:28.750 there forever. Well, at some point, a new version might be released that just 00:06:28.750 --> 00:06:33.750 assumes it's active and doesn't explicitly say it anymore. It could have also 00:06:33.750 --> 00:06:36.250 reached the state failed. 00:06:37.280 --> 00:06:38.640 Right. But it didn't. 00:06:38.740 --> 00:06:39.200 It didn't. 00:06:39.850 --> 00:06:44.960 One thing. Okay. I noticed, and that's another thing I saw questions about, so 00:06:44.960 --> 00:06:50.020 let me jump right to that point. Luke Jr., Luke Dashjr, he has this 00:06:50.020 --> 00:06:55.620 node graph thing on his special website where it says that 25% 00:06:55.620 --> 00:07:01.230 of nodes on the network right now are ready for Taproot. I've seen some concern 00:07:01.230 --> 00:07:06.370 about that. So let's maybe detail what that means exactly. 00:07:07.570 --> 00:07:12.890 Yeah, I'm assuming that means 25% of the nodes that Luke knows about. And 00:07:12.890 --> 00:07:16.610 there's only two ways you can, well, there's kind of three ways you can learn 00:07:16.610 --> 00:07:20.630 about a node. One is the easiest way the node connects to you and says, hello, 00:07:20.750 --> 00:07:23.350 I'm a node. So you can remember where that came from. 00:07:24.650 --> 00:07:30.230 The other is that you connect to it. And that requires it to be open to 00:07:30.230 --> 00:07:34.290 connections. It has to be a listening node, as it's called. Otherwise, you can't 00:07:34.290 --> 00:07:34.750 connect to it. 00:07:36.190 --> 00:07:39.930 But there's also this gossiping system we talked about in another episode where 00:07:39.930 --> 00:07:45.030 nodes gossip addresses of nodes. But the only addresses that are gossiped are 00:07:45.030 --> 00:07:51.030 of nodes that are listening. So the addresses that are being gossiped around are 00:07:51.030 --> 00:07:54.690 a subset of all the nodes that actually exist, because there is absolutely no 00:07:54.690 --> 00:07:57.570 point in gossiping about a node that you know is not listening. 00:07:59.360 --> 00:08:03.080 And of course, you know, nodes might be gossiping about nodes that are long dead, 00:08:03.510 --> 00:08:04.730 but are just gone. 00:08:05.190 --> 00:08:06.670 Two questions. One. 00:08:06.730 --> 00:08:11.870 So a quarter of, you know, is kind of a vague number. It probably means a quarter 00:08:11.870 --> 00:08:17.150 of mostly listening nodes, which is not all the nodes. And the other thing to 00:08:17.150 --> 00:08:20.970 consider is, you know, the phenomena of astroturfing. I can spin up a million 00:08:20.970 --> 00:08:24.970 nodes tomorrow. Well, I can't because it's really expensive. But, you know. 00:08:25.510 --> 00:08:27.630 Michael Saylor could spin up a million nodes tomorrow. 00:08:27.790 --> 00:08:32.430 A rich version of you could do it. Michael Saylor probably, well, is he technical enough? 00:08:32.550 --> 00:08:36.550 And, you know, Blue Matt could probably spin up one node and make it look like a 00:08:36.550 --> 00:08:41.030 million nodes by messing with DNS because he knows how to do that. I don't. But, 00:08:41.090 --> 00:08:42.890 yeah. Anyway, continue. 00:08:44.460 --> 00:08:48.410 I'm going to skip my first question. Because that was going to be a joke and it 00:08:48.410 --> 00:08:51.350 doesn't work anymore. So I'm going to go straight to my second question. 00:08:51.390 --> 00:08:56.150 Well, we can do your joke and have the editor move the joke to before what I just said. 00:08:56.310 --> 00:09:01.110 No, I'm just going to skip it altogether. My question was, is this a problem? 25% 00:09:01.110 --> 00:09:04.530 nodes are ready. Is this a problem? Is it a problem that it's not more? 00:09:05.250 --> 00:09:07.750 Oh, I was going to say, why would it be a problem that nodes are ready? 00:09:08.090 --> 00:09:09.890 No, that it's not 100%. 00:09:10.600 --> 00:09:15.340 No, it's quite early. So the whole idea of the Speedy Trial was to see if there 00:09:15.340 --> 00:09:19.600 was any hope of activating this thing. While the Speedy Trial is in progress, you 00:09:19.600 --> 00:09:23.020 don't have to check the Taproot rules. There's no reason for it. All you want to 00:09:23.020 --> 00:09:28.480 do is make sure that you're checking the Taproot rules before it activates. So 00:09:28.480 --> 00:09:32.780 you could have done it before the Speedy Trial, or you can start doing it 00:09:32.780 --> 00:09:38.280 now-ish. You have until October or November. So take your time, but 00:09:38.280 --> 00:09:39.020 don't forget. 00:09:39.610 --> 00:09:43.710 What's the problem if people do forget? You want to get into that? Let's get into 00:09:43.710 --> 00:09:44.190 that briefly. 00:09:44.150 --> 00:09:44.600 [unclear] 00:09:44.190 --> 00:09:47.630 Why is it important that people actually do upgrade before November? 00:09:47.630 --> 00:09:53.570 So in a certain sense for yourself, it's probably not a problem unless 00:09:53.570 --> 00:09:59.420 somebody's really really motivated to mess with you um but or 00:09:59.420 --> 00:10:03.400 if there's like real big problems on the network that that are sort of outside 00:10:03.400 --> 00:10:08.460 what you know but you know big reorgs um if you know if suddenly a huge reorg 00:10:08.460 --> 00:10:12.550 happens and you don't understand what's going on, it probably might have 00:10:12.550 --> 00:10:16.810 something to do with somebody not obeying the Taproot rules and getting punished 00:10:16.810 --> 00:10:21.660 for it. So I guess one scenario we could describe is 00:10:21.660 --> 00:10:26.980 you are running an old node, and you're receiving coins, you're just using 00:10:26.980 --> 00:10:32.860 regular SegWit, and those coins are coming from a Taproot address, or 00:10:32.860 --> 00:10:36.700 so you think. So you're looking at a Block Explorer, and you see that these coins 00:10:36.700 --> 00:10:37.760 are coming from a Taproot address. 00:10:38.970 --> 00:10:44.390 But it turns out that this transaction is actually fake. It's not actually a 00:10:44.390 --> 00:10:48.050 Taproot transaction. It has a Schnorr signature, but somebody flipped a bit 00:10:48.050 --> 00:10:53.130 around. So for all the nodes that do run Taproot, they can see that that 00:10:53.130 --> 00:10:54.010 transaction is invalid. 00:10:55.580 --> 00:10:59.480 And you should not be seeing that transaction normally because there's all sorts 00:10:59.480 --> 00:11:04.380 of defense mechanisms against that. Your mempool won't see it. So you'll only see 00:11:04.380 --> 00:11:08.300 it if it's in a block. So somebody would have to make an invalid block and give 00:11:08.300 --> 00:11:13.630 it to you. But they might be able to do that with an Eclipse attack. So then 00:11:13.630 --> 00:11:17.730 something would look like, oh, somebody just paid [unclear] Taproot address. I 00:11:17.730 --> 00:11:22.240 haven't upgraded. Okay, fine. I'm accepting that confirmation. And I'm going to 00:11:22.240 --> 00:11:25.710 send you the Lambo. That's sort of your scenario. 00:11:26.030 --> 00:11:29.870 The point being, if I'm going to summarize that in two sentences, is that we want 00:11:29.870 --> 00:11:33.630 the whole network to be in consensus and see the same blocks and see the same 00:11:33.630 --> 00:11:37.530 transactions. So if there's a significant part or even a small part of the 00:11:37.530 --> 00:11:42.890 network that's not enforcing the same rules, then it could become messy if miners 00:11:42.890 --> 00:11:44.730 start messing around. 00:11:44.970 --> 00:11:48.070 So that's actually the second scenario I would say. So the first one I described 00:11:48.070 --> 00:11:51.290 was really just your own interest. It's like somebody might be messing with you 00:11:51.290 --> 00:11:53.440 in the... convoluted way I just described. 00:11:53.680 --> 00:11:53.860 Sure. 00:11:54.220 --> 00:11:59.520 But the other reason is more systemic. If you end up with very few people 00:11:59.520 --> 00:12:03.820 actually enforcing the rules, some miner might mine an invalid block, even 00:12:03.820 --> 00:12:08.930 accidentally. And other miners, if they're also not verifying the rules, which is 00:12:08.930 --> 00:12:13.330 be building on top of that block, and your node will just be accepting those 00:12:13.330 --> 00:12:18.750 blocks. But then one day, you do upgrade, or somebody else... 00:12:19.820 --> 00:12:25.800 some exchange or somebody important. And they certainly say, hey, the last 00:12:25.800 --> 00:12:30.020 one year worth of blocks is invalid. What the hell is going on? And we end up 00:12:30.020 --> 00:12:31.460 with a complete disaster. 00:12:31.940 --> 00:12:32.920 Yeah, that's it. 00:12:33.000 --> 00:12:36.160 So you don't want a situation where, where miners are building on top of blocks 00:12:36.160 --> 00:12:39.340 that are invalid, like, that would assume that the miners aren't enforcing it and 00:12:39.340 --> 00:12:42.880 that nobody else in the economic system isn't enforcing it. And that's, that's 00:12:42.880 --> 00:12:43.300 quite bad. 00:12:43.480 --> 00:12:47.700 Yeah, that's a good way of separating the two concerns, I guess. It's partly for 00:12:47.700 --> 00:12:51.800 your own benefits to upgrade, and it's also partly to everyone's benefit if 00:12:51.800 --> 00:12:52.600 everyone upgrades. 00:12:52.820 --> 00:12:56.180 Yeah, and not just you, but everybody you know, and especially every exchange 00:12:56.180 --> 00:12:56.720 you're using. 00:12:58.180 --> 00:12:59.800 Yeah if you're using one uh 00:12:59.800 --> 00:13:04.040 But I think to get back to your previous point, we're not too concerned about 00:13:04.040 --> 00:13:07.720 this. The whole point of Speedy Trial was that it's going to be speedy, and now 00:13:07.720 --> 00:13:11.320 people have a few more months to upgrade, which should hopefully be enough for 00:13:11.320 --> 00:13:16.720 you know, a lot of people, yes, as well as miners. And in this scenario that it… 00:13:16.720 --> 00:13:21.440 even if it's just a majority of miners that's upgraded as the signaling suggests 00:13:21.440 --> 00:13:26.990 they have, then… then it's going to be fine either way more or less. You know, 00:13:27.070 --> 00:13:30.570 it's ideal if people actually enforce the rules, but at least they wouldn't split 00:13:30.570 --> 00:13:31.530 the network in that case. 00:13:31.790 --> 00:13:36.230 Yeah, it gives you a little bit more time to upgrade. But, you know, it's like 00:13:36.230 --> 00:13:40.730 defense in depth, right? So if you don't upgrade, well, the miners have upgraded, 00:13:40.730 --> 00:13:44.190 so you're still okay. And even if they haven't, there's still some fallback 00:13:44.190 --> 00:13:48.620 mechanisms. But you don't want to rely on the last line of defense for this sort of stuff. 00:13:49.100 --> 00:13:49.460 Yeah. 00:13:49.680 --> 00:13:50.520 That's defense in depth. 00:13:50.540 --> 00:13:52.340 I want to move on to the next point. 00:13:52.560 --> 00:13:52.740 Okay. 00:13:54.180 --> 00:13:56.540 By the way, Sjors, it's pretty warm in here. 00:13:56.980 --> 00:13:57.540 I know. 00:13:57.720 --> 00:13:58.620 I'm sweating a lot. 00:13:59.040 --> 00:13:59.580 I know. 00:13:59.700 --> 00:14:00.100 A lot. 00:14:00.850 --> 00:14:01.630 Oh, no. 00:14:03.180 --> 00:14:09.180 Let's move on. I'm trying to concentrate on… Taproot activation. 00:14:09.580 --> 00:14:12.940 Taproot lock-in. No, let's focus on Taproot activation. That's the next point. 00:14:13.220 --> 00:14:18.860 All right, so what if it's activated? What can we expect? What 00:14:18.860 --> 00:14:23.540 is the Bitcoin Core wallet going to do for us? Let's move to that point. 00:14:24.100 --> 00:14:24.520 Yes. 00:14:25.140 --> 00:14:26.740 Why should everyone be happy? 00:14:27.810 --> 00:14:31.730 Well, let's first start with something really dull and boring before we go there, 00:14:31.770 --> 00:14:37.070 but it is Bitcoin Core related. So in the next, hopefully grandiose version of 00:14:37.070 --> 00:14:42.960 Bitcoin Core version 22, there's going to be a new RPC method that will tell 00:14:42.960 --> 00:14:43.380 you... 00:14:43.380 --> 00:14:44.260 What is an RPC method? 00:14:45.200 --> 00:14:49.500 It's sort of a command line thing that you can use against your node. Or you can 00:14:49.500 --> 00:14:50.480 do it in the little window. 00:14:50.780 --> 00:14:54.080 You can plug software in it and programs and do stuff with your node, right? 00:14:54.300 --> 00:14:58.620 Yeah, exactly. So it's not in the graphical interface, but it is pretty easy to 00:14:58.620 --> 00:15:04.080 use. And this will tell you how many miners are still signaling. Because the idea 00:15:04.080 --> 00:15:07.880 is that during this lock-in phase, miners should continue to signal. They don't 00:15:07.880 --> 00:15:11.950 have to, but... it's recommended so that you can see that miners upgraded and 00:15:11.950 --> 00:15:14.570 didn't accidentally downgrade or, you know, forgot that they upgraded. 00:15:15.870 --> 00:15:20.290 So it'll be possible to monitor that, monitor that. So that's good. 00:15:21.530 --> 00:15:25.890 But maybe that's, you know, is that all we're going to get for Taproot? Like 00:15:25.890 --> 00:15:29.130 being able to see if it exists probably, you know, maybe you want to do a little 00:15:29.130 --> 00:15:29.630 bit more. 00:15:30.870 --> 00:15:36.070 So the other thing that Bitcoin Core is working on is support for wallets 00:15:36.070 --> 00:15:37.990 that actually have Taproot. 00:15:38.960 --> 00:15:39.360 Nice. 00:15:40.100 --> 00:15:44.960 And hopefully, well, definitely some of that will be in version 22, 00:15:44.960 --> 00:15:48.500 but hopefully a lot of it. 00:15:50.060 --> 00:15:56.020 I did not mean that as a pun, by the way. So the first thing that would be in 00:15:56.020 --> 00:16:01.040 the wallet is a way to watch these Taproot addresses. 00:16:02.200 --> 00:16:05.900 So they would be watch only. You wouldn't be able to spend from them, but you'd 00:16:05.900 --> 00:16:06.640 be able to watch them. 00:16:06.820 --> 00:16:07.160 Right. 00:16:09.060 --> 00:16:14.160 Really any kind. No, those would only be very simple Taproot addresses too. So 00:16:14.160 --> 00:16:19.220 for example, you're receiving just on a public key or you can have some scripts, 00:16:19.620 --> 00:16:23.960 but only very simple scripts. So in other words, you cannot do some super 00:16:23.960 --> 00:16:29.140 sophisticated multi-sig setup yet in Bitcoin Core, not even to watch it. So this 00:16:29.140 --> 00:16:30.640 is all just one step at a time. 00:16:32.150 --> 00:16:36.470 We're talking about Bitcoin Core. 22, right? The upcoming release. 00:16:36.650 --> 00:16:39.590 Yeah, and that part is already in it. So I think that'll make it into the release. 00:16:39.710 --> 00:16:42.730 So you can monitor what's going on on the network, basically? 00:16:43.010 --> 00:16:47.390 Well, you can create a watch-only wallet. It's just that if you want to spend it, 00:16:47.710 --> 00:16:52.610 now you need to do something manually. So the next step, of course, is that 00:16:52.610 --> 00:16:56.990 Bitcoin Core can also sign Taproot transactions. But again, only very simple 00:16:56.990 --> 00:16:57.830 Taproot transactions. 00:17:00.110 --> 00:17:03.130 And from the last time I checked, the simplest... 00:17:03.130 --> 00:17:07.190 So to recap that real brief in like 10 seconds, because we haven't mentioned this 00:17:07.190 --> 00:17:12.110 at all yet, but Taproot allows for all sorts of complex spending conditions. 00:17:13.020 --> 00:17:18.630 And in an ideal scenario, spending... from these 00:17:18.630 --> 00:17:22.510 conditions will be indistinguishable from a regular transaction. 00:17:23.030 --> 00:17:25.690 Yeah, so that regular transaction is the thing that's been implemented. 00:17:25.730 --> 00:17:29.550 Yeah, there are also regular transactions, even in Taproot, and that's going to 00:17:29.550 --> 00:17:32.250 be implemented in Bitcoin Core 22, is that what you said? 00:17:32.450 --> 00:17:36.590 Yeah, at least in some experimental part of it, right? It's probably not going to 00:17:36.590 --> 00:17:37.290 be on by default. 00:17:38.530 --> 00:17:43.290 So you can't do the very complex stuff yet in Bitcoin Core 22, but you can do the 00:17:43.290 --> 00:17:47.710 simple spends that are actual… still Taproot spends that look like a Taproot spend. 00:17:47.710 --> 00:17:52.990 Yeah, so you can just create a receive address, you know, that starts with 1BCP, 00:17:53.230 --> 00:17:53.810 I think. 00:17:54.950 --> 00:17:55.390 BC1P. 00:17:55.390 --> 00:18:01.190 Oh, BC1P, yeah. Instead of BC1Q, it starts with BC1P. And 00:18:01.190 --> 00:18:05.860 so you'll be able to receive coins on that. You can already try it on Signet 00:18:05.860 --> 00:18:07.620 because the Taproot is already active there. 00:18:09.370 --> 00:18:14.050 As well as some slightly more complicated scenarios. But then the last time I 00:18:14.050 --> 00:18:17.570 checked it, it would not give you the correct fee if it was a more complicated 00:18:17.570 --> 00:18:19.710 scenario. So there's a lot of work to be done. 00:18:19.970 --> 00:18:25.690 Right. To be very clear, we're talking about Bitcoin Core 22 now. Anyone 00:18:25.690 --> 00:18:30.610 else, any wallet, anyone clever enough to work with this stuff can, of course, 00:18:30.850 --> 00:18:35.050 starting in November, do all of this fancy Taproot stuff. It's just Bitcoin Core 00:18:35.050 --> 00:18:39.150 is sort of taking it slow. They're starting with regular Taproot transactions. 00:18:39.490 --> 00:18:42.790 And then down the line, presumably more options will be added. 00:18:43.190 --> 00:18:46.210 Exactly. So this is the Bitcoin Core. The wallet's part of Bitcoin Core, right? 00:18:46.270 --> 00:18:50.150 So the Bitcoin Core node will verify all those complicated conditions. So you can 00:18:50.150 --> 00:18:52.990 use them. It's just that you'll have to write your own wallet to do it. 00:18:54.660 --> 00:18:59.160 But it's nice to have Bitcoin Core also have an example wallet, if only so people 00:18:59.160 --> 00:19:02.140 can sanity check that it really works as they think it does. 00:19:03.440 --> 00:19:08.420 So if you're really impatient and you want to roll your own wallet, I mean, first 00:19:08.420 --> 00:19:13.660 of all, only do that on testnet and on Signet. But you can look at the... 00:19:13.990 --> 00:19:18.930 The Chaincode workshop that they did two years ago, they did a Taproot workshop. 00:19:19.210 --> 00:19:24.510 And part of that workshop was Python notebooks. In those Python notebooks, you 00:19:24.510 --> 00:19:28.330 would construct Taproot transactions completely from scratch, like starting with 00:19:28.330 --> 00:19:34.170 two public keys and adding them up and creating all these. Very cool. And there 00:19:34.170 --> 00:19:36.970 might be some tweaks that need to be made because I don't know if they updated 00:19:36.970 --> 00:19:41.310 the workshop with all the latest changes to the specification. But you can use 00:19:41.310 --> 00:19:44.870 that to roll your own wallet. Like I said, like a test wallet. 00:19:46.390 --> 00:19:50.490 That's the only one I'm aware of. What I'm hoping to see is hardware wallets 00:19:50.490 --> 00:19:51.350 implement this stuff. 00:19:51.610 --> 00:19:56.030 Yeah, I'm personally not aware of a lot of Taproot software that's actually in 00:19:56.030 --> 00:20:00.150 development. And that probably makes sense, right? Software developers in general 00:20:00.150 --> 00:20:05.310 presumably want to wait before spending a lot of time working on Taproot stuff 00:20:05.310 --> 00:20:07.530 until Taproot is actually locked in. 00:20:07.710 --> 00:20:11.690 It depends on their business plan if they have any, right? Maybe they want to be 00:20:11.690 --> 00:20:15.400 the first to market. Then it makes sense to have everything ready, long before it 00:20:15.400 --> 00:20:16.610 activates, but not… 00:20:16.860 --> 00:20:21.820 No, but [unclear]. I mean, up until last week, there was a, you know, 00:20:22.060 --> 00:20:27.560 real risk that it would be a huge [unclear] of time if it hadn't locked in or 00:20:27.560 --> 00:20:31.960 activated at all. So it makes sense that developers will only start focusing on 00:20:31.960 --> 00:20:32.900 it now, don't you think? 00:20:33.340 --> 00:20:36.780 It does. It depends on what your plan is. Like, if you have a plan that you know 00:20:36.780 --> 00:20:41.040 you can execute in six months, then sure, wait for the lock-in. If you have a 00:20:41.040 --> 00:20:43.840 plan that takes two years, then maybe you were already working on this. 00:20:45.040 --> 00:20:45.780 Fair enough. 00:20:46.160 --> 00:20:46.940 That I don't know. 00:20:47.220 --> 00:20:49.200 Do you have any idea how much I'm sweating? 00:20:50.670 --> 00:20:55.010 No, but the nice thing is because of this pandemic, we have a nice social 00:20:55.010 --> 00:20:57.670 distancing. So it's not my problem. 00:20:58.730 --> 00:21:00.990 All right, move on, move on. We're moving on. 00:21:01.130 --> 00:21:06.850 Yeah, I just wanted to add that just to compare to the past. So when SegWit came 00:21:06.850 --> 00:21:11.310 alive, when it was activated after much drama, after much more time as well, 00:21:12.220 --> 00:21:17.040 I don't think there were any wallets or maybe one. But there was no Bitcoin Core 00:21:17.040 --> 00:21:21.360 support for it in the wallet. That took another year. And the reason for that was 00:21:21.360 --> 00:21:27.140 because the Bitcoin Core wallet was an absolute mess. And now it is not a 00:21:27.140 --> 00:21:30.460 mess. It is much more flexible, much more powerful, which is why adding Taproot 00:21:30.460 --> 00:21:34.520 to it is going a lot faster than last time. And we might even have some wallet 00:21:34.520 --> 00:21:36.540 support before it activates. So that's very cool. 00:21:38.430 --> 00:21:42.750 But we'll just have to see what the other people are doing. And maybe one more 00:21:42.750 --> 00:21:48.490 point that I have is outside of wallets, we know that the Lightning folks are 00:21:48.490 --> 00:21:53.490 really excited about Taproot because it allows them to do cool stuff. So I'm 00:21:53.490 --> 00:21:56.890 looking forward to see what they do, and it might make sense for them to try all 00:21:56.890 --> 00:22:01.460 that stuff on Signet, and just have it ready to maybe even already have it in 00:22:01.460 --> 00:22:04.180 shipped code and just say, like, this thing is… we're going to start using 00:22:04.180 --> 00:22:08.560 Taproot for new channels as soon as it activates. And it's already rolled out, so 00:22:08.560 --> 00:22:10.900 all your peers already have Taproot too. You don't have to wait. 00:22:11.840 --> 00:22:17.490 I think the main benefit is that Lightning closing… as long as it's 00:22:17.490 --> 00:22:21.190 cooperative, will in fact look like regular Bitcoin transactions. 00:22:21.450 --> 00:22:25.230 That's one advantage. The other is that if you're doing a transaction, you have a 00:22:25.230 --> 00:22:30.030 payment hash right now. And that payment hash is sort of a fingerprint that is 00:22:30.030 --> 00:22:33.850 being given to all the intermediate nodes. And with Taproot, you can use points, 00:22:34.110 --> 00:22:38.710 a different point for each node in the process. So you're going to have much 00:22:38.710 --> 00:22:39.170 better privacy. 00:22:39.350 --> 00:22:40.390 And this is thanks to Schnorr signatures? 00:22:40.690 --> 00:22:41.790 This is thanks to Schnorr, yes. 00:22:41.790 --> 00:22:43.790 Yeah, which is part of the Taproot upgrade, yeah. 00:22:44.270 --> 00:22:48.410 Yeah. And I have no idea how easy that is to implement. Maybe somebody already 00:22:48.410 --> 00:22:53.650 did. Maybe they're going to try and find out that it's quite hard. I'm not up to 00:22:53.650 --> 00:22:58.290 date. We should talk to somebody who is more up to date on Lightning. 00:22:58.890 --> 00:23:04.250 That's an excellent idea, Sjors. Also a little bit of a spoiler. Or no, a teaser… 00:23:04.390 --> 00:23:08.060 A teaser. That's much better. Stay tuned, folks. 00:23:09.370 --> 00:23:13.270 Sjors, last question. I think this is the last question for me. What did we… 00:23:13.590 --> 00:23:17.670 Okay, so we've spoken about... Well, we haven't spoken about Taproot a lot. That 00:23:17.670 --> 00:23:21.290 was a previous episode. We've spoken about what people can expect, what lock-in 00:23:21.290 --> 00:23:27.290 exactly means. What have we learned about soft fork upgrades? Have we 00:23:27.290 --> 00:23:29.750 learned anything now that this one was successful? 00:23:29.970 --> 00:23:35.970 I'm hoping that we have reduced our PTSD when it comes to 00:23:35.970 --> 00:23:40.820 soft forks. Because we had pretty, like, it only took three… difficulty 00:23:40.820 --> 00:23:46.680 adjustment periods to get the lock-in. It was at like 99%, so we didn't even need 00:23:46.680 --> 00:23:50.920 to lower the threshold to 95%. Could have done it at 100%. Well, could not have 00:23:50.920 --> 00:23:52.900 done it at 100%, but we could have done it at 99%. 00:23:52.900 --> 00:23:54.300 98% or something, yeah. 00:23:54.680 --> 00:24:00.160 So I'm pretty sure we could have just gotten 100% if we were really stubborn 00:24:00.160 --> 00:24:04.360 about it and miners were willing to re-org each other. But I mean, that's good 00:24:04.360 --> 00:24:09.200 news. Maybe it's even scary, because if it's so easy to convince miners. 00:24:11.200 --> 00:24:15.280 But we know that people have worked really hard on trying to get this done. So 00:24:15.280 --> 00:24:21.420 I'm happy to see that. Hopefully for the next soft forks that we have in mind, 00:24:22.910 --> 00:24:27.010 things can be, you know, scenarios can be discussed without too much drama. You 00:24:27.010 --> 00:24:29.770 can still think about all sorts of scenarios, but there will be maybe a little 00:24:29.770 --> 00:24:32.530 bit less emotion because we know it doesn't have to be bad. 00:24:32.950 --> 00:24:38.330 Yeah, well, there are definitely still some lingering disagreements on what to do 00:24:38.330 --> 00:24:42.730 if miners would not cooperate as easily. Of course, yeah, 00:24:44.370 --> 00:24:48.190 Mandatory signaling or not is sort of the main one I think where there's still 00:24:48.190 --> 00:24:52.090 some difference of perspectives on whether or not that's that's a good plan B, 00:24:52.090 --> 00:24:57.210 um… So we have not resolved that at all, but you know, since miners were going to 00:24:57.210 --> 00:25:00.790 cooperate, there was no way of resolving it now probably, so… 00:25:00.790 --> 00:25:05.910 No, and I think this is a good time, you know, the next year or so to think about 00:25:05.910 --> 00:25:09.210 these mechanisms in general without a specific soft fork in mind. 00:25:09.490 --> 00:25:13.170 It's probably good to continue this discussion and the discussion is sort of 00:25:13.170 --> 00:25:15.530 continuing in different venues and places. 00:25:16.350 --> 00:25:21.030 But also just the code because it's very annoying to see a pull request that 00:25:21.030 --> 00:25:25.700 implements a whole new way of doing things right when you need it. 00:25:26.020 --> 00:25:28.640 Right, so you're referring to BIP-8, for example. 00:25:28.960 --> 00:25:32.460 Yeah, it would have been nice to have that BIP-8 pull request if that had 00:25:32.460 --> 00:25:38.260 happened two years ago with some dummy soft fork just to show how it works. We 00:25:38.260 --> 00:25:43.020 could have probably spent more time on it. But I can also see why if it's not 00:25:43.020 --> 00:25:46.380 urgent, nobody's going to review it, nobody's going to write it. So it's always 00:25:46.380 --> 00:25:48.820