Episode 27: Softchains

Aaron van Wirdum Before the show, a quick word from our sponsor. Live from Utrecht, this is the Van Wirdum Sjorsnado.

Sjors Provoost Hello.

Aaron van Wirdum Hello.

Ruben Somsen Hello.

Sjors Provoost Hey, who's there?

Ruben Somsen I don't know. Someone who's never been on the show before.

Sjors Provoost It's Ruben.

Ruben Somsen Oh.

Aaron van Wirdum Ruben is back.

Ruben Somsen Yeah.

Aaron van Wirdum Again.

Ruben Somsen Yeah.

Aaron van Wirdum Ruben, I think you're our in-house sidechain expert.

Ruben Somsen I guess so.

Aaron van Wirdum At this point. Well, I would consider you a... You're a… Bitcoin expert. But it seems like your specialization lies in all sorts of sidechain. Anything sidechain.

Ruben Somsen Yeah, that seems like it. It just happened to be like that, become like that.

Aaron van Wirdum Is that how am I using the term correctly? That's how I've been using the term. Sidechain is sort of the umbrella term. And we have all sorts of different ways of doing it, which have their own names like drive chain or state chain.

Sjors Provoost Depends if you're picking on the definition of sidechain, then it's not. Then you would just say other chain or related chain, I guess.

Ruben Somsen Yeah, but that doesn't really roll off the tongue. I'm a other chain expert. Well, not altcoins, I guess.

Aaron van Wirdum No, you're not altcoins.

Ruben Somsen So it's difficult. Yeah, I like, generally speaking, I'm very much interested in trying to get Bitcoin to do more with less. And I think sidechains are a good avenue for reaching that. So that's kind of why I think I spend a lot of time thinking about these things.

Aaron van Wirdum Yeah, so you came up with another idea, another type of sidechain, I would call it, which is called a softchain.

Ruben Somsen That's right.

Aaron van Wirdum And that's what we're going to discuss today.

Sjors Provoost Yeah, we're going to try and understand it.

Ruben Somsen Great.

Aaron van Wirdum So first of all, for the listeners who haven't listened to one of the previous episodes about sidechains, Ruben, what is a sidechain? Briefly.

Ruben Somsen Yeah, so a sidechain is basically a completely separate chain, ideally, that you can move your bitcoins to and you can move your bitcoins back again. And the dream is kind of that you can build out this ecosystem where your bitcoins are not necessarily stuck with Bitcoin's validation rules. But if you like Ethereum's validation rules or something, you could maybe move your bitcoins to some Ethereum-like chain and use them there. And then when you are done again, because you figured out that Ethereum is not so great after all, you can move back to Bitcoin. Buying and selling is not quite that at all. And this kind of preserves the 21 million Bitcoin limits, where you don't have to deal with all these altcoin shenanigans, yet you still get all the functionality that you might want that is not available in Bitcoin currently.

Sjors Provoost So that's an argument from experimentation or from more features.

Ruben Somsen I guess so. Yeah.

Sjors Provoost And your other argument, I guess, would be scale, in theory.

Ruben Somsen Yeah, yeah, that's definitely a second argument. Good point. Yeah, if you have all these sidechains, then potentially, you could have more block space. You could have multiple sidechains that are just like Bitcoin or maybe slightly different. And yeah, it basically gives you more block space for people to use.

Aaron van Wirdum Yeah. So let's say you want to use some sort of DeFi app that's not really compatible with the current Bitcoin protocol. You can move it to a sidechain. That has these Ethereum rules and you can do all your DeFi stuff there. And then when you're done, you move back your bitcoins to the main Bitcoin blockchain.

Ruben Somsen Yeah. And importantly, yeah, you can do it with your bitcoins, right? Because we talked about, I think I didn't call it space chains back then, but I call it space chains now, which is blind merge mining in a perpetual one-way peg. So that one did not allow you to move your bitcoins to, well, you could move to the other chain, but you couldn't move back. So this proposal actually allows you to move back. But there are obviously downsides as well, which we'll get into.

Sjors Provoost Yeah. A couple of weeks ago, we talked about drive chains, which do allow you to move your coins back.

Ruben Somsen Yeah. And that's also good to kind of point out the difference. So with drive chains, very high level, the miners basically control the bitcoins and they decide whether or not you get to move back. And with this proposal, it wouldn't be like that. It would actually be consensus, basically, whether or not you get to move back.

Aaron van Wirdum Yeah. So we just gave a DeFi example. Other examples would be like Zcash, sidechain, or like any altcoin that's out there. Basically, you could instead use a sidechain and then therefore use sort of the Bitcoin currency unit.

Ruben Somsen Yeah.

Aaron van Wirdum Under these different rules and conditions.

Ruben Somsen That's right.

Aaron van Wirdum All right. So soft chains, your new, well, is it new? No, when did you propose this?

Ruben Somsen Yes and no, it's new. I posted it December 31st last year. So not too long ago because we just entered this year. So it was a little New Year's gift, so to speak.

Aaron van Wirdum It's your newest one.

Ruben Somsen It's my newest one, but it's, you know, I'm building forth on work that I did about a year and a half ago on proof of work fraud proofs. So it's not completely new, but the kind of sidechain aspect of it is new.

Aaron van Wirdum Right. So yeah, that is the first step in explaining how soft chains work or proof of work.

Ruben Somsen Fraud proofs.

Aaron van Wirdum Fraud proofs, exactly. So let's get into that. And before we get into that, I want to tell the listener, at this point, it's probably easiest if you forget about sidechains for a minute. Ruben is just going to explain a consensus mechanism. It could potentially work on the Bitcoin main chain as well.

Ruben Somsen Yeah.

Aaron van Wirdum Okay, so let's get into it. What are proof of work fraud proofs?

