URSFs (User Rejected Soft Forks) - Episode 57

Aaron van Wirdum Live from Utrecht, this is Bitcoin.

Sjors Provoost Explained.

Aaron van Wirdum Hey, Sjors.

Sjors Provoost What's up?

Aaron van Wirdum Sjors Provoost, Bitcoin Core contributor and author.

Sjors Provoost Oh, yes.

Aaron van Wirdum Congratulations.

Sjors Provoost Thank you.

Aaron van Wirdum Your new book, Bitcoin, a Work in Progress, is now available on Amazon?

Sjors Provoost On everywhere. If you go to btcwip.com, which is Work in Progress, there's links to… to various Amazons and other sites where you can hopefully buy the book.

Aaron van Wirdum What is the book?

Sjors Provoost It is basically based on this podcast. So if you like this podcast, you will like the book. So what I did is I took a couple of the episodes and had a transcript made. And then worked with an editor to turn the transcripts into, well, chapters with a lot of back and forth. So some of them will look similar to the episodes and others will look completely different than the episode. So even if you've listened to every episode, I think you'll learn something new from the book.

Aaron van Wirdum Great. And you'll also learn something new in this episode.

Sjors Provoost That's right.

Aaron van Wirdum We are going to discuss URSFs, which stands for user-resisted soft fork or user-rejected soft fork. I think it's sort of settling on user-resisted soft fork, but the acronym is the same anyways. So URSF.

Sjors Provoost Well, rejection is an outcome and resistance is an attempt, right? Well, I guess you can succeed at either.

Aaron van Wirdum So wait, which one do you prefer then?

Sjors Provoost Well, I would say rejected because then you say we actually rejected it.

Aaron van Wirdum Yeah, I think that's a bit more accurate as well. All right. So before, let's just start with what a URSF is exactly, like what it technically is.

Sjors Provoost Yeah.

Aaron van Wirdum Do you want me to explain or do you want to?

Sjors Provoost No, you go ahead.

Aaron van Wirdum All right. So basically there's different ways of implementing it exactly. But as the name suggests, it is a way to reject or [unclear]. I'm going to go with reject, I think. It's a way to reject a soft fork. And the way this can be done technically and that, you know, again, there's… multiple ways to do it but the way that makes most sense if you ask me in the way it hasn't been implemented at all yet there's no client that does this it's more of a concept. Uh yeah so a little bit of background. The first time I heard about it was uh Jorge Timón one of the former Bitcoin Core contributors, he he came up with this concept, or that's he that's the first time I heard about it, and this was during the Taproot discussion. Okay now it wasn't implemented back then, but now we sort of have a new discussion going on about CTV check template verify and in that context there has now actually been some code produced by Jeremy Rubin who's also uh the main proponent proponent of CTV. So now the concept is getting a bit more real, and it's probably a good time to start talking about this. All right so what it does essentially, so a soft fork can be activated— has been activated so far through blockchain signaling. We've talked about this in previous episodes so for example Taproot used speedy trial which required the 90 percent of all blocks within one difficulty period had to um had a activation signal in it, which is something that miners put in the block. All right. So once 90% of all blocks have this, then it indicates that the soft fork is going to be active. What a URSF does is it will actually reject the last block. Let's stick to the simple example. It will reject the last signaling block before activation. So I think the difficulty period has 2016 blocks. 90% of that is 1815 blocks. So a URSF client will accept up to 1814 blocks that signal, but the 1815 block will be rejected. So at that point, it will basically create a blockchain split. And on the side of the split that the URSF is accepting, there will not be a soft fork.

Sjors Provoost Yeah, so I guess the specific details can probably be varied, but the idea is that when you're signaling for a soft fork, at least the way it's done in BIP9 and in other proposals, you are expecting a signal. And in the case of this, you would actually require there to be not a signal. And so I guess that the easiest thing to compare this to is the UASF, the User Activated soft fork. Because a user activated soft fork is where your node requires there to be a signal at a certain date. So then I guess there's three mechanisms that we can sort of look at.

Aaron van Wirdum Yeah, it's like a mirror of a UASF. I think that's an accurate way to put it. If the UASF requires that a soft fork will be activated, the URSF will reject it if that happens.

