WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode. 00:00:19.280 --> 00:00:21.620 Live from Utrecht, this is Bitcoin. 00:00:22.100 --> 00:00:22.780 Explained. 00:00:23.990 --> 00:00:24.650 Hey, Sjors. 00:00:25.110 --> 00:00:25.550 What's up? 00:00:26.240 --> 00:00:30.400 Sjors Provoost, Bitcoin Core contributor and author. 00:00:31.020 --> 00:00:31.560 Oh, yes. 00:00:31.900 --> 00:00:32.480 Congratulations. 00:00:33.120 --> 00:00:33.460 Thank you. 00:00:33.880 --> 00:00:39.340 Your new book, Bitcoin, a Work in Progress, is now available on Amazon? 00:00:39.660 --> 00:00:45.420 On everywhere. If you go to btcwip.com, which is Work in 00:00:45.420 --> 00:00:49.750 Progress, there's links to… to various Amazons 00:00:49.750 --> 00:00:53.450 and other sites where you can hopefully buy the book. 00:00:53.610 --> 00:00:54.490 What is the book? 00:00:55.240 --> 00:00:59.560 It is basically based on this podcast. So if you like this podcast, you will like 00:00:59.560 --> 00:01:03.180 the book. So what I did is I took a couple of the episodes and had a transcript 00:01:03.180 --> 00:01:08.460 made. And then worked with an editor to turn the transcripts into, 00:01:08.480 --> 00:01:13.780 well, chapters with a lot of back and forth. So some of them will look similar to 00:01:13.780 --> 00:01:17.960 the episodes and others will look completely different than the episode. So even 00:01:17.960 --> 00:01:21.140 if you've listened to every episode, I think you'll learn something new from the book. 00:01:22.220 --> 00:01:25.440 Great. And you'll also learn something new in this episode. 00:01:25.620 --> 00:01:26.160 That's right. 00:01:26.200 --> 00:01:31.850 We are going to discuss URSFs, which stands 00:01:31.850 --> 00:01:37.770 for user-resisted soft fork or user-rejected 00:01:37.770 --> 00:01:42.450 soft fork. I think it's sort of settling on user-resisted soft fork, but 00:01:42.450 --> 00:01:47.040 the acronym is the same anyways. So URSF. 00:01:48.450 --> 00:01:54.150 Well, rejection is an outcome and resistance is an attempt, right? Well, I guess 00:01:54.150 --> 00:01:56.390 you can succeed at either. 00:01:56.990 --> 00:01:58.950 So wait, which one do you prefer then? 00:01:59.600 --> 00:02:03.320 Well, I would say rejected because then you say we actually rejected it. 00:02:03.680 --> 00:02:08.280 Yeah, I think that's a bit more accurate as well. All right. So before, let's 00:02:08.280 --> 00:02:13.960 just start with what a URSF is exactly, like what it technically 00:02:13.960 --> 00:02:14.380 is. 00:02:14.820 --> 00:02:15.120 Yeah. 00:02:15.660 --> 00:02:17.860 Do you want me to explain or do you want to? 00:02:18.140 --> 00:02:18.940 No, you go ahead. 00:02:19.200 --> 00:02:24.840 All right. So basically there's different ways of implementing it exactly. But as 00:02:24.840 --> 00:02:30.340 the name suggests, it is a way to reject or [unclear]. I'm going to go with 00:02:30.340 --> 00:02:35.760 reject, I think. It's a way to reject a soft fork. And the way this can be done 00:02:35.760 --> 00:02:40.270 technically and that, you know, again, there's… multiple ways to do it but the 00:02:40.270 --> 00:02:46.050 way that makes most sense if you ask me in the way it hasn't been implemented at 00:02:46.050 --> 00:02:50.290 all yet there's no client that does this it's more of a concept. Uh yeah so a 00:02:50.290 --> 00:02:54.910 little bit of background. The first time I heard about it was uh Jorge Timón one 00:02:54.910 --> 00:02:59.850 of the former Bitcoin Core contributors, he he came up with this concept, or 00:02:59.850 --> 00:03:04.290 that's he that's the first time I heard about it, and this was during the Taproot 00:03:04.670 --> 00:03:10.130 discussion. Okay now it wasn't implemented back then, but now we sort of have a 00:03:10.130 --> 00:03:13.510 new discussion going on about CTV 00:03:14.800 --> 00:03:20.480 check template verify and in that context there has now actually been some code 00:03:20.480 --> 00:03:26.100 produced by Jeremy Rubin who's also uh the main proponent proponent of CTV. 00:03:26.100 --> 00:03:31.040 So now the concept is getting a bit more real, and it's probably a good time to 00:03:31.040 --> 00:03:35.560 start talking about this. All right so what it does essentially, so a soft fork 00:03:35.560 --> 00:03:41.070 can be activated— has been activated so far through blockchain signaling. We've 00:03:41.070 --> 00:03:46.030 talked about this in previous episodes so for example Taproot used speedy trial 00:03:46.030 --> 00:03:51.670 which required the 90 percent of all blocks within one difficulty 00:03:51.670 --> 00:03:57.130 period had to um had a activation signal in it, 00:03:57.130 --> 00:04:02.900 which is something that miners put in the block. All right. So once 90% of all 00:04:02.900 --> 00:04:06.540 blocks have this, then it indicates that the soft fork is going to be active. 00:04:07.040 --> 00:04:12.180 What a URSF does is it will actually 00:04:12.180 --> 00:04:14.860 reject the last block. 00:04:16.880 --> 00:04:22.640 Let's stick to the simple example. It will reject the last signaling block before 00:04:22.640 --> 00:04:28.030 activation. So I think the difficulty period has 00:04:28.030 --> 00:04:32.730 2016 blocks. 90% of that is 00:04:32.730 --> 00:04:38.110 1815 blocks. So a URSF client 00:04:38.110 --> 00:04:43.990 will accept up to 1814 blocks that signal, but the 00:04:43.990 --> 00:04:49.650 1815 block will be rejected. So at that point, it will basically 00:04:49.650 --> 00:04:55.540 create a blockchain split. And on the side of the split that the 00:04:55.540 --> 00:05:00.460 URSF is accepting, there will not be a soft fork. 00:05:01.420 --> 00:05:07.020 Yeah, so I guess the specific details can probably be varied, but the idea is 00:05:07.020 --> 00:05:11.580 that when you're signaling for a soft fork, at least the way it's done in BIP9 00:05:11.580 --> 00:05:17.560 and in other proposals, you are expecting a signal. And in the 00:05:17.560 --> 00:05:22.300 case of this, you would actually require there to be not a signal. And so I guess 00:05:22.300 --> 00:05:26.200 that the easiest thing to compare this to is the UASF, the User Activated 00:05:26.200 --> 00:05:32.100 soft fork. Because a user activated soft fork is where your node requires there 00:05:32.100 --> 00:05:37.280 to be a signal at a certain date. So then I guess there's three mechanisms that 00:05:37.280 --> 00:05:38.540 we can sort of look at. 00:05:38.800 --> 00:05:43.760 Yeah, it's like a mirror of a UASF. I think that's an accurate way to put it. If 00:05:43.760 --> 00:05:49.700 the UASF requires that a soft fork will be activated, the URSF will 00:05:49.700 --> 00:05:51.560 reject it if that happens. 00:05:51.800 --> 00:05:55.880 Yeah, and the key part here is that you're not actually rejecting the soft fork, 00:05:56.060 --> 00:05:59.770 you're rejecting the activation flagging of the soft fork I mean the specific 00:05:59.770 --> 00:06:03.530 thing that your node is looking for is not the soft fork rules itself but is is 00:06:03.530 --> 00:06:06.630 the activation rules and so one way to look at it… 00:06:06.630 --> 00:06:11.330 Again like there's probably different implementation details but this does seem 00:06:11.330 --> 00:06:15.090 or is in my opinion at least the most straightforward way of doing it. Yeah. 00:06:15.090 --> 00:06:15.750 Yeah. 00:06:15.750 --> 00:06:21.550 Okay so that's now that we've covered what it technically is hopefully 00:06:21.550 --> 00:06:26.760 our listeners will now understand what the concept is. And now we'll try to 00:06:26.760 --> 00:06:32.540 explain why this does or does not make sense to actually have 00:06:32.540 --> 00:06:38.060 around. Right? Okay. So let me see. I'll take the lead on this one and then you 00:06:38.060 --> 00:06:42.680 can comment. That's kind of the opposite of how we usually do it, I think. But 00:06:42.680 --> 00:06:43.840 let's see how it goes. 00:06:44.080 --> 00:06:44.540 Yes. 00:06:44.760 --> 00:06:46.060 All right. So. 00:06:47.660 --> 00:06:52.880 Oh, I want to emphasize something first. I'm going to use the word UASF a lot in 00:06:52.880 --> 00:06:58.400 this episode. And so will you probably. But when I use it, I guess you can make 00:06:58.400 --> 00:07:04.200 up your own mind. When I use it throughout this episode, I just mean a 00:07:04.200 --> 00:07:10.020 client that will enforce the soft fork rules for sure. So I don't necessarily 00:07:10.020 --> 00:07:14.620 mean an alt client because that's sort of another debate. Like do soft forks need 00:07:14.620 --> 00:07:19.790 to be activated through Bitcoin Core? Or through an alt client I don't that's not 00:07:19.790 --> 00:07:20.470 what I'm talking about 00:07:20.470 --> 00:07:23.610 So yeah I think I understand what you mean um… 00:07:23.610 --> 00:07:29.410 So let me finish real quick. A UASF in my definition can be implemented 00:07:29.410 --> 00:07:30.170 in Bitcoin Core. 00:07:30.770 --> 00:07:34.690 Yeah, I think there's nothing inherent about a UASF that can't be implemented in 00:07:34.690 --> 00:07:39.930 Bitcoin Core. It's just that the last two times that somebody proposed a UASF, it 00:07:39.930 --> 00:07:44.130 wasn't in Bitcoin Core. But the general idea of a UASF, at least these 00:07:44.130 --> 00:07:49.690 implementations so far, were that they required signaling. So where Bitcoin Core 00:07:49.690 --> 00:07:54.490 would use BIP9, which allows signaling, and if the signaling happens, then the 00:07:54.490 --> 00:08:00.410 soft fork happens, a UASF, whoever releases it requires the signaling to take 00:08:00.410 --> 00:08:04.750 place, which has the advantage of that then other nodes on the network that may 00:08:04.750 --> 00:08:08.370 not, you know, look at the UASF, they will see the signaling and know that the 00:08:08.370 --> 00:08:09.250 soft fork is going to activate. 00:08:10.730 --> 00:08:16.510 No, no, I disagree. Or I think you're wrong. Like there are different, you can 00:08:16.510 --> 00:08:22.240 also do an UASF without signaling. But but I'll get to that in a minute. Okay 00:08:22.240 --> 00:08:25.700 for now I just wanted to emphasize because there is another debate. There is the 00:08:25.700 --> 00:08:31.680 debate that some people think that any soft fork should be released outside 00:08:31.680 --> 00:08:36.890 of Bitcoin Core, because otherwise Core developers have too much control or the 00:08:36.890 --> 00:08:40.690 perception of control. But that's not the argument I'm talking about at all. So I 00:08:40.690 --> 00:08:45.230 just wanted to emphasize that before I start to actually lay out sort of the 00:08:45.230 --> 00:08:46.070 soft fork strategy. 00:08:46.310 --> 00:08:50.710 Okay. I just think that the scenario with signaling is the easiest to explain, 00:08:51.070 --> 00:08:56.390 right? You have with BIP9, there's optional signaling with UASF, [unclear] 00:08:56.370 --> 00:08:58.510 This is the next step. I'll get to this right now. 00:08:58.670 --> 00:08:58.890 Okay. 00:08:59.010 --> 00:09:00.070 And then you can comment on it. 00:09:00.250 --> 00:09:00.470 Okay. 00:09:01.450 --> 00:09:07.310 All right. So basically, ideally, we want 00:09:07.310 --> 00:09:13.100 miners to signal and to activate the soft fork that way. And that's how 00:09:13.100 --> 00:09:18.920 it has been done with previous soft forks, definitely before SegWit. That's how 00:09:18.920 --> 00:09:23.020 we did soft forks. And the reason for that is that if miners enforce the soft 00:09:23.020 --> 00:09:27.240 fork, then you are sure that the network stays in consensus because even 00:09:27.240 --> 00:09:33.170 non-upgraded nodes will follow the majority chain. Yeah okay the problem with 00:09:33.170 --> 00:09:37.350 this and we've talked about this in previous episodes I'm not gonna rehash all of 00:09:37.350 --> 00:09:43.590 it but in short the problem with this is that it allows miners to block the upgrade 00:09:43.590 --> 00:09:44.250 Yes. 00:09:44.250 --> 00:09:49.450 Miners can just refuse to signal and then the soft fork the upgrade doesn't 00:09:49.450 --> 00:09:55.340 happen okay now there's three ways to deal with that situation. Option one 00:09:55.340 --> 00:10:00.360 is to accept that miners have a veto. You just you know you just 00:10:01.660 --> 00:10:06.540 agree, that miners should be allowed to block a soft fork that's one option. 00:10:06.540 --> 00:10:11.330 That's an opinion you can have, and there are people that have this opinion. Okay 00:10:11.330 --> 00:10:16.490 that's optional. I don't like this option, but you know I think inherently the 00:10:16.490 --> 00:10:20.950 rules of Bitcoin are defined by the users when they accept money. It's you know I 00:10:20.950 --> 00:10:21.690 will define 00:10:23.170 --> 00:10:28.990 which rules I want my money to adhere to and the miners are more like commodity 00:10:28.990 --> 00:10:32.290 producers, and if they don't produce the blocks that I want then I'm just not 00:10:32.290 --> 00:10:37.270 gonna value the whatever coins they mine. I think users are fundamentally in 00:10:37.270 --> 00:10:41.470 control of the system, but you can be of the opinion you can have a different 00:10:41.470 --> 00:10:42.470 different opinion. You can 00:10:42.470 --> 00:10:47.550 Well you can have a more zen interpretation. Instead of saying miners should be 00:10:47.550 --> 00:10:51.980 able to block a soft fork you could also say well, It's true that miners can 00:10:51.980 --> 00:10:54.900 block a soft fork, even if you don't think that's a good thing. 00:10:56.910 --> 00:11:00.130 I mean, well, okay, let's... 00:11:00.130 --> 00:11:01.790 But anyway, option two. 00:11:01.950 --> 00:11:07.870 Right. So... Option two and this has not been done yet, but I think 00:11:07.870 --> 00:11:12.890 it makes more sense to explain it in this order. Option two I think it was 00:11:12.890 --> 00:11:18.690 defined in BIP 149. It has been discussed in context of 00:11:18.690 --> 00:11:22.910 [unclear] years ago and then you're during a Taproot discussion as well. 00:11:22.910 --> 00:11:28.280 BIP 149 I guess I'm just gonna call it that, is 00:11:28.280 --> 00:11:34.240 or it's a flag day activation so in the case of BIP 00:11:34.240 --> 00:11:40.220 149 or flag day activation you don't actually use miner signaling you just 00:11:40.220 --> 00:11:46.000 say you just embed in the client, you say on this block height 00:11:46.000 --> 00:11:50.590 or this date and time in the future, I prefer block heights, but whatever doesn't 00:11:50.590 --> 00:11:55.350 really matter for the purpose of the argument. Your node is just going to enforce 00:11:55.350 --> 00:12:00.650 new soft fork rules. So if a block is mined that breaks these rules, your node 00:12:00.650 --> 00:12:03.990 will just reject it. There's no signaling involved in this case. 00:12:04.130 --> 00:12:06.530 And this is in fact how soft forks worked in the very beginning. 00:12:08.230 --> 00:12:12.630 When Satoshi was making soft forks, he would just put in an activation height and 00:12:12.630 --> 00:12:14.590 it would just happen after a certain height. 00:12:14.950 --> 00:12:18.130 I guess you're right, actually. Yeah, this is how the very first soft forks 00:12:18.130 --> 00:12:20.930 happened. Yeah, you're right. There was no signaling back then. 00:12:21.070 --> 00:12:24.550 Well, the very first intentional soft forks, maybe there were accidentals that 00:12:24.550 --> 00:12:27.270 didn't even have a height in it, but yeah. 00:12:27.630 --> 00:12:28.610 Right, right, yeah. 00:12:29.700 --> 00:12:30.100 Okay. 00:12:30.340 --> 00:12:34.700 Yeah, so if they even had a height that you bring it up, were there ever flagged 00:12:34.700 --> 00:12:38.000 activations actually, or was there just a new code release? 00:12:38.420 --> 00:12:43.280 So the block size decrease, for example, had an activation height in it. 00:12:43.460 --> 00:12:43.820 Oh, it did? 00:12:43.980 --> 00:12:44.200 Yeah. 00:12:44.400 --> 00:12:44.620 Okay. 00:12:45.100 --> 00:12:46.780 But there may have been other changes that didn't. 00:12:47.630 --> 00:12:53.510 All right so so this is an option. Uh I've again there are people that would 00:12:53.510 --> 00:12:58.390 prefer this so if miners don't cooperate you just implement a flag day. I have a 00:12:58.390 --> 00:13:03.700 problem with this because, um at that point the 00:13:05.500 --> 00:13:06.100 blockchain… 00:13:07.710 --> 00:13:09.590 Maybe we should just say what option three is. 00:13:09.590 --> 00:13:10.190 No, no. 00:13:10.190 --> 00:13:11.090 Okay, okay. 00:13:11.090 --> 00:13:15.850 There could be a split in the blockchain at some point, because some users have 00:13:15.850 --> 00:13:17.730 upgraded and some have not. 00:13:17.730 --> 00:13:22.290 Yeah right and in fact this has happened in the past right, where miners would 00:13:22.290 --> 00:13:27.430 not well miners would not be running the same update and then you you get a split 00:13:27.430 --> 00:13:30.730 and then it's up to the nodes but not everybody upgrades their node, 00:13:30.730 --> 00:13:36.510 Right and to add to that it's sort of— this split can happen at any 00:13:36.510 --> 00:13:41.330 time. Like this at any time a miner could break the rules and then some nodes are 00:13:41.330 --> 00:13:46.590 going to enforce and some of them are not, and you can't know in advance when 00:13:46.590 --> 00:13:50.570 it's going to happen. It might happen on Christmas Eve and no one is around to 00:13:50.570 --> 00:13:54.270 coordinate some sort of solution, and now you have an even bigger problem. Like 00:13:54.270 --> 00:13:59.830 it's yeah unpredictable, which I don't like. Now there's a another more subtle 00:13:59.830 --> 00:14:04.440 thing I don't like about it which is… soft forks 00:14:04.440 --> 00:14:10.240 the nodes that are running stricter rules, they sort of have this 00:14:10.240 --> 00:14:15.660 asymmetric advantage right? Because whoever is enforcing the soft fork 00:14:15.660 --> 00:14:21.320 worst case scenario they'll— worst case scenario they end up on a minority chain, 00:14:21.320 --> 00:14:26.930 while uh if you're not adhering to the strict rules the looser 00:14:26.930 --> 00:14:32.630 rules, they can that that chain can be reorgs away right? So you've 00:14:32.630 --> 00:14:37.490 accepted money, uh and now all of a sudden the soft fork chain is getting longer 00:14:37.490 --> 00:14:41.170 and now the money you accepted just disappears because your chain disappeared. 00:14:41.170 --> 00:14:45.650 Yeah, right. So the only way to sort of be really sure that this doesn't happen 00:14:45.650 --> 00:14:51.560 to you is you need to be on the soft fork side right. So in this 00:14:51.560 --> 00:14:57.360 case where with the flag day activation you kind of really just need to 00:14:57.360 --> 00:14:59.780 follow along. And I think that 00:15:01.270 --> 00:15:07.170 gives a sort of subtle or maybe not so subtle implicit power 00:15:07.170 --> 00:15:12.250 to developers, because if developers and specifically Bitcoin Core developers you 00:15:12.250 --> 00:15:16.490 know in this in this case if Bitcoin Core is the de facto reference 00:15:16.490 --> 00:15:20.930 implementation then you better just do what they released because otherwise 00:15:20.930 --> 00:15:25.990 you're running this reorg risk. So there's sort of a you know I think there's 00:15:25.990 --> 00:15:27.930 sort of a hidden power that could… 00:15:28.780 --> 00:15:34.440 Yeah, or in the case of a UASF that is, well, let's not use that term, but in 00:15:34.440 --> 00:15:38.660 case of this mechanism being used not even by Bitcoin Core, but by any group of 00:15:38.660 --> 00:15:44.160 people, then maybe you would say, well, it's better to do whatever that group of 00:15:44.160 --> 00:15:46.280 people says because otherwise I might get re-orged. 00:15:46.720 --> 00:15:47.720 Right, exactly. 00:15:47.880 --> 00:15:50.500 That gets back to the long debates about UASFs in general. 00:15:50.940 --> 00:15:55.920 But that's exactly where the [unclear] comes in in a minute. We're getting there. 00:15:56.260 --> 00:16:01.980 Okay, so option one was, you just accept the unpleasant fact that 00:16:01.980 --> 00:16:07.940 miners could not signal. Option two is you just start 00:16:07.940 --> 00:16:11.480 enforcing the new rules without any signaling. 00:16:11.820 --> 00:16:11.980 Right. 00:16:12.300 --> 00:16:12.940 Option three. 00:16:13.260 --> 00:16:19.020 And in option three, that's essentially what BIP 148 was in the 00:16:19.020 --> 00:16:22.320 SegWit context, which is mandatory signaling. 00:16:22.840 --> 00:16:22.960 Yeah. 00:16:23.200 --> 00:16:28.800 So that's the UASF that we've seen and that we remember and that we've done 00:16:28.800 --> 00:16:33.980 podcasts on. It's when your node mandates signaling at some point. 00:16:34.000 --> 00:16:38.880 And the advantage over that over option two is that now you know exactly when the 00:16:38.880 --> 00:16:43.980 conflict is going to happen because you know what block should signal and not. So 00:16:43.980 --> 00:16:47.900 you're not waiting until the rules are actually violated. You're already having 00:16:47.900 --> 00:16:52.640 the fight in the signaling phase. And a secondary benefit is that because the 00:16:52.640 --> 00:16:56.860 signaling is mandatory, if the signaling therefore happens, then everybody 00:16:56.860 --> 00:17:00.520 understands what's going on, whether or not they're running the mandatory 00:17:00.520 --> 00:17:01.400 signaling client. 00:17:01.900 --> 00:17:06.000 All right. So if I understand your arguments or what you just said correctly, the 00:17:06.000 --> 00:17:11.120 first thing you said is, so if there is a split between 00:17:11.120 --> 00:17:16.280 nodes that are enforcing different things, then in the case of mandatory 00:17:16.280 --> 00:17:21.640 signaling, at least it happens at a predictable time as opposed to some unknown 00:17:21.640 --> 00:17:22.680 time in the future. 00:17:22.980 --> 00:17:26.460 Right. First, there's the discussion about whether the new rules shall apply and 00:17:26.460 --> 00:17:29.680 that discussion is settled. And yeah. 00:17:30.090 --> 00:17:34.550 Yeah, so there's always a chain split risk or at least in both of these cases. 00:17:34.770 --> 00:17:39.930 And it's arguably better to have it at a predictable time. I tend to agree with that. 00:17:40.070 --> 00:17:43.690 And also to have the split over something as simple as signaling rather than the 00:17:43.690 --> 00:17:45.290 actual rules, right? 00:17:45.710 --> 00:17:47.010 Why is that a benefit, do you think? 00:17:47.030 --> 00:17:51.490 Well, right now, I mean, I think there was somebody before Taproot activated who 00:17:51.490 --> 00:17:57.140 created a transaction that was invalid under the Taproot rules. And then you have 00:17:57.140 --> 00:18:02.880 discussions about whether or not that's a problem. We talked about that in the 00:18:02.880 --> 00:18:08.700 context of burying the soft forks. So if you want to say, 00:18:08.780 --> 00:18:12.280 I don't like these new rules, then you would make a transaction that's invalid 00:18:12.280 --> 00:18:16.280 under the rules, but it's kind of difficult to do that. So a signal is much 00:18:16.280 --> 00:18:17.500 easier to understand. 00:18:18.010 --> 00:18:21.870 Yeah, and then the other thing you said is if there are other nodes on the 00:18:21.870 --> 00:18:25.390 network that are just looking at the signaling but won't mandate it, then they 00:18:25.390 --> 00:18:30.690 can also be activated through this UASF. Some people would consider it a 00:18:30.690 --> 00:18:34.830 detriment. I don't really understand why personally, but I've seen that argument. 00:18:35.070 --> 00:18:39.810 Well, in any case, that's relevant in the case where a small minority or anyway, 00:18:39.950 --> 00:18:44.550 a minority releases such a UASF client. In the case where Bitcoin Core releases a 00:18:44.550 --> 00:18:48.930 UASF client, I would guess there is no other group. It's just everybody would be 00:18:48.930 --> 00:18:52.370 running that. There wouldn't be somebody running a regular BIP9 optional 00:18:52.370 --> 00:18:53.690 signaling client. 00:18:53.930 --> 00:18:54.250 Right, exactly. 00:18:59.800 --> 00:19:05.740 Insofar that I understand this concern at all, I think, and this actually gets to 00:19:05.740 --> 00:19:11.620 our next point, is sort of the problem of UASFs or [unclear] 00:19:11.620 --> 00:19:15.860 mandatory signaling type of UASFs. And that is that, 00:19:17.000 --> 00:19:22.140 again, it's sort of… there's this asymmetric 00:19:22.140 --> 00:19:27.820 advantage over enforcing it. And therefore, a small group of users 00:19:27.820 --> 00:19:33.810 may sort of impose their will on 00:19:33.810 --> 00:19:34.770 the majority. 00:19:35.290 --> 00:19:35.710 Yeah, exactly. 00:19:36.090 --> 00:19:42.010 Okay. This is where the URSF comes in. So if the 00:19:42.010 --> 00:19:47.570 problem is that a small minority can start enforcing the rules, they 00:19:47.570 --> 00:19:53.130 essentially incentivize miners to just go along with them because that way they 00:19:53.130 --> 00:19:58.930 won't split the chain and they presumably maximize profits. 00:19:59.570 --> 00:20:03.390 But you know that not everyone likes a small minority kind of controlling things 00:20:03.390 --> 00:20:09.070 idea. So a URSF as the mirror of a UASF gives other users 00:20:09.070 --> 00:20:14.630 a way out. So if they really don't like the rules that are being 00:20:14.630 --> 00:20:20.170 proposed in this UASF, and that will be mandated in this UASF, then the 00:20:20.170 --> 00:20:26.300 URSF gives everyone who wants out an option out. 00:20:26.600 --> 00:20:27.180 Yes. 00:20:27.420 --> 00:20:33.230 Now, the problem, of course, is that this would split the chain. But I guess the 00:20:33.230 --> 00:20:39.110 way I see it is that if there's one group of people, an intolerant minority, that 00:20:39.110 --> 00:20:43.400 definitely wants something. And there's another group of people that definitely 00:20:43.400 --> 00:20:48.340 don't want that. Then the change should split. And I think that's what should 00:20:48.340 --> 00:20:50.880 happen. If people want different things, they want different things. 00:20:51.040 --> 00:20:56.620 And the nice thing about this situation where you have a UASF versus a 00:20:56.620 --> 00:21:02.400 URSF is that it's a clean split, right? It basically means that 00:21:02.400 --> 00:21:08.000 there's not going to be a reorg ever because the UASF side wants to see signals. 00:21:08.540 --> 00:21:13.280 And the URSF side does not want to see signals. So whatever happens in the 00:21:13.280 --> 00:21:16.180 future, whichever of these chains gets longer in the future, it doesn't matter 00:21:16.180 --> 00:21:20.060 because they will never accept each other because of that presence or absence of 00:21:20.060 --> 00:21:20.460 the signal. 00:21:20.840 --> 00:21:26.680 Yeah, well, there's one caveat there, right? So you are right. It is correct that 00:21:26.680 --> 00:21:32.370 the UASF clients will definitely follow the soft fork chain and the 00:21:32.370 --> 00:21:37.950 URSF clients will definitely follow the URSF chain. So the 00:21:37.950 --> 00:21:43.900 soft fork rejecting chain. So even if one chain is 00:21:43.900 --> 00:21:47.620 longer for a while, but then another chain overtakes it, it doesn't matter for 00:21:47.620 --> 00:21:48.120 these clients. 00:21:48.400 --> 00:21:48.960 Yes. 00:21:49.240 --> 00:21:55.070 However, it does matter for non-upgraded clients. 00:21:55.210 --> 00:21:55.470 Yep. 00:21:55.930 --> 00:22:01.490 Right? So let's say for example there 00:22:01.550 --> 00:22:06.980 is an alt client that does a UASF and then there's an alt client that does a 00:22:06.980 --> 00:22:12.560 URSF and Bitcoin Core does neither. And people keep running 00:22:12.560 --> 00:22:18.500 and using Bitcoin Core, then these people can actually suffer reorgs. 00:22:18.600 --> 00:22:23.180 Yeah, this sounds like a plausible scenario because if there is such a big battle 00:22:23.180 --> 00:22:26.760 between people who absolutely want a soft fork and people who absolutely don't 00:22:26.760 --> 00:22:32.060 want it, I would guess Bitcoin Core would do absolutely nothing and wait and see 00:22:32.060 --> 00:22:36.100 what happens. So in that case, indeed, the Bitcoin Core nodes would follow one 00:22:36.100 --> 00:22:41.910 side of the camp and then after a while... Because one camp beats the other it 00:22:41.910 --> 00:22:45.230 would follow the other side of the of the camp and and so those two battling 00:22:45.230 --> 00:22:48.810 camps would actually cause a lot of economic damage even outside of them 00:22:48.810 --> 00:22:50.490 Yeah potentially 00:22:50.490 --> 00:22:55.550 So I I think assuming the market doesn't fix this, and I guess that's where you come in. 00:22:56.310 --> 00:23:02.030 Yeah well I mean I think every— so given all the trade-offs so far 00:23:02.600 --> 00:23:08.600 I still think that UASF, I think UASFs are the way to do soft forks. 00:23:08.720 --> 00:23:13.180 I don't want miner vetoes. I think that's just the way soft forks should be done. 00:23:13.420 --> 00:23:19.320 But then I also think that a URSF should basically be a 00:23:19.480 --> 00:23:22.360 standard option that is also given. 00:23:22.860 --> 00:23:27.560 So basically you're saying if you get rid of the BIP9 system because miners have 00:23:27.560 --> 00:23:32.960 this veto power, then you would be okay with UASF as long as there's also the 00:23:32.960 --> 00:23:36.840 URSF. So you have to have both in order to have a balance. 00:23:37.200 --> 00:23:40.740 Right, yeah. Obviously, just my personal opinion that I'm giving on the podcast, 00:23:40.880 --> 00:23:44.840 this isn't some technical truth. But yeah, given all the options, I don't want 00:23:44.840 --> 00:23:50.630 miner vetoes. I don't like the… the flag day activation for the reasons I 00:23:50.630 --> 00:23:55.130 explained. And given all the trade-offs, my personal preference moving forward 00:23:55.130 --> 00:24:00.510 with these kinds of things is to do UASF, mandatory signaling, and then standard 00:24:00.510 --> 00:24:02.710 also give users a way out. 00:24:02.910 --> 00:24:08.630 Right. And this is where we probably don't really agree because I don't like the 00:24:08.630 --> 00:24:12.990 miner vetoes just as much as you don't like them, but I'm not willing to replace 00:24:12.990 --> 00:24:17.670 it with something that I think is unsafe. Which I think, well, the UASF, without 00:24:17.670 --> 00:24:21.830 anything else, I definitely think is unsafe, as I've explained in other episodes. 00:24:22.010 --> 00:24:26.610 And I think this combination is still unsafe, despite it having some cool features. 00:24:27.990 --> 00:24:32.810 So I'd rather deal with the current annoying situation than to, you know, open 00:24:32.810 --> 00:24:36.070 the other can of worms. But we can explore what that can of worms looks like. 00:24:36.750 --> 00:24:41.430 Well, I was just sort of prefacing this. I was saying, okay, this is given the 00:24:41.430 --> 00:24:46.550 trade-offs and... my knowledge of how the system works and the risk and my 00:24:46.550 --> 00:24:52.150 personal preference is that any soft fork should be a UASF in Core or maybe 00:24:52.150 --> 00:24:56.670 somewhere else that's not part of this podcast discussion. I think it should be 00:24:56.670 --> 00:25:01.070 UASF with mandatory signaling and standard users should also given being given 00:25:01.070 --> 00:25:05.870 the option to opt out through a URSF So that opinion sort of stands on itself. 00:25:05.870 --> 00:25:11.520 Now to mitigate the risk and this was what you're getting at, so to mitigate the 00:25:11.520 --> 00:25:17.400 reorg risk and that kind of stuff I think it would be much better if this sort of 00:25:17.400 --> 00:25:21.140 battle happens without any casualties. 00:25:21.140 --> 00:25:22.300 Yeah. 00:25:22.300 --> 00:25:27.940 And and I think that this can be accomplished fairly well through futures 00:25:27.940 --> 00:25:33.900 markets. So instead of actually splitting the chain and only then allowing 00:25:33.900 --> 00:25:38.620 trade between the coins and now all of a sudden one coin is more valuable and 00:25:38.620 --> 00:25:42.700 another while the market is sort of figuring this out live and it's been traded 00:25:42.700 --> 00:25:46.740 live and there are replay attacks and who knows what else, and then what the 00:25:46.740 --> 00:25:51.200 reorgs and You know, the Bitcoin Core user in the middle suffers. And so instead 00:25:51.200 --> 00:25:57.340 of doing that live, I think it can be done sort of virtually through futures markets. 00:25:58.260 --> 00:26:03.240 So basically you're selling, you have an exchange that sells two sides that 00:26:03.240 --> 00:26:08.760 basically says, here's, you know, you deposit a Bitcoin now and it'll 00:26:08.760 --> 00:26:13.580 tell you you'll get either, you'll get, I think you'll get both at first. You'll 00:26:13.580 --> 00:26:18.220 get both back after the split and then it's up to the market to decide which 00:26:18.220 --> 00:26:20.000 which half of that is worth more. 00:26:20.000 --> 00:26:20.380 Yeah. 00:26:20.380 --> 00:26:22.280 And this has been done by Bitfinex in the past. 00:26:22.280 --> 00:26:26.220 Exactly, so you get both back after split. You get coins on both sides of splits, 00:26:26.220 --> 00:26:28.720 but before the split you can trade between them. 00:26:28.720 --> 00:26:29.540 Yeah. 00:26:29.540 --> 00:26:35.320 So, and if you trade between them if I sell all my [unclear] coins for URSF 00:26:35.320 --> 00:26:40.300 coins then I get two [unclear] coins and zero [unclear] coins after split yeah 00:26:40.300 --> 00:26:46.170 right. So this way the market can figure out which option they think is 00:26:46.170 --> 00:26:50.710 more valuable which which version of Bitcoin the market really wants. Do they 00:26:50.710 --> 00:26:54.110 want the soft fork version, or do they want the version that rejected the 00:26:54.110 --> 00:26:58.930 soft fork? And by allowing the market to figure this out before there's actually 00:26:58.930 --> 00:27:04.250 chain split chaos miners can see all right users clearly want the soft fork 00:27:04.250 --> 00:27:08.290 so we're just going to mine the soft fork because we want to make as much money 00:27:08.290 --> 00:27:09.210 as possible. So that's what… 00:27:09.210 --> 00:27:13.500 So miners will have to pick a side based on the market estimate and you get some 00:27:13.500 --> 00:27:14.340 data from the market. 00:27:14.740 --> 00:27:20.360 Exactly. So I think if the futures markets work as I expect them to, then there 00:27:20.360 --> 00:27:24.560 won't actually be any re-arc chaos afterwards. If you're still worried about 00:27:24.560 --> 00:27:28.580 that, you can still use the client you want, but this is sort of a way to 00:27:28.580 --> 00:27:33.300 mitigate that extra risk that otherwise sort of neutral users that aren't aware 00:27:33.300 --> 00:27:37.300 of what's going on might suffer. So you use futures markets for that and then the 00:27:37.300 --> 00:27:38.420 miners can react to that. 00:27:38.560 --> 00:27:40.920 So as much as I think futures markets are super cool, 00:27:42.710 --> 00:27:47.450 I don't like the idea. And I guess I have roughly three reasons for that. But I 00:27:47.450 --> 00:27:48.970 don't know if you wanted to finish something. 00:27:49.070 --> 00:27:51.250 No, no, no, go ahead. I think that's sort of my case. 00:27:51.410 --> 00:27:56.090 So one is this adds a whole bunch of complexity compared to what we have now. And 00:27:56.090 --> 00:28:01.810 I don't want to say proof of stake complexity. But, you know, some complexity at 00:28:01.810 --> 00:28:05.530 least. Because now it depends on how much market power you have and what happens 00:28:05.530 --> 00:28:11.420 to the protocol. So the second is that personally I don't believe in... I 00:28:11.420 --> 00:28:15.740 don't believe in the strong efficient market theory. So the idea of an efficient 00:28:15.740 --> 00:28:19.300 market theory is that the markets, you know, the collective knowledge in the 00:28:19.300 --> 00:28:24.120 market will know, well, collectively will be able to make a good prediction of 00:28:24.120 --> 00:28:27.640 what's actually going to happen, taking everything into account. But my 00:28:27.640 --> 00:28:30.760 impression is that, you know, the market very often does not take things into 00:28:30.760 --> 00:28:35.140 account, especially black swan events. But I also think if they just don't 00:28:35.140 --> 00:28:37.700