Ruben Somsen Yeah, so we're taking a bit of a detour here and we're going to be talking about how you could potentially validate a blockchain, such as Bitcoin or other blockchains, in a way that is very cheap to validate, essentially. So it's kind of like one way of doing that would be SPV proofs, where SPV basically means you look at the proof of work. And you just assume that whichever chain with the most proof of work, a lot of effort went into creating that chain, so it must be valid. Like that's one way you can get very cheap consensus. But the general issue with that is that you're trusting that 51% of the miners or more is actually telling you the truth. And if everybody starts relying on that, these miners could actually create coins out of thin air. So it's not very secure, but it would be one way of kind of getting cheap consensus.

Aaron van Wirdum Yeah. So the normal way to achieve that is for everyone on the network to control, to check every, to validate every protocol rule.

Ruben Somsen Yes.

Aaron van Wirdum To validate that everything that happens in every block is valid.

Ruben Somsen Yeah.

Aaron van Wirdum And then SPV, like you explained, is a much cheaper way to do it because you're not checking everything in every block. You're only checking the proof of work. Yeah.

Sjors Provoost And so in episode 25, we actually explained SPV.

Ruben Somsen Oh, great. Yeah.

Aaron van Wirdum Right. And then soft chains is a method sort of in between.

Ruben Somsen Well, proof of work, fraud proofs, right? That's why we're not talking about the soft chains yet.

Aaron van Wirdum You're right.

Ruben Somsen Yeah.

Aaron van Wirdum It's sort of in between full validation and SPV validation in a way.

Ruben Somsen So if you look at SPV, the assumption is SPV works if 51% of all miners are being honest. And with proof of work fraud proofs, what you can do is you can say this validation method works if there is some honest miner out there and you can choose whatever percentage you like, if you say it's 1%, that's fine. You can go all the way conservative to say 0.01%. But the difference is that what your assumption is affects how slow your validation is.

Aaron van Wirdum You need more confirmations if you want to trust less miners, am I saying that right?

Ruben Somsen Yeah, so so let's take a simple number like one percent, if you assume that only one percent of all miners is honest and 99 is out there to get you, it basically means that you got to wait for that honest miner to create their block. And if you don't see that block, well, you're not going to see that block until you've given them enough time to actually create that block. So that's why it's a slow consensus mechanism, but it's much more secure than SPV. And you no longer have the 51% assumption.

Aaron van Wirdum Yeah. So to restate that with SPV, with full validation, you don't need to trust any hash power, basically. With SPV, you need to trust that at least half hash power is honest.

Ruben Somsen Yeah. More than half, yeah.

Aaron van Wirdum Proof of war— work frauds proofs…

Ruben Somsen Sorry for the name. Yeah.

Aaron van Wirdum You can sort of pick your own level of trust in hash power and then depending on that you need to wait for more confirmations.

Ruben Somsen Yeah.

Aaron van Wirdum And let's say I think okay I think at least one percent of hash power is going to be honest so therefore I'm just going to wait a whole day of confirmations for example. Yeah that's maybe two days or whatever. Yeah. Okay. So how does this work?

Ruben Somsen Yeah exactly. So so the way this works is you only look at the forks. So if you have normally, when you have the Bitcoin blockchain, you download all the headers, and then you download all the blocks that are associated with the headers. But what you do here is you start with only the headers, and then you look whether there are forks. So maybe you have like a block one, block two, block three, four, five. And then somewhere along the line, you see another block three. So block three B, let's say. So there's one, two, three B, and there's one, two, three, A, four, five.

Aaron van Wirdum I want to make a small clarification for listeners that don't know this because the term fork is very confusing.

Ruben Somsen That's true, yeah.

Aaron van Wirdum We're not talking about Bcash kind of altcoin forks or anything like that. We're just talking about the normal operation of things in Bitcoin where sometimes, for example, by coincidence, two competing blocks are mined by different miners and then eventually the longest chain wins out, right?

Ruben Somsen Yeah, that's correct.

Aaron van Wirdum That's the type of fork we're talking about here.

Sjors Provoost Yeah, which we mentioned in last week's episode.

Ruben Somsen Perfect.

Aaron van Wirdum You're like an encyclopedia of episodes.

Sjors Provoost Yeah,

Ruben Somsen So basically these are regular, naturally occurring forks that would happen in Bitcoin anyway, just by pure coincidence or if a miner just happens to mess up or whatever. So these occur naturally. But there are also reasons why they could occur kind of unnaturally, which is that a miner is kind of deliberately trying to create an invalid… and if there's a deliberate attempt to create an invalid block, all the miners that kind of don't want to participate in that invalid chain, they need to fork away from that chain. So given we kind of can…

Aaron van Wirdum Hang on, do you mean by invalid in this context? Do you mean that it's breaking protocol rules?

Ruben Somsen Exactly, yeah.

Aaron van Wirdum So for example, the miner is awarding itself a thousand Bitcoin as a block reward.

Ruben Somsen Yeah, so basically anything that your full node would reject. If your full node were to download the block and validate the block and they would reject the block, that would be an invalid block.

Aaron van Wirdum Right, yeah. So it's possible for miners to create invalid blocks. Then you have a fork, basically. What happens then, Ruben?

Ruben Somsen Yeah, so that's kind of what you want to check for, right? You want to figure out whether something is invalid. And so this is called proof-of-work fraud proofs. And the reason for that is maybe it's not the best name. Sjors, you had a suggestion.

Sjors Provoost I think it was proof-of-work fraud indicator.

Ruben Somsen Fraud indicator, yeah. So I like that. I forgot it again, but yeah, it's good. So fraud indicator, let's say. The fact that there's a fork is an indication that the block you're forking away from might be invalid, but you don't know for sure.

Aaron van Wirdum May or may not be, yeah.

Ruben Somsen So if we then had a method to validate that specific block, we could actually kind of investigate that claim and see whether or not something is wrong. So that's the first thing. And the second thing is that this miner that created the forked block, they did choose to mine… the block before it is the same in both forks.