Sjors Provoost Yeah, and the key part here is that you're not actually rejecting the soft fork, you're rejecting the activation flagging of the soft fork I mean the specific thing that your node is looking for is not the soft fork rules itself but is is the activation rules and so one way to look at it…

Aaron van Wirdum Again like there's probably different implementation details but this does seem or is in my opinion at least the most straightforward way of doing it. Yeah.

Sjors Provoost Yeah.

Aaron van Wirdum Okay so that's now that we've covered what it technically is hopefully our listeners will now understand what the concept is. And now we'll try to explain why this does or does not make sense to actually have around. Right? Okay. So let me see. I'll take the lead on this one and then you can comment. That's kind of the opposite of how we usually do it, I think. But let's see how it goes.

Sjors Provoost Yes.

Aaron van Wirdum All right. So. Oh, I want to emphasize something first. I'm going to use the word UASF a lot in this episode. And so will you probably. But when I use it, I guess you can make up your own mind. When I use it throughout this episode, I just mean a client that will enforce the soft fork rules for sure. So I don't necessarily mean an alt client because that's sort of another debate. Like do soft forks need to be activated through Bitcoin Core? Or through an alt client I don't that's not what I'm talking about

Sjors Provoost So yeah I think I understand what you mean um…

Aaron van Wirdum So let me finish real quick. A UASF in my definition can be implemented in Bitcoin Core.

Sjors Provoost Yeah, I think there's nothing inherent about a UASF that can't be implemented in Bitcoin Core. It's just that the last two times that somebody proposed a UASF, it wasn't in Bitcoin Core. But the general idea of a UASF, at least these implementations so far, were that they required signaling. So where Bitcoin Core would use BIP9, which allows signaling, and if the signaling happens, then the soft fork happens, a UASF, whoever releases it requires the signaling to take place, which has the advantage of that then other nodes on the network that may not, you know, look at the UASF, they will see the signaling and know that the soft fork is going to activate.

Aaron van Wirdum No, no, I disagree. Or I think you're wrong. Like there are different, you can also do an UASF without signaling. But but I'll get to that in a minute. Okay for now I just wanted to emphasize because there is another debate. There is the debate that some people think that any soft fork should be released outside of Bitcoin Core, because otherwise Core developers have too much control or the perception of control. But that's not the argument I'm talking about at all. So I just wanted to emphasize that before I start to actually lay out sort of the soft fork strategy.

Sjors Provoost Okay. I just think that the scenario with signaling is the easiest to explain, right? You have with BIP9, there's optional signaling with UASF, [unclear]

Aaron van Wirdum This is the next step. I'll get to this right now.

Sjors Provoost Okay.

Aaron van Wirdum And then you can comment on it.

Sjors Provoost Okay.

Aaron van Wirdum All right. So basically, ideally, we want miners to signal and to activate the soft fork that way. And that's how it has been done with previous soft forks, definitely before SegWit. That's how we did soft forks. And the reason for that is that if miners enforce the soft fork, then you are sure that the network stays in consensus because even non-upgraded nodes will follow the majority chain. Yeah okay the problem with this and we've talked about this in previous episodes I'm not gonna rehash all of it but in short the problem with this is that it allows miners to block the upgrade

Sjors Provoost Yes.

Aaron van Wirdum Miners can just refuse to signal and then the soft fork the upgrade doesn't happen okay now there's three ways to deal with that situation. Option one is to accept that miners have a veto. You just you know you just agree, that miners should be allowed to block a soft fork that's one option. That's an opinion you can have, and there are people that have this opinion. Okay that's optional. I don't like this option, but you know I think inherently the rules of Bitcoin are defined by the users when they accept money. It's you know I will define which rules I want my money to adhere to and the miners are more like commodity producers, and if they don't produce the blocks that I want then I'm just not gonna value the whatever coins they mine. I think users are fundamentally in control of the system, but you can be of the opinion you can have a different different opinion. You can

Sjors Provoost Well you can have a more zen interpretation. Instead of saying miners should be able to block a soft fork you could also say well, It's true that miners can block a soft fork, even if you don't think that's a good thing.