Aaron van Wirdum Yeah, they still agree that the block came... Before it is valid. Everyone basically, of all the forks you're seeing, everyone agrees that block is valid at least.

Ruben Somsen Yeah, otherwise they wouldn't have forked from that point. They would have forked earlier.

Aaron van Wirdum Right.

Ruben Somsen So we have two assumptions here. We have the assumption that that block might be invalid and the block before it, all the miners agree that it's valid.

Aaron van Wirdum Right.

Ruben Somsen So with that assumption, now what you need is you need to download block three and you need to validate it. But we have a problem because you need the UTXO sets.

Sjors Provoost To validate the block right because every block contains transactions which refer back to previous transactions and those previous transactions well they're not in this block so either you have to download all the other blocks or you need to keep track of you know which coins currently exist and that is the UTXO set.

Aaron van Wirdum Yeah, which we discussed in episode well…

Sjors Provoost In a whole bunch of episodes but in particular because of where we're going in episode 15 where we explain Utreexo and UTXO commitments right.

Ruben Somsen So yeah, Utreexo, which is definitely an episode I think you should go back and listen to, but Utreexo basically gives you a solution to validate blocks without having the entire [unclear] sets. You just need a hash. And then you need some proofs that are attached to the hash. And that allows you to validate a transition. So in this case, from block two to block three, we can validate that transition. So what you need inside of block two, inside of consensus, is a hash to the Utreexo state. And with that state, which you assume is valid, because we're assuming block two is valid, you can then… validate the transition from block two to block three, without requiring the entire UTXO set. And that's how we achieve basically what we want, which is validating block three and figuring out whether the most proof of work chain is valid or not.

Aaron van Wirdum Yeah, so the reason it's that much lighter than full validation is because you're not downloading all the blocks. You're only looking for potential conflicts where they exist. And that's the only thing you check.

Ruben Somsen Yeah.

Aaron van Wirdum Well, plus... The block headers, the proof of work for all blocks.

Ruben Somsen Yeah, so it's basically every block for which there is another block at the same block height. You need to go and check the block inside of the most proof of work chain.

Aaron van Wirdum Right.

Sjors Provoost And if you're bored, you can also check, you know, a random other block as a spot check. Although for this mechanism, that doesn't really matter.

Ruben Somsen Yeah, I don't think it would do anything here, but it's definitely interesting that it's possible, thanks to Utreexo, if you have these commitments.

Sjors Provoost Yeah, so the interesting thing, there are different ways of doing commitments of the UTXO set in blocks. And Utreexo is a very interesting one, because it's not just a commitment, that you can, you know, if you have the UTXO set, you can figure out what the Utreexo is, but you could have a different hash as well but that hash won't be very useful to check the next block and with Utreexo it is useful to check the next block because you can it's a hash that you can add things to. It's an accumulator. Yeah, so I can take the hash of the previous block add all the transactions to it and now I have the hash of the new block. Yeah, and well we explained that in episode 15, but not all UTXO commitments will work like this.

Ruben Somsen Yeah, that's right.

Aaron van Wirdum So yeah, I want to point out right here that this, what you just explained, this is why you potentially only need one percent of honest miners. Now let's say in this example, you just gave proof of work, fraud proofs, fraud indicators. If 100% of miners is dishonest, then you're never going to find out because there's never going to be a conflicting block. They're always colluding and you're just never going to find out.

Ruben Somsen Yes.

Aaron van Wirdum But if there's even 1% of honest miners, then at some point that one honest miner isn't going to build on the longest proof of work chain because they think it's invalid. They know it's invalid. Instead, they're going to create a conflicting block that's honest. So even if there were like 100 blocks that were dishonest, after block one or whatever. And then at some point, the honest miner will create an honest block two. At that point, you see the conflict and you go check which of the two block twos is valid. If you see that a block two that created, that preceded the 100 blockchain with 100 blocks, then you're just going to reject all 100 blocks and you're going to continue only on this block number two.

Sjors Provoost Yeah.

Ruben Somsen So it's important to point out here that the creation of the fork is really not a sacrifice, right? It's not that that person who created that fork block and caused the 100 blocks to be rejected. That's just kind of the normal way things should be. Like that person who created the forked block, they get the block reward, whereas everybody else who was building on the invalid chain, they get nothing, right? Because their chain is invalidated.

Sjors Provoost Right, but it is a little bit risky because at any point, if you're proposing, if you're telling the rest of the network, oh, we're about to do a 100 block reorg, or maybe a thousand or whatever it is, at some point the rest of the network might say, well, although you're right, like it's not worth the damage that this reorg does, but we don't want to get too far ahead of our discussion section…

Aaron van Wirdum But, well, we can get into this now maybe?

Ruben Somsen Yeah, I think it's a good like…

Aaron van Wirdum Yeah a lot of people might say, well I just sold my car for these coins or I just you know I just accepted rent or whatever let's you know okay yes sure the chain turned out to be invalid but, let's just forget about it. Let's just continue on this chain because I don't want to lose all this money I received. That's sort of possible. That's sort of complicated incentive thing going on there, game theory thing.

Sjors Provoost Now, of course, if you're receiving money on one of those soft chains or whatever thing is built on top of this mechanism, if you're the one receiving coins on it, you probably want to do full validation of that particular chain. So at least you know that there's a problem. But then you could still have the opposite, where you can see that there's cheating going on, but you may have to wait a whole year for any miner to agree with you on the fact that there's cheating going on. Because all the other people are not validating. You're the only one validating.

Ruben Somsen Yeah, so the people who are not validating, not fully validating, but only basically doing the proof of work fraud proof validation, they have an assumption to make, right? Like they have to assume that there is a honest miner out there and they have to, because of that assumption, they have to slow down how long they wait. So if you receive money for a car and you use this consensus mechanism and you don't wait for the proper number of blocks, yeah, that is just... The wrong behavior, basically. That's not what you're supposed to so that's basically outside of the trust assumption of this model. But if your assumption is wrong, right, if you just assume one percent of all miners is honest, and that's actually a wrong assumption, yeah, then then you are screwed. So that's definitely, you got to make a conservative choice there. And for that reason, this consensus mechanism isn't isn't very practical. Instead of a full node, like you could theoretically run this on your phone or something, right?

Sjors Provoost So ironically, this reverses the risks when compared to how Bitcoin works when it comes to light nodes. So if on Bitcoin, you're running an SPV node, but you see that if you're running the SPV node, you might be cheated because you're only checking the proof of work. But whoever runs the full node knows exactly what's going on. But here it could be the opposite. You could be running a full node, you could be verifying everything very carefully, but you just don't get all the headers for some reason. And so, yeah, you might not know that somebody else is out there lying, basically. You'd have to not see a very long chain of headers, but...

Ruben Somsen Well, if they're invalid headers, presumably none of your peers are going to tell you about it because they're invalid. So maybe it's possible to not be aware.

Sjors Provoost Right. Yeah, I guess you'd still be following the valid chain, but you might not know that there's an invalid chain out there because you might only be talking to other full nodes. So you don't know that the rest of the network is kind of trusting on an invalid chain and shit is about to hit the fan. Although you have the correct chain, it may take a while for the rest of the network to agree on that because there's an invalid chain out there that you don't know about. Though I guess you would know about it.

Ruben Somsen Yeah, I think arguably it might be just good in general to... Give all valid proof-of-work headers to all the full nodes, regardless of whether or not they're in the most proof-of-work chain, just as an indicator of whether something is wrong. But that's kind of a separate discussion.

Sjors Provoost Yeah.

Aaron van Wirdum So we've explained this consensus mechanism in general terms.

Ruben Somsen Yeah.

Aaron van Wirdum So how do we apply this as a sidechain?

Ruben Somsen Yeah.

Aaron van Wirdum That would be the next step, right?

Ruben Somsen Yeah. Yeah. So now we have this consensus mechanism, which you could theoretically apply to Bitcoin and you could have consensus this way, but just very slowly.

Aaron van Wirdum Yeah. Plus it would require Utreexo or something like that.

Ruben Somsen Yeah.

Aaron van Wirdum Which doesn't exist. We create a sidechain, it's easy to just implement it there.

Ruben Somsen Yeah, I have a method of actually not even requiring a Utreexo commitment, but let's not go into that. But there's a post out there if you're interested in that.

Sjors Provoost But it is good to realize that... The Utreexo and the commitments, they are a bit of a controversial idea. But in this case, they wouldn't have to happen on the Bitcoin side. They'd have to happen on the sidechain side. And so maybe we'd be fine with that.

Ruben Somsen Yeah, yeah, exactly. So what we're doing here is we're using this consensus mechanism for the sidechains or softchains, as I call them, that we're going to be introducing. So on the side of the softchains, you need to have these Utreexo set commitments, but not inside of the Bitcoin blockchain. So that's not something that we require for Bitcoin here.

Sjors Provoost But you do need some soft fork on the Bitcoin side.

Ruben Somsen Yes, yeah, absolutely.

Sjors Provoost Tell us.

Ruben Somsen Yeah. So the way it works is we are going to introduce a soft fork. And let's say we just start very simply. Let's say we want to create 10 more copies of Bitcoin. We use Bitcoin Core for it, exactly the same. So we kind of want to create a kind of a side chain block size increase, so to speak. So we create these 10 chains. And they will have no coins on them. And there's going to be no block reward or no coins being generated every block. But people can move their coins in. And moving their coins in is going to be very simple. It's just you freeze your coins on the Bitcoin blockchain and you point to a chain that you want to go to. And then what we do is we expect everybody who runs a Bitcoin full node to validate these 10 other soft chains. But they validate them through these proof of work fraud proofs. And roughly speaking...

Sjors Provoost Fraud indicators.

Ruben Somsen Fraud indicators. Yeah, that's a better name. And roughly looking at the Bitcoin blockchain and its history and looking at kind of just natural forks occurring by accident. This comes down to, I think it was roughly, I don't remember the exact numbers, but something like 40 blocks a year. That's probably even on the high end. And roughly this would cost you, including the headers, 100 megabytes per chain per year.

Aaron van Wirdum What you mean is 40 fork blocks, basically, right?

Ruben Somsen Yes.

Aaron van Wirdum So 40 times where you'd have to check… exactly, if anything weird is going on.

Ruben Somsen Yeah. And that's with, yeah, not, you know, non-malicious. Nobody on purpose… well, presumably, I guess we don't know what what the reason was for these forks.

Aaron van Wirdum Sure. Yeah.

Ruben Somsen So given roughly those numbers, we can introduce those 10 chains and we can get everybody to validate them with proof-of-work fraud proofs and it would cost them 10 times 100 megabytes per year. So roughly one gigabytes. And if we thought that was a burden on the full nodes, we could even combine this with a block size decrease. I think one gigabyte is only like minus 1% or something. So we could decrease the Bitcoin block size by 1% to compensate for the extra cost. And then we basically introduce these 10 chains. And it's important to note, and this is something that some people I've explained this to have gotten confused about, you completely separately validate the header. So you just have to get the headers from the peer-to-peer network, from these proof of work, from these soft chains. So they're not going to be committed inside of the Bitcoin blockchain or anything like that.

Sjors Provoost It is essentially like you're running 11 nodes.

Ruben Somsen Yes.

Sjors Provoost So your main Bitcoin node does full validation and then you have 10 Bitcoin sidechain nodes built in, of course, that are doing this partial validation by just doing the headers and just checking conflicts.

Ruben Somsen Yeah, that's right. And then what we do is we make the peg outs incredibly slow. We make them like a one year period. So the peg out meaning you moved your coins to the soft chain and now you want to move back. So moving back is going to take a year. And the reason we do that is because we don't want to rely too much on miners. And if we wait a year, I don't know what it works out to, but it's like 0.01% or something like somebody out there within a year has to create a fork when an invalid block occurs that is specifically trying to peg out something that's invalid.