Aaron van Wirdum I mean, well, okay, let's...

Sjors Provoost But anyway, option two.

Aaron van Wirdum Right. So... Option two and this has not been done yet, but I think it makes more sense to explain it in this order. Option two I think it was defined in BIP 149. It has been discussed in context of [unclear] years ago and then you're during a Taproot discussion as well. BIP 149 I guess I'm just gonna call it that, is or it's a flag day activation so in the case of BIP 149 or flag day activation you don't actually use miner signaling you just say you just embed in the client, you say on this block height or this date and time in the future, I prefer block heights, but whatever doesn't really matter for the purpose of the argument. Your node is just going to enforce new soft fork rules. So if a block is mined that breaks these rules, your node will just reject it. There's no signaling involved in this case.

Sjors Provoost And this is in fact how soft forks worked in the very beginning. When Satoshi was making soft forks, he would just put in an activation height and it would just happen after a certain height.

Aaron van Wirdum I guess you're right, actually. Yeah, this is how the very first soft forks happened. Yeah, you're right. There was no signaling back then.

Sjors Provoost Well, the very first intentional soft forks, maybe there were accidentals that didn't even have a height in it, but yeah.

Aaron van Wirdum Right, right, yeah.

Sjors Provoost Okay.

Aaron van Wirdum Yeah, so if they even had a height that you bring it up, were there ever flagged activations actually, or was there just a new code release?

Sjors Provoost So the block size decrease, for example, had an activation height in it.

Aaron van Wirdum Oh, it did?

Sjors Provoost Yeah.

Aaron van Wirdum Okay.

Sjors Provoost But there may have been other changes that didn't.

Aaron van Wirdum All right so so this is an option. Uh I've again there are people that would prefer this so if miners don't cooperate you just implement a flag day. I have a problem with this because, um at that point the blockchain…

Sjors Provoost Maybe we should just say what option three is.

Aaron van Wirdum No, no.

Sjors Provoost Okay, okay.

Aaron van Wirdum There could be a split in the blockchain at some point, because some users have upgraded and some have not.

Sjors Provoost Yeah right and in fact this has happened in the past right, where miners would not well miners would not be running the same update and then you you get a split and then it's up to the nodes but not everybody upgrades their node,

Aaron van Wirdum Right and to add to that it's sort of— this split can happen at any time. Like this at any time a miner could break the rules and then some nodes are going to enforce and some of them are not, and you can't know in advance when it's going to happen. It might happen on Christmas Eve and no one is around to coordinate some sort of solution, and now you have an even bigger problem. Like it's yeah unpredictable, which I don't like. Now there's a another more subtle thing I don't like about it which is… soft forks the nodes that are running stricter rules, they sort of have this asymmetric advantage right? Because whoever is enforcing the soft fork worst case scenario they'll— worst case scenario they end up on a minority chain, while uh if you're not adhering to the strict rules the looser rules, they can that that chain can be reorgs away right? So you've accepted money, uh and now all of a sudden the soft fork chain is getting longer and now the money you accepted just disappears because your chain disappeared. Yeah, right. So the only way to sort of be really sure that this doesn't happen to you is you need to be on the soft fork side right. So in this case where with the flag day activation you kind of really just need to follow along. And I think that gives a sort of subtle or maybe not so subtle implicit power to developers, because if developers and specifically Bitcoin Core developers you know in this in this case if Bitcoin Core is the de facto reference implementation then you better just do what they released because otherwise you're running this reorg risk. So there's sort of a you know I think there's sort of a hidden power that could…

Sjors Provoost Yeah, or in the case of a UASF that is, well, let's not use that term, but in case of this mechanism being used not even by Bitcoin Core, but by any group of people, then maybe you would say, well, it's better to do whatever that group of people says because otherwise I might get re-orged.

Aaron van Wirdum Right, exactly.

Sjors Provoost That gets back to the long debates about UASFs in general.

Aaron van Wirdum But that's exactly where the [unclear] comes in in a minute. We're getting there.

Sjors Provoost Okay, so option one was, you just accept the unpleasant fact that miners could not signal. Option two is you just start enforcing the new rules without any signaling.

Aaron van Wirdum Right.

Sjors Provoost Option three.

Aaron van Wirdum And in option three, that's essentially what BIP 148 was in the SegWit context, which is mandatory signaling.

Sjors Provoost Yeah.

Aaron van Wirdum So that's the UASF that we've seen and that we remember and that we've done podcasts on. It's when your node mandates signaling at some point.

Sjors Provoost And the advantage over that over option two is that now you know exactly when the conflict is going to happen because you know what block should signal and not. So you're not waiting until the rules are actually violated. You're already having the fight in the signaling phase. And a secondary benefit is that because the signaling is mandatory, if the signaling therefore happens, then everybody understands what's going on, whether or not they're running the mandatory signaling client.

Aaron van Wirdum All right. So if I understand your arguments or what you just said correctly, the first thing you said is, so if there is a split between nodes that are enforcing different things, then in the case of mandatory signaling, at least it happens at a predictable time as opposed to some unknown time in the future.

Sjors Provoost Right. First, there's the discussion about whether the new rules shall apply and that discussion is settled. And yeah.

Aaron van Wirdum Yeah, so there's always a chain split risk or at least in both of these cases. And it's arguably better to have it at a predictable time. I tend to agree with that.

Sjors Provoost And also to have the split over something as simple as signaling rather than the actual rules, right?

Aaron van Wirdum Why is that a benefit, do you think?

Sjors Provoost Well, right now, I mean, I think there was somebody before Taproot activated who created a transaction that was invalid under the Taproot rules. And then you have discussions about whether or not that's a problem. We talked about that in the context of burying the soft forks. So if you want to say, I don't like these new rules, then you would make a transaction that's invalid under the rules, but it's kind of difficult to do that. So a signal is much easier to understand.

Aaron van Wirdum Yeah, and then the other thing you said is if there are other nodes on the network that are just looking at the signaling but won't mandate it, then they can also be activated through this UASF. Some people would consider it a detriment. I don't really understand why personally, but I've seen that argument.

Sjors Provoost Well, in any case, that's relevant in the case where a small minority or anyway, a minority releases such a UASF client. In the case where Bitcoin Core releases a UASF client, I would guess there is no other group. It's just everybody would be running that. There wouldn't be somebody running a regular BIP9 optional signaling client.

Aaron van Wirdum Right, exactly. Insofar that I understand this concern at all, I think, and this actually gets to our next point, is sort of the problem of UASFs or [unclear] mandatory signaling type of UASFs. And that is that, again, it's sort of… there's this asymmetric advantage over enforcing it. And therefore, a small group of users may sort of impose their will on the majority.

Sjors Provoost Yeah, exactly.

Aaron van Wirdum Okay. This is where the URSF comes in. So if the problem is that a small minority can start enforcing the rules, they essentially incentivize miners to just go along with them because that way they won't split the chain and they presumably maximize profits. But you know that not everyone likes a small minority kind of controlling things idea. So a URSF as the mirror of a UASF gives other users a way out. So if they really don't like the rules that are being proposed in this UASF, and that will be mandated in this UASF, then the URSF gives everyone who wants out an option out.

Sjors Provoost Yes.

Aaron van Wirdum Now, the problem, of course, is that this would split the chain. But I guess the way I see it is that if there's one group of people, an intolerant minority, that definitely wants something. And there's another group of people that definitely don't want that. Then the change should split. And I think that's what should happen. If people want different things, they want different things.

Sjors Provoost And the nice thing about this situation where you have a UASF versus a URSF is that it's a clean split, right? It basically means that there's not going to be a reorg ever because the UASF side wants to see signals. And the URSF side does not want to see signals. So whatever happens in the future, whichever of these chains gets longer in the future, it doesn't matter because they will never accept each other because of that presence or absence of the signal.

Aaron van Wirdum Yeah, well, there's one caveat there, right? So you are right. It is correct that the UASF clients will definitely follow the soft fork chain and the URSF clients will definitely follow the URSF chain. So the soft fork rejecting chain. So even if one chain is longer for a while, but then another chain overtakes it, it doesn't matter for these clients.

Sjors Provoost Yes.

Aaron van Wirdum However, it does matter for non-upgraded clients.

Sjors Provoost Yep.