Sjors Provoost So a peg out on the main chain, that of course is a soft fork, right? Because it's probably from old nodes point of view, an address that anybody can spend from. Coins go in there. Those coins belong to the side chain. And for old nodes, anybody can just take that money. But for these new nodes, there are constraints. But what exactly is that constraint? Some sort of block refer… they have to refer to a block hash on one of the sidechains?

Ruben Somsen Yeah, so this is not completely worked out because I think they're, you know, this really, you go into the weeds and I think those design decisions kind of need to come later.

Sjors Provoost Well, but roughly you refer to a block hash because then you could say, well, if that block hash is forked out or like in an invalid block, because we checked all those conflicts, we're not going to accept the peg out.

Ruben Somsen Yeah, that's right. Yeah, you definitely have to. So... If you want to peg out on the Bitcoin blockchain, you say, hey, I want… to, so you're not even spending the UTXO yet. You're just saying like one year from now, I want to take some coins out of this UTXO. And you point to a specific soft chain block, which also contains your peg out transaction that you want to be referring to. And then from that moment inside of Bitcoin consensus, you wait one year worth of blocks, however many blocks that is. And then after a year, if that block, if that soft chain block that you pointed to is still valid according to proof of work fraud proof consensus, then you get your peg out.

Aaron van Wirdum Yeah, so to make the problem you're solving here very concrete, if I understand correctly, to give one example is that miners would create an invalid transaction on the side chain to just pay all the money to themselves. Yeah, and then your assumption is well there's got to be some miner out there somewhere who's going to actually create a valid alternative yeah, and at that point it creates a conflict and at that point, everyone checks and sees that the valid alternative is not sending all this money to all the miners so therefore the peg out transaction is invalid and won't happen.

Ruben Somsen Yeah, and and to add to that: if there is no block that is forking away from the invalid block, then from the perspective of everybody who's using the soft chain, and it's important to note, if you're actually using the soft chain, you're running it as a full node. So you opt into it and you actually validate it normally. So then from their perspective, the chain is not moving forward because this is just a big chain of invalid blocks. So all their transactions are stuck. So there's basically a huge fee pressure of saying like, hey, build the next block, please, because everything you're building is invalid. From that perspective, I think it's incredibly unlikely that within a year, there is not going to be a block that is going to indicate that that entire chain was actually invalid.

Sjors Provoost But this is where I start getting really scared. And you're also going to get really scared. You already gave some examples, but I'm going to give another one, which is that… this is a fraud indicator, as you said. It's not really a proof. And I guess a difference here would be a proof would be something committed to the blockchain that really says, okay, this is the real thing and this is the evidence that this thing is wrong. And there's problems with that concept. But at least everybody would have access to that proof at the same time. And with this fraud indicator… you're really hoping that all the Bitcoin full nodes are aware that this particular pegout is invalid. So all of them have seen this alternative header chain, have seen this header fork, basically.

Ruben Somsen Yeah.

Sjors Provoost Because if one doesn't, then they might think, oh, it's perfectly valid. And so you get a consensus disagreement there. And that might still work out if the majority of hash power, at least, because, you know, as long as the Bitcoin miners, the majority of the Bitcoin miners, are doing the correct thing. But if they're not, then things get real messy.

Ruben Somsen Yeah, worst case scenario, which I think is kind of an unlikely scenario, right? That you don't learn about a certain... It is very similar to how in Bitcoin you're assuming that you learn about the most proof of work chain. And if nobody tells you about the most proof of work chain, then you might get stuck on some fork and you don't see the chain move forward anymore or something like that. Theoretically, I guess that could happen on one of these soft chains. I think it's unlikely, but let's say it did, then that one node or those couple of nodes that are in that situation, they could theoretically fork away from Bitcoin and they would consider some, well, yeah, I guess I guess it would be a scenario where they think a certain pegout was invalid because they didn't learn about it or something.

Sjors Provoost No, it'd be the other way around. So I think it wouldn't be too bad because yeah if if there is a pegout that is not valid, but but you have not seen the real chain, then you don't know that it's not valid. But that's okay, because you still think you think it's valid.

Ruben Somsen Yeah, but it's not being spent, basically, then.

Sjors Provoost Yeah, so I think you'd be fine in terms of the software dynamics there. So maybe we should move on to the example you talked about, which is, now let's do some funny things with consensus.

Ruben Somsen Yeah, so there are problems with this, which you haven't talked about yet, and let's get into that.

Aaron van Wirdum Yeah, let's get into it. You're the expert.

Ruben Somsen Yeah, so the problem was so far that I've identified, and... I guess I'll start with saying that… at its current… they're not terrible, but I think they are bad enough for it to not really be a great idea for Bitcoin yet. Like really, if we can't mitigate these issues sufficiently, I don't think this is something that should currently be activated in Bitcoin.

Aaron van Wirdum Right, so you're against your own proposal?

Ruben Somsen I am basically against my own proposal. I think there is some potential there to think it through and maybe mitigate these issues. So I'm hopeful that we can get to a point where it's safer than I think it is, or than I currently think it is.

Aaron van Wirdum Right. So we're considering this sort of like a first draft.

Ruben Somsen Yeah, yeah, basically.

Aaron van Wirdum Okay. So why is it a first draft? What's the problem?

Ruben Somsen So the first issue, and this is one that I think can be mitigated, is that you could have a non-deterministic consensus in one of these soft chains.

Aaron van Wirdum You mean like a bug, or is that what you mean or not?

Ruben Somsen Yeah, it would be a bug. So what I mean by non-deterministic consensus is that: you and I run the proof of work, fraud proof, a soft chain, the software on a different computer, and somehow the software interprets something differently, and you think a block is invalid, and I think a block is valid. So that would be non-deterministic in the sense that we don't, given the same data, we don't come to the same conclusion.

Aaron van Wirdum Right, but that's the same for Bitcoin itself, right? That's a problem right now.

Ruben Somsen Yes. So what I mean here is that let's say if you want to do something fancy, like, hey, let's create an Ethereum soft chain.

Aaron van Wirdum Right.

Ruben Somsen Well, then you inherit all of Ethereum's crazy stuff that's in there. And that is not something I would be comfortable with because of this non-deterministic bug potential which could come back to actually influence Bitcoin main chain because let's see how this would occur yeah if there's a transaction there's a pegout transaction and the block is in dispute because there's a fork block and because of this the non-deterministic behavior your node thinks the pegout is valid and my node thinks it's invalid then a year goes by and now the pegouts, half the network thinks the pegout is spendable, half the network thinks the pegout is not spendable. And now you run into a fork on Bitcoin, actually.

Aaron van Wirdum Yeah, so any risk of the sidechain would actually be an equal risk for Bitcoin in this scenario. Yes. It wouldn't be some sort of sealed off risk. That's a problem of sidechain users; it would now all of a sudden be everyone's problem.

Ruben Somsen At the very least, you would see it coming because it would occur before that one year period is up but you know that eventually it's going to happen and then you need to actually take action to prevent it, which is like at least the soft fork.

Sjors Provoost So in a way it could be the difference between two operating systems like you said Windows and Linux maybe having different interpretation but it can also be different versions right we had, Bitcoin 0.7 and 0.8 where we you know introduced a consensus bug which had to be undone and, now you have 10 different chains each with their own development team and they might not be very experienced and they one of those teams makes a single mistake like that. Yeah. And boom.

Aaron van Wirdum Yeah, so as if consensus isn't hard enough on Bitcoin itself, yet now we're expanding that to potentially less competent teams.

Sjors Provoost Yeah, right. Now you could go back to what you said, the simplest version, which just adds scale, which is having 10 clones of Bitcoin and maybe even, I think you mentioned in the mailing list, you turn off everything except Taproot and you simplify it, make it as unrisky as possible.

Aaron van Wirdum Yeah.

Sjors Provoost Now that actually brings up another, two other issues for me. One we haven't talked about yet, I think. But I forgot what it was.

Ruben Somsen I'll interject and at least say one thing, which is something that Adam Back pointed out, which is that it's sort of like an extension block. An extension block would be that you have sort of a blockchain inside of a blockchain that everybody validates. So it's sort of the same thing here, where you could have an Ethereum extension block or something like that. The difference just is that it's an extension block that's really cheap to validate for people who only care about the peg-ins and the peg-outs. And the people who actually want to use the day-to-day, they got to go and actually do full validation on it.

Sjors Provoost Yeah. So I have a couple of them that could be a problem.

Ruben Somsen Okay.

Sjors Provoost One is a denial of service attack where I am a miner and I'm going to create blocks with very low proof of work, basically. Well, it depends on when the soft fork is introduced. But if these soft chains have the same proof of work, but it's the lower difficulty, I could create lots of separate chains, presumably that you then all have to validate to figure out which one is wrong. And the other thing you mentioned that I… and that was the one I forgot, actually. You mentioned that these chains don't have their own block reward.

Ruben Somsen Yeah.

Sjors Provoost But then why on earth would you mine them? Just for the fees, I guess.

Ruben Somsen Yeah. Yeah, so it would be the same as, you know, Bitcoin eventually has to get into that state as well.

Sjors Provoost But why not give it a block reward and have a nice game of musical chairs?

Ruben Somsen Well, that would be an altcoin. So then you basically break the 21 million limits by creating these other coins that I guess can't move back into Bitcoin mainchain, but they would be…

Sjors Provoost No, they can, just until the peg runs out.

Ruben Somsen Until…

Sjors Provoost So it just becomes more and more fractional.

Ruben Somsen Oh, yeah, fractional. Yeah, that would be great. Fractional chain. Well, you know…

Aaron van Wirdum Translate in a different price, obviously, defeating the point of a sidechain.

Ruben Somsen Yeah, I think that would be…

Sjors Provoost It's a strictly lower price.

Ruben Somsen Yeah, that would be kind of disastrous. But yeah, no, that's definitely a good point. You run into the problem that Bitcoin will eventually run into sooner, and you sort of have a bootstrapping problem in the sense that when you first start the chain, there's not going to be much, in terms of fees on there. So there are a couple of things you can do. I think the first thing you would want to do is be very conservative with how much block space you add. So you don't want to start and just create 10 chains right away. You want to start maybe with one chain or something like that, or you could have like one chain activate every year, or I don't know, something along those lines. And yeah, the other thing you want to do is make sure that there's enough proof of work because yeah, like Sjors’s pointing out, if the proof of work is really cheap, every time a fork is created and… it could then potentially be created really really cheaply, every full node has to do more work. They have to dial out another block and they have to check the Utreexo proofs. It's roughly uh three megabytes. So yeah, that would not be ideal. So… either you would want there to be some kind of minimum where you say, well, a block needs to at least have 10% of Bitcoin's proof of work or something along those lines. Or, and I don't know if we want to get into that now, I guess we should, you could do merged mining.

Sjors Provoost Right, because the other thing with proof of work before we get to merged mining is if all these things are clones of Bitcoin Core and they all use SHA-256, now you have these giant ASIC miners that can pick. If they want to mine the main chain, some shitcoin clone, or one of these 10 alternative chains, and because they could overwhelm any of these alternative chains, they could do all sorts of shenanigans where the whole game theory, I think, is not clear in advance. Generally, it's very bad when two coins have the same proof-of-work algorithm. The big coin can really bully the small coin.

Ruben Somsen Yeah.

Sjors Provoost Re-org it out of existence; mess with the difficulty do all sorts of shenanigans and now we can you know we would do that times 10 yeah so it's it's, very interesting yeah I guess a minimum proof of work could at least make that more difficult, yeah but then they you'd have to design consensus rules to compare difficulties. And uh…