Aaron van Wirdum Right? So let's say for example there is an alt client that does a UASF and then there's an alt client that does a URSF and Bitcoin Core does neither. And people keep running and using Bitcoin Core, then these people can actually suffer reorgs.

Sjors Provoost Yeah, this sounds like a plausible scenario because if there is such a big battle between people who absolutely want a soft fork and people who absolutely don't want it, I would guess Bitcoin Core would do absolutely nothing and wait and see what happens. So in that case, indeed, the Bitcoin Core nodes would follow one side of the camp and then after a while... Because one camp beats the other it would follow the other side of the of the camp and and so those two battling camps would actually cause a lot of economic damage even outside of them

Aaron van Wirdum Yeah potentially

Sjors Provoost So I I think assuming the market doesn't fix this, and I guess that's where you come in.

Aaron van Wirdum Yeah well I mean I think every— so given all the trade-offs so far I still think that UASF, I think UASFs are the way to do soft forks. I don't want miner vetoes. I think that's just the way soft forks should be done. But then I also think that a URSF should basically be a standard option that is also given.

Sjors Provoost So basically you're saying if you get rid of the BIP9 system because miners have this veto power, then you would be okay with UASF as long as there's also the URSF. So you have to have both in order to have a balance.

Aaron van Wirdum Right, yeah. Obviously, just my personal opinion that I'm giving on the podcast, this isn't some technical truth. But yeah, given all the options, I don't want miner vetoes. I don't like the… the flag day activation for the reasons I explained. And given all the trade-offs, my personal preference moving forward with these kinds of things is to do UASF, mandatory signaling, and then standard also give users a way out.

Sjors Provoost Right. And this is where we probably don't really agree because I don't like the miner vetoes just as much as you don't like them, but I'm not willing to replace it with something that I think is unsafe. Which I think, well, the UASF, without anything else, I definitely think is unsafe, as I've explained in other episodes. And I think this combination is still unsafe, despite it having some cool features. So I'd rather deal with the current annoying situation than to, you know, open the other can of worms. But we can explore what that can of worms looks like.

Aaron van Wirdum Well, I was just sort of prefacing this. I was saying, okay, this is given the trade-offs and... my knowledge of how the system works and the risk and my personal preference is that any soft fork should be a UASF in Core or maybe somewhere else that's not part of this podcast discussion. I think it should be UASF with mandatory signaling and standard users should also given being given the option to opt out through a URSF So that opinion sort of stands on itself. Now to mitigate the risk and this was what you're getting at, so to mitigate the reorg risk and that kind of stuff I think it would be much better if this sort of battle happens without any casualties.

Sjors Provoost Yeah.

Aaron van Wirdum And and I think that this can be accomplished fairly well through futures markets. So instead of actually splitting the chain and only then allowing trade between the coins and now all of a sudden one coin is more valuable and another while the market is sort of figuring this out live and it's been traded live and there are replay attacks and who knows what else, and then what the reorgs and You know, the Bitcoin Core user in the middle suffers. And so instead of doing that live, I think it can be done sort of virtually through futures markets.

Sjors Provoost So basically you're selling, you have an exchange that sells two sides that basically says, here's, you know, you deposit a Bitcoin now and it'll tell you you'll get either, you'll get, I think you'll get both at first. You'll get both back after the split and then it's up to the market to decide which which half of that is worth more.

Aaron van Wirdum Yeah.

Sjors Provoost And this has been done by Bitfinex in the past.

Aaron van Wirdum Exactly, so you get both back after split. You get coins on both sides of splits, but before the split you can trade between them.

Sjors Provoost Yeah.

Aaron van Wirdum So, and if you trade between them if I sell all my [unclear] coins for URSF coins then I get two [unclear] coins and zero [unclear] coins after split yeah right. So this way the market can figure out which option they think is more valuable which which version of Bitcoin the market really wants. Do they want the soft fork version, or do they want the version that rejected the soft fork? And by allowing the market to figure this out before there's actually chain split chaos miners can see all right users clearly want the soft fork so we're just going to mine the soft fork because we want to make as much money as possible. So that's what…

Sjors Provoost So miners will have to pick a side based on the market estimate and you get some data from the market.

Aaron van Wirdum Exactly. So I think if the futures markets work as I expect them to, then there won't actually be any re-arc chaos afterwards. If you're still worried about that, you can still use the client you want, but this is sort of a way to mitigate that extra risk that otherwise sort of neutral users that aren't aware of what's going on might suffer. So you use futures markets for that and then the miners can react to that.

Sjors Provoost So as much as I think futures markets are super cool, I don't like the idea. And I guess I have roughly three reasons for that. But I don't know if you wanted to finish something.

Aaron van Wirdum No, no, no, go ahead. I think that's sort of my case.

Sjors Provoost So one is this adds a whole bunch of complexity compared to what we have now. And I don't want to say proof of stake complexity. But, you know, some complexity at least. Because now it depends on how much market power you have and what happens to the protocol. So the second is that personally I don't believe in... I don't believe in the strong efficient market theory. So the idea of an efficient market theory is that the markets, you know, the collective knowledge in the market will know, well, collectively will be able to make a good prediction of what's actually going to happen, taking everything into account. But my impression is that, you know, the market very often does not take things into account, especially black swan events. But I also think if they just don't understand the subject matter, the market can be very, very wrong. But even if it was, the question is whether the implementation of the market would be correct. And if you're dealing with a very short-term soft fork activation, though, of course, you could make the term longer.

Aaron van Wirdum I definitely think it should be at least a year.

Sjors Provoost Yeah, and probably more because if you look at, you know, somebody just sets up a quick futures market like Bitfinex did, there's going to be discussions about whether the market is fair. There's going to be a lot of discussions about market manipulation. So that's kind of where I come up with my earlier argument, if the future market is not super well structured it could be manipulated by people with a lot of money to to push the result one way or the other.

Aaron van Wirdum Well I think with UASF versus URSF it's pretty clear right? You get paid on that client the whatever chain that client…

Sjors Provoost Yeah but there's all sorts of shenanigans that the exchanges that are trading these tokens can do right? They can manipulate the order book. It can be people pushing money around. I mean every problem you have on an unregulated exchange or commodities market you're going to have here. So eventually you can iron all that out because the species has hundreds of years of experience with how to set up a stock market and how to set up a securities market or a commodities market. But then maybe we'd need like 10 years of SEC enforcement and whatever to really get a proper... A proper futures market that is really reliable. But maybe that's acceptable, right? Maybe we say, okay, we don't do another soft fork for the next 10, 20 years while we figure out this futures market thing and make sure it's completely fair. That could be. And maybe that actually ends up happening over the long run anyway. What was my third one? No, I think this was my third one. So my first argument was, I think this adds complexity. Including you know giving power to rich people. Okay the second I don't believe in efficient markets.

Aaron van Wirdum Let me respond to that live now. Oh, okay.

Sjors Provoost And then I just wanted to recap it but we…

Aaron van Wirdum Are recapping it. So your first argument is gives people to power to rich people. So I I don't think that argument is very compelling, because there's nothing really new about futures markets like right now you know the Winklevoss twins and Michael Saylor or whoever could release an alt client, and then start selling their Bitcoin and buying these alt coin or new Bitcoin version of it. The only thing the future market does is sort of make that virtual instead of having to do it live, that there's no actual difference other than that, if I don't see any other difference. So it's there's nothing new going on here. It's not it's not some sort of proof of stake kind of system where the rich get to vote. No it's actual trading, like people actually trade in the same way that people already trade between Bitcoin and altcoins and like it doesn't you know Michael Saylor can decide to sell all his Bitcoin tomorrow and buy whatever shit coin he wants. That's trading, so there's nothing new there in my view. And then your second point?

Sjors Provoost Well, my second point was that I don't believe in general in the efficient market hypothesis, at least a strong one. So that's difficult to debate here, I guess.

Aaron van Wirdum Yeah, that's difficult to debate. I just have a strong... I think it's just the best we have, basically, and maybe you don't.

Sjors Provoost Well, I'm not saying it's not the best we have. I'm just saying it's not good enough.

Aaron van Wirdum But if it's the best we have, we should do it, right?