Ruben Somsen Yeah, there are some complexities there, which I agree are not ideal, but I do think they're solvable. But yeah, we are getting into the territory of where you're starting to create fixes for little problems in ways that are not really elegant?

Sjors Provoost I think where this will go, and I think I mentioned this before in another episode where we said there's some implementation details to work out. Why do implementation details matter? Because I think once you think about them... You will end up with just bigger blocks. That's sort of where you, after you apply fix after fix for problem after problem, you end up right back where you started with bigger blocks. And then you say, well, we don't want bigger blocks because the problem we had with bigger blocks. And it turns out you can't fix the block size problem.

Ruben Somsen Yeah, I do think it's not quite like bigger blocks. At the very least, it's a soft fork, not a hard fork. So that's a win. And I think the second thing that…

Sjors Provoost You can make bigger blocks with a soft fork.

Ruben Somsen I guess you could if you made it an extension block. Fair enough.

Sjors Provoost Yeah.

Ruben Somsen Okay. That's true. Yeah. So I guess to your proof of work points, just briefly to point out, you could choose to have different proof of work on these different chains. So that could be one way of doing it. But I think that would also be a little messy.

Sjors Provoost And that opens… multiple cans of worms right it opens the cans of worms that other coins have when they come up with the new proof of work and oops there's an ASIC or oops there's no ASIC and or you're competing with some altcoin you didn't know about. Yeah. But also this proof of work is, again, another consensus thing that could have bugs in it.

Ruben Somsen Yeah. Yeah. I think that's also in terms of, you know, I'm very slight tangent, I guess, but like every time a new coin is created, you don't know if the creators secretly have an optimization for whatever they chose for their proof of work.

Sjors Provoost Yeah. Yeah, and there's also the symmetry, because some proofs of work are not as nicely symmetrical— asymmetrical, I mean, some you know, with Bitcoin it takes a lot of work to produce the right hash, but it always takes the exact same amount of time to verify the hash. Yeah, so the verification is O zero as we say I think. So it scales with the zero power, so it doesn't scale at all. And then the proof of work scales more than that. But there are other forms of proof of work where it might be actually quite expensive to verify it. So then you create another DoS factor where in order to verify all these blocks, you need to do very expensive proof of work verification because, oops.

Ruben Somsen Yeah. I feel like there's one criticism that I haven't addressed.

Aaron van Wirdum Yeah, I think generally speaking, so to… get back on track, I think the two main downsides you've mentioned now are the consensus risk, if there's a bug in one of the sidechains, and the potentially low proof-of-work security of the sidechains. And then the third one…

Ruben Somsen Well, yeah, there's one more thing we should get into about the low proof-of-work, which is merged mining. So that's one potential way of solving it. And now I remember what I was going to address, which was to claim whether or not this isn't just like a block size increase. So if you do merged mining… what you could do is you could say, well, every soft chain block just requires the same amount of proof of work as a Bitcoin block. And what that means is that every Bitcoin miner has to also merge mine the soft chain. And this makes it more difficult for miners, which is a real downside, which I'm not happy with. But it would mean that everyone who wants to be a Bitcoin miner also has to be a miner for every soft chain. So if we were to introduce 10 soft chains, that would mean they have to run another 10 full nodes to get all the fees and to create adequate proof of work.

Sjors Provoost And do they have to create a block every time or can they opt out of creating... I guess they can opt out of some of the chains, right?

Ruben Somsen Yeah.

Sjors Provoost But they lose out on revenue.

Ruben Somsen Yeah, exactly. So it would be, that's kind of always the tricky thing with merged mining. You're sort of obligated to merge mine because you're not going to be competitive if you don't do it.

Sjors Provoost Right. And we talked about that in the episode about drive chains, where if you're a miner on the moon behind a Tor node, it's not fun if you have to download other chains as well.

Ruben Somsen Yeah.

Sjors Provoost And especially if those other chains also have super complicated smart contract validation rules and terabytes of data.

Ruben Somsen And I guess it's worth mentioning that something like blind merged mining doesn't actually work for this. And there's an important reason for that, which is that you need forks to be outside of Bitcoin consensus. And with blind merged mining, your consensus of your other chain is inside of the Bitcoin chain, which means that whoever is the Bitcoin miner can choose never to allow you to create the fork in the first place. So blind merged mining is off the table here.

Sjors Provoost Yeah.

Aaron van Wirdum Okay third problem?

Ruben Somsen Oh yeah, just one more thing I want to address which is so in this scenario the miners would have to do more work but it's still the case that everybody who runs a regular full node and these soft chain full nodes or soft chain nodes they they would not have to do 10 times the work. They would just have the same amount of work that they're doing today. And optionally, if they want to opt into one of these soft chains, then they have to validate that specific chain. So I think it's still a win in that regard where, you know, maybe you would have two chains that you validate per person and the other eight or nine chains you don't care about.

Sjors Provoost Well, at least, yeah, I guess other way to put it, if you're running a regular node, you verify what you care about.

Ruben Somsen Yeah.

Sjors Provoost Right. Plus a little bit of work for the other chains.

Ruben Somsen That's right.

Sjors Provoost With all the caveats that we talked about.

Ruben Somsen Yeah.

Sjors Provoost Denial of service attacks that make you verify all the things.

Ruben Somsen Yeah. Okay.

Aaron van Wirdum I think it's time for problem number three.

Ruben Somsen That's right.

Sjors Provoost Was there a third problem?

Ruben Somsen There was. Yeah. So the third problem is also sort of related to low proof of work, which is that you could have a scenario where there is a one-year reorg on a soft chain. And if that's the case, and if this this one-year reorg…

Aaron van Wirdum That basically means 99.999% of miners are dishonest or something like that.