Sjors Provoost No, because we could just either stick to what we're doing with BIP9 and just accept that it may be very difficult to get some soft forks through if miners really don't like it.

Aaron van Wirdum Right. Yeah, remember that. Again, my points about futures market isn't an argument in favor of... Uh why I think there should be UASF and URSF I think these that should be the case anyways I just think a futures market is a way to make it safer. Okay and then your third point?

Sjors Provoost My third point is that even if in theory a futures market could work in practice, it's going to be very difficult to get it to work because of all the shenanigans that can happen on markets.

Aaron van Wirdum I mean, that I probably agree with. Like in an ideal scenario, we all work towards a future where we can do these kinds of things, trustless on Bitcoin with smart contracts, or I don't know what that would look like, but that would be ideal.

Sjors Provoost Maybe. I'm super skeptical about that because I think Bitcoin solves one specific problem and I don't think blockchain technology, quote unquote, is useful for something like a stock market I think some things are fine in centralized systems

Aaron van Wirdum Yeah I'm not going to think out loud of ways you could do this… I'm

Sjors Provoost No but

Aaron van Wirdum I it seems plausible to me that you could somehow lock bitcoins up in a certain way and then only be able to unlock them anyways maybe. Um yeah so that was sort of my point on futures markets which I'll say it for the third time. That's not even an argument in favor of [unclear]. I think [unclear] should exist either way and UASFs as well. I just think futures market would make it the safest way to do it.

Sjors Provoost Yeah, exactly. But I think without the futures market, it would be super unsafe. And with the futures market, it would be unsafe or something like that.

Aaron van Wirdum Yeah, I mean, you like miner vetoes. I can tell.

Sjors Provoost Yeah, I love miner vetoes. So maybe it is useful to talk about this concept of rough consensus or even like what is supposed to happen under good circumstances with protocol upgrades.

Aaron van Wirdum Yes.

Sjors Provoost Because it's a very good reminder that there was another way to do it, which has worked a few times. So the idea of rough consensus is defined in some Internet Engineering Task Force standard, which is a very hippie document. It talks about humming and rough consensus, and it's definitely written by people in San Francisco. But the idea there is that when you make a new technical proposal, when you make a proposal for a change, you're supposed to, well, first of all, you should spec it out in a way that people can read it. You should write some working code that actually does the thing that you're saying, so you don't have all these pie-in-the-sky perpetual motion machines. And then other people should be paying attention to it, should be reviewing it. And if they don't have any objections, then you can go forward with it. If they do have objections, and those objections are of a technical nature, not of a political, like, I don't like the color green kind of nature, then you should address those technical objections you should explain either why the objection is wrong, or you should find a solution for that. And if you follow that process, it does kind of mean that that proposals move forward by definition. Like there's no because there's not really a way to stop these things from happening there so the things may get stranded because there may be objections and you can't fix them, so then the the proposal stops, and there may not be anybody willing to review your proposal because people just don't care about it, in which case it stops. But if enough people review it and they don't find problems with it, well, then I guess within the current mechanism, you would then propose something like a BIP9 upgrade where miners can signal for it. And if they do signal for it, it just happens. But notice that there's no mechanism [unclear] to politically say…

Aaron van Wirdum It could still also be UASF, right? UASF could make it through this process.

Sjors Provoost Yes, but what I'm saying is more like there's no obvious way how something will be stopped other than to have an articulated technical reason why it should be stopped. And so what is missing, you could say, maybe that's not good because we have seen that miners can sort of randomly veto something if they don't like it, even if they have no reason for it. But there's no way for users to veto something. And so that could be another perspective of why something like a URSF could be interesting, even if I'm skeptical about this proposal. But the idea could be there could be soft forks that there's no technical objection to, yet for some interesting political reason, we just don't want it.

Aaron van Wirdum Well, the other reason could, of course, be... You know, like this is a good process or these are good principles, but developers could still, you know, get lost in their own biases. They're still humans. They could become corrupted.

Sjors Provoost That could be one scenario where developers indeed, yeah, they just go off on a tangent. They come up with some software that nobody has a good technical objection to, but actually nobody wants it either. Yeah, because something went wrong with the developers. And then, yeah, the question is, what do you do about that? One thing could be simply that nobody downloads it out of apathy, maybe. But then because developers keep releasing new versions that also fix bugs, you could get into a situation where you kind of have to. And then there's not an obvious way to resist that. So I'm not saying that the problem is unsolved.

Aaron van Wirdum I do like these are obviously good principles or at least they sound like obviously good principles. I think I've personally become a bit less worried about you know the concrete example would be an alt client that releases in UASF outside of this process I've personally become a little less worried about that, and the reason for that is what I just discussed is the futures markets if someone thinks the process doesn't work well let them test it against the market. If they're right the market will just reject it and there will never be a split, and no miners will mine it right? Or maybe they're right and they help Bitcoin forward and move past a broken process, but either way I'm I've become noticeably less worried about alt clients, because I think right hope but I think futures markets will sort of solve that problem.

Sjors Provoost Yeah but again yeah we we talked about that that hinges on on how much you trust future markets as well as their specific implementations.

Aaron van Wirdum Market efficiency. Yeah.

Sjors Provoost Yeah, um and I maybe we can bring up I can bring up one more point which we did talk about before. So far we've talked about rejecting a soft fork based on signaling, so you you well we also talked about flag day but in this this URSF concept, the idea is that you reject a signal for a soft fork, but there are soft forks that don't have a signal. And flag days are one obvious example of that, where there's simply nothing to reject because the new rules apply at this date and there's nothing you can stop, basically. And another very pernicious example of a soft fork that you can't stop this way would be like a mandatory KYC miner whitelisting kind of thing where miners only mine blocks that are compliant in some bizarre way. And there's nothing on the blockchain that shows that they are. So there's nothing you can do then other than that you would say, well, we mandate that certain transactions be in there. But that's a really weird rule to have as a user. So in general I would say there we don't really have a good way to reject soft forks like maybe this could be a way to reject signaled soft forks.

Aaron van Wirdum Well so I think what you're describing now is a 51 percent attack, and I guess yeah I guess sort of what we're discussing or the way I see it is you know engineering principles like how should we do things? And yeah sure the system can still be attacked in other ways but what should we strive for what should we do if we want to upgrade the protocol?

Sjors Provoost It's true. I guess the difference between a 51% attack and a soft fork in the example we talked about with KYC stuff is that as soon as the attack stops, basically, the system reverts back to normal where all transactions are accepted because nodes are not rejecting those transactions, only miners are. Whereas the soft fork, the idea would be that it's permanent. After whether or not miners signal at some point those rules have been enforced for a while and we can assume that they'll always be enforced they're not going to be reverted.

Aaron van Wirdum Yeah I mean if we wanted to but I'm not sure if we want to, we essentially this sort of gets to a philosophical discussion of what is even Bitcoin? Like what what are the Bitcoin rules? What is a full node? Well and in that sense like this is sort of how I would define it I guess uh you know if

Sjors Provoost I mean, you do not want to be the first person to run a hard fork that stops enforcing SegWit, basically. So that's sort of a mechanism that keeps enforcing the rules that are activated in a soft fork. But those rules would actually have to be... Those rules are in the code, and they're in the code that miners run, they're in the code that exchanges run, they're in the code that users run. And if you want to be the first one to relax those rules, it's usually not a good place, so you'd really have to organize that.

Aaron van Wirdum Yeah, well, what I was going to say is I would maybe even argue or make the case that the way I would define the protocol upgrade is there needs to be something on the blockchain that signals that and that can be recognized as such so people can either upgrade to the new rules or reject it. At this point, the discussion is getting philosophical.

Sjors Provoost Yeah, I mean, we've had soft forks without signaling, but I agree that signaling is a good way to do it. Okay, I think we've probably covered this concept, and the episode may be a little bit confusing, but at the same time, hopefully interesting.

Aaron van Wirdum They usually are, I think, Sjors.

Sjors Provoost Well, sometimes we have a very clear concept that we're going to explain, and it's a little bit less philosophical.

Aaron van Wirdum This was a bit different than usual, yeah.

Sjors Provoost Anyhow, that all.

Aaron van Wirdum I think that was it.

Sjors Provoost All right, then. Thank you for listening to Bitcoin Explained.