Ruben Somsen Yeah, or 200%, like depending on how you want to look at it, like you have a chain and then suddenly a new new chain appears. Okay, yeah. Yeah, and and it doesn't have to be— it doesn't even have to be invalid. These could be two valid chains. The thing is that one year from now, you have to make a decision. Is this pegout valid or is this pegout invalid? Let's say right at the moment where it's about to become valid then you know you say in your node you say, okay this pegout is valid I'm done. And then right at that moment this other chain appears with a year worth of proof of work which basically pushes out the pegout transaction.

Sjors Provoost Oh, it suddenly appears.

Ruben Somsen It suddenly appears.

Sjors Provoost Oh, that's a problem.

Ruben Somsen That's a problem, yeah. And now that pegout transaction that you thought was valid is not valid. And if this happens right at that moment, right at the year cutoff, then half the network might think it's valid, half the network might think it's invalid. And now we're back to the fork issue.

Sjors Provoost This reminds me of something that happened to Bitcoin Cash. Because they were doing a bunch of hard forks, and they had very low proof of work, and then they had a little bit of a fight with Bitcoin SV, and they were threatening to reorg each other. And basically, if you have two tiny, tiny coins, in this case, and you start reorging one of them, well, yeah, in general, if you have a tiny coin and somebody threatens to reorg you, you might get a reorg of 10 or 20 blocks or something like that. Rather than just accepting that, which means you just have to wait more confirmations, the Bitcoin Cash folks said, no, no, no, no. If your node sees a reorg of more than 10, it will ignore it. And this is very bad because what happens now is that, let's say you are running continuously, your node is constantly on. It sees a bunch of blocks coming in and then it sees a 20 block reorg. And so it ignores it. And then it might stop because that 20 block reorg might actually be the chain that's continuing. So your node will just stop suddenly. But if you're a new node and you're starting up, you're just looking at which is the longest right now and you're going to follow that. It means that the state of your node depends on how long it's been online. And if somebody games it and… creates reorgs that are exactly 10 blocks long. It just creates them secretly and then sends them over the network. It just knows that because of the difference in timing, it's going to knock half the nodes out. And or you can steal coins that way, of course. Because if you can fool an exchange into no longer checking new blocks…

Aaron van Wirdum With the amount of proof-of-work security on Bcash, someone could do that as a hobby.

Ruben Somsen I think. Yes, I think.

Aaron van Wirdum Okay, so that's… yeah, and that's kind of the same problem here.

Ruben Somsen Yeah, I totally agree. It's exactly the same problem. And I think specific to what you mentioned, I think Bitcoin Unlimited does not have that. So if you run an exchange, just go run Bitcoin Unlimited. So you don't have that problem. But yeah, you could literally…

Aaron van Wirdum Does that still exist?

Ruben Somsen That's a good question. Maybe this is all the information by now.

Sjors Provoost The code exists somewhere, I guess it exists.

Ruben Somsen Yeah, maybe it's uh it's not being kept up to date. So any any recent Bitcoin Core bugs might apply here. But yeah.

Aaron van Wirdum Or newly introduced bugs.

Ruben Somsen Yeah, that's possible too, of course. So really, yeah, it is that same problem where you have this one year cutoff. And that, if there is a reorg right at that moment, you know, the saving grace here compared to the Bitcoin Cash examples, that's not 10 blocks, it's one year. So that makes it better.

Sjors Provoost This comes back to my point that the difference between a fraud proof that is committed somehow…

Ruben Somsen Yeah.

Sjors Provoost And so, you know, what all the reorg rules are versus an indicator, which depends on when you see things and does not depend on something that's actually in the main blockchain.

Ruben Somsen Yeah.

Sjors Provoost So, yeah.

Ruben Somsen But the one-year reorg, if we were to do merged mining, it would be incredibly unlikely that… any miner would succeed in doing that without getting noticed.

Sjors Provoost Yeah, but when it comes to Bitcoin consensus, incredibly unlikely is not good enough.

Ruben Somsen Yeah, maybe, yeah. But yeah, it is definitely, it's a pain point, right? And we can try to mitigate it and we can make it less and less painful, but it stays there. It's there. And I don't think you can get rid of it completely. And there was one more mitigation that I wanted to point out, which is that what you could do is you could actually disallow, just like your example, just like with Bitcoin Cash, you could disallow reorgs of longer than half a year on the soft chain. And what this does is you create the exact same problem as Bitcoin Cash, right, where if you have a half a year reorg, suddenly you you lose consensus but because you do it after half a year not after a year the consensus issue appears on the soft chain first. And then you still have half a year before that issue goes and comes to the main chain. And then you could potentially do a soft fork or something like that to mitigate that issue if it occurs. I don't think this is great because you don't want to rely on soft forks, but I'm just throwing it out there.

Sjors Provoost So I think we talked about this long enough.

Aaron van Wirdum Yeah.

Sjors Provoost Let's get to the verdict.

Ruben Somsen Yeah, I think…

Sjors Provoost I say let's not do this.

Ruben Somsen I agree.

Aaron van Wirdum Yeah, I think we all agree, or at least I would say it's an interesting concept. It's fairly well thought out, but part of that thinking it out includes concluding that there are some trade-offs that probably make it not worth the risks and the efforts for now.

Ruben Somsen Yeah, so I'm hopeful that maybe other people who are listening to this come up with some ideas to make it more viable than it is today. I have a little chat room that I actually created for space chains. So if people want to join me there and try and think of ways of mitigating that, it's t.me slash space chains. I use it for softchains as well. I mean, I don't want to create another chat room for every proposal. So that's, you know, if people are interested in that, they can come join me there.

Aaron van Wirdum That's on Telegram.

Ruben Somsen That's on Telegram. Yeah.

Sjors Provoost Okay.

Aaron van Wirdum I think that's it, Sjors.

Sjors Provoost Okay, then, thank you for listening to the Van Wirdum Sjorsnado.

Aaron van Wirdum There you go.

Ruben Somsen There you go.