*** Thanks to Chris Lin for editing this transcript *** Anna (00:00:07): Welcome to Zero Knowledge, a podcast where we talk about the latest in zero knowledge research and the decentralized web. The show is hosted by me, Anna. Fredrik (00:00:18): And me, Fredrik. Anna (00:00:27): This week, guest co-host Georgios and I chat with Hasu, an independent crypto researcher, focused on Bitcoin and Ethereum, economics and security. We talk about the history of elastic block size proposals in Bitcoin, and some of the new proposals now making their way into Ethereum. But before we start in, I want to say thank you to this week's sponsor Trail of Bits. The initial release of yVault contained a bug that could be manipulated by an attacker to drain most (if not all) of the pool's assets. Trail of Bits found this bug and quickly reported it to the yVault team, they were able to secure the roughly 400 K USD held in the system. This bug, which was luckily caught highlights the risk stemming from increased complexity caused by composition in the DeFi space as described in their recent blog post entitled "Accidentally stepping on a DeFi lego: DeFi composability is hard". For example, if you integrate multiple tokens, any one token could compromise the security of your entire platform. On the other hand, if you integrate multiple platforms, your protocol could suffer from complex interactions. If this is a relevant topic to you or the project you work on, reach out to Trail of Bits to arrange a security assessment or sign up for their Ethereum security office hours. I've added a link in the show note to the blog post as well as their website. So thank you again, trail of bits. And now here's our interview with Hasu. So this week I welcome back Georgios to the show. He's here, partly as a guest, and partly as a guest host, while Frederick is still off bringing Polkadot to life. So welcome Georgios. Georgios (00:02:10): Hi Anna, glad to be back. Anna (00:02:12): So tell me, Georgios what is new since the last time you've been on the show? Georgios (00:02:17): Previously I was operating independently or so working with companies that wanted my services. And recently I joined Paradigm as a research partner to work closely with the funds portfolio companies. And as a general disclaimer, everything is said in this podcast is my views and my views only and does not represent the fund. Anna (00:02:41): Sounds good. So today's guest is Hasu or Hasufi, Hasufli. How do I say... what's your handle? Hasu: Just Hasu, it's fine. Anna: Okay, cool. So Hasu is an independent crypto researcher, who's focused on Bitcoin and Ethereum, economics and security. So welcome to the show, Hasu. Hasu (00:03:01): Hey Anna. Hey Georgios. Anna (00:03:03): So somebody on Twitter, like this was a tweet, sent it at us a while back, somebody pointed out that podcast hosts tend to start the episode with, when did you first learn about Bitcoin? And that might not be interesting for most people, right? But actually in this particular case, I'm quite curious about your origin story. Like where do you come from? What, you know, what part of the world got you into this space? Hasu (00:03:34): Yeah. I can give you the short rundown, so... Anna: Sure. Hasu: So I started way back. I started... I dropped out of university to play online poker professionally. Did that for almost a decade and that's, that's why I came into contact with like computer science for the first time, as we bet proprietary training software for online poker. And at the time I used Bitcoin occasionally, but I didn't really look into it. I just, I just used it, which is probably pretty rare. And then when poker was kind of dying around 2017, 18, then I was looking for a new challenge and that's the first time I really looked into Bitcoin. I mean the first time I really looked like beneath the surface, it didn't mean like, it, it clicked pretty soon for me, so I obviously wish I would have done it sooner. Hasu (00:04:30): But I was in the fortunate position really to put all my time and just studying crypto, from that point on, I didn't really have to have to work for a few years, so I could just sink all my time into that. And like the Twitter and medium made it really easy to build an audience at the same time. So it's almost like you get paid for learning as long as you're willing to like, tweet about it and write about it a little bit. So that's, I think like social media makes learning so much easier and so much more fun and interactive. So yeah, Anna (00:05:04): I totally, I completely identify with this. I mean, this podcast was a learning has been a learning experience for myself, I think also for Frederick, but you're right. Like being able to create something at the same time has so many more benefits than maybe just learning on your own. Hasu (00:05:18): Yeah. I realize that, but playing poker that I enjoy teaching more than playing. For the last years I didn't really play much myself anymore. I just, I was focused on developing software for studying and analysis and I had some players that I coached pretty actively. So... Anna (00:05:38): You just said that like poker died. I actually don't know anything about this. How did poker die? Hasu (00:05:45): So yeah, all games that are played for money and they are not purely chance, but are like some spare component. They have a natural life cycle where there's this incentive for good players to invest a lot into getting better. So they do. But the bad players don't really get better. So that if there's a widening gap between the bad players who financed the whole poker economy and the good players and yeah, so that's, that's how games basically come to an end Anna (00:06:17): Because it's no longer worth it for people to get good, I guess. Hasu (00:06:21): Yeah, because there's not enough new inflow of money, because it's no of fun anymore for bad players just because they lose so fast. And this was really accelerated dramatically by the rise of machine learning. So that's what we worked with as well. Every online pokers there nowadays. I mean, this is what chess computers, for example have been based on for a long time, but yeah, you have the same for poker. So anyone who plays online poker for any meaningful amount of money today, they study all day using machine learning towards just to get better pretty much. Anna (00:06:56): Wow. I mean, that's a whole world. I don't know that much about, but this is interesting. I want to ask you, so like now we know your story kind of from poker to Bitcoin really, but like, did you, you like, you just first got into Bitcoin, but now, I mean, I definitely know of you more through your interactions with the Ethereum community. Would you say it's Bitcoin and Ethereum for you now? Or are you also involved in other projects? Hasu (00:07:23): Attracts? I would say it's Bitcoin and Ethereum. I started out mostly focusing on Bitcoin, but nowadays that's a lot of stuff that I like a lot about Ethereum. Like more and more of my research has been focused on that lately. Anna: Okay. Hasu: And I feel like it, it reflects like you have this synergy effects as we're there. So if we study something that happens in Ethereum, like we did with the EIP-1559, that's always something to take away from for Bitcoin as well. Anna (00:07:53): Okay. You're one of these, I mean, I know a few researchers that have their foot in both of these ecosystems. Do you find the balancing act, a challenge? Do you get shouted at, from both sides or are you pretty much embraced? Hasu (00:08:08): Yeah, you're maybe embraced less than someone who lives in only one of the words, but overall I feel like, I mean, especially now that I guess it's more popular now than last year to be interested in Ethereum as well. So yeah, it doesn't, it's not really a problem. Anna (00:08:27): So let's move on to the topic that we have planned for this episode, which is we're going to be looking at this like elastic block size proposals and how they stack up, I guess. So why, why don't you start, Georgios, because you have that first question, so yeah. Why don't I throw it to you Giorgio's to sort of get this conversation started. Georgios (00:08:50): Yeah, thank you Anna. So Hasu, I guess we can start by talking about why do we want blocks to not be too big, but also not too small? Why does the block size... Hasu (00:09:05): Yes, block size is probably like the most discussed metric? So there are really three reasons. Three downsides to larger blocks. So they are larger blocks, increase validation costs for users and they hurt fairness. Fairness is a term that we would get into in a minute. And they also hurt fee revenue that is necessary to secure the network. I start by explaining a validation costs. Bitcoin is basically a replicated database, right? And the state of their database is who owns which coins. There's been for a start in the UTXO set. And like when Bitcoin versus traditional databases in who can write to the chain by a proof of work, but also who can validate the state. Because only when you, when you know, whether coin you receive is actually in the correct state there, and it's recognized by the rest of the network only then you know, that basically you actually received a Quine on Bitcoin that you can trust. This is equivalent to being a root user of a database compared to, let's say, interacting with the database via trusted middleman, because that trusted middleman, I can tell you anything they want, right. Anna (00:10:32): In the traditional kind of computer setup. Hasu (00:10:35): Exactly. Yeah. Yeah. And to compute the state like the latest state of Bitcoin, and you need to run the state transition function on our previous transactions from genesis, this we're kind of downloading everything that has ever happened on Bitcoin and then running signature verification and a bunch of other validity checks on these transactions and the larger blocks get the more data there is to download and process for a new node that wants to come online in Bitcoin and then also wants to stay in sync with the blockchain as it grows. So the larger the blocks, the more there is to validate and the higher, the cost of being a root user of that database becomes. And I, I guess just can say a bit more about that, but like most of quote, unquote innovation in other blockchains, or a lot of it actually comes down to tinkering with this one metric, the validation costs. So a lot of what is sold as scalability is actually introducing new trust assumptions by jacking up the validation cost. Georgios (00:11:48): Yeah, exactly. And typically users forget or other creators of these chains, forget that it is very important to be able to validate the state yourself because otherwise you are exactly, as you said earlier, you would be relying on other middleman to serve you the state. And in the end of this middleman, they're not providing any proof that the state they are serving you is the correct one. So for example, today Infura does not provide any further proof and any metal proof, for example, which says that, you know, this transaction was actually included. It's just an API that you trust to give you the information. Anna (00:12:29): And you can't, like, like a light client, can't see, wouldn't be able to actually verify this, this type of level of transaction. Georgios (00:12:38): So a light client can do that. Although in few connecting to inferior, you're not connecting as a light client, you're just asking the server for some arbitrary information, but also in the context of light clients, you change the security assumption from previously where it was that you're validating all state transitions and that, you know, that this date is actually valid. You're changing it to the SPV assumption, which in Bitcoin, this is called Simplified Payment Verification, which means that you are trusting them, the proof of work only, and you're not trusting the actual state transition function to be applied correctly. Anna (00:13:20): But so what you just described, so these are the downsides of the large blocks. Hasu: The first one of them. Anna: Yeah. Okay. What's, what's the next downside of a large block. Hasu (00:13:30): Large blocks for fairness between miners, all Proof-of-Work clients want this property quiet fairness, which basically says that for every hash that might not compute, they should get the same reward. So and I, who provides 1% of hashes should get 1% of rewards and another miner maybe provides 30% of hashes should get 30% of the rewards. So it's, it's really about this proportion proportionality, Anna (00:14:02): But would that not happen with a large block? Is it like too much? Like, does it, does the, do the proportions get changed because they are large. Georgios (00:14:11): Yes, exactly. So large blocks benefits larger miners because of the propagation delay of blocks during mining, you can think of the propagation delay as an unfair advantage because a larger miner can mine on their blocks immediately, whereas it needs to propagate to everyone else first, before they can mine on it. So using the example of the 30% hash rate miner, 70% of the time, the large minor has to wait for someone as this block to arrive for him in order to start mining on it. Whereas the smaller minor, where's only 1% of hashrate needs to at 99% of the time for the block to process. Hasu (00:14:53): And that's why basically, like I said, if you're the 30% miner, then basically 30% of the time you have a propagation delay of zero and this, this is really amplified by the block size, right? The larger blocks are the longer they take to propagate, and the more it hurts fairness. Georgios: just to clarify by what, on what has meant that by propagation time of zero, because if you have 30% of the time, if you are the miner, you don't need to propagate it to anyone. You have the block. So the propagation time is zero because you already have the block. Hasu: They used to have to propagate if you want other miners to converge with your blockchain, but you can build on it immediately, whereas everyone else can bid it in zero plus propagation delay. Anna (00:15:40): All right, is that, are those all of the downsides of the large blocks? Are there other things? Hasu (00:15:44): Well, the third one is that larger blocks hurt fee revenue, which in some networks are required for security, such as in Bitcoin. And Bitcoin, the block subsidy is supposed to decrease over time. And then one day fees are supposed to pay for security alone, but fees and Bitcoin are the reside of block space, supply and demand. And users are only willing to pay fees if it helps them get priority over some other users. So in the supply, if there's ever too much supply of block space so that anyone who wants and can get in, then there's no bidding for priority. So if, if you have really large blocks, you set yourself up for the scenario where there may not be the congestion necessary to create fees, and without fees there's no security without security. There's no demand to use the network and so on. So that's, that's really a security death spiral there. Anna (00:16:42): It's almost like it's become too efficient. Hasu: Yes. Anna: But I know that, I know that that's usually liked but in this case it's a negative. Hasu (00:16:49): Yeah. Right. Yeah. Georgios: But Hasu, to be clear, this only applies on change where the blocks subsidy eventually goes away such as Bitcoin. Do you think that this could become a potential problem for Ethereum? Hasu: No. I don't think that's... no, Ethereum based on its design can not have this problem because they are set up to have a permanent block subsidy. They will always have enough incentive for the blockchain to move forward. They don't rely on transaction fees. In fact, as we'll see later, when we talk about EIP-1559, the fees were not even go to miners most of the time they will simply be burnt. Anna (00:17:33): So now I think you've covered the kind of challenges or problems with the large block, the two large blocks. What's wrong with small blocks on the other side of the coin. Hasu (00:17:45): One of the big problems when blocks are too small is that transacting is too expensive and too prohibitive for users. So we discussed previously, our large blocks can push users toward trusted third parties in the example of, Infura, or well, straight up using banks or exchanges. But they're the same as to when transacting it's just too expensive when blocks are too smart. So really the transaction cost and the validation cost, there are two, two sides of the same coin, basically two costs of using Bitcoin or using Ethereum. So it's, it's really like if it really doesn't have you much, if you can lower one of the two costs to zero at the expense of raising these other costs like super high, because the user still has to bear both of the costs anyway. So you want to keep them in some kind of balance, I guess. Hasu (00:18:48): Yeah. So what really happens if, if the base chain doesn't have a lot of capacity for users, then the users were either not use cryptocurrency. So there's really nowhere fair benefit for them at all on like no utility from the chain, or they use a trusted provider such as centralized exchange. And this problem is not really circumvented by layer 2 solutions either since or no one layer 2 solutions, at least for Bitcoin. And I'm not sure about Ethereum. So relying on Georgios there, they always depend on this assumption that the base layer is available for dispute resolution. So in other words, the assumption that you can always get a transaction in, at the base they are in a reasonable price, but if the fees on layer one on second friend uncooperative closed in the Lightning Network, for example, are a hundred dollars, then you, you really can't use the Lightning Network for anything less than a hundred dollars without becoming vulnerable to griefing attacks. Georgios (00:19:54): Hmm. I guess a detail on this is that Bitcoin's layer 2 design space is only around things involving fraud proofs while the Ethereum designed the theorem. Let's say ecosystem has support for utilizing validity proofs, whether that is a STARK or SNARK, or who knows what else in the future. So this is a;so nice because it's relevant to the ZK podcast after all. Anna: I like Georgios. He was always bringing it back to ZK. I forget. But yeah. Cool. Georgios: And so for example, in Ethereum says, ZK Rollup solutions, which is kind of, really one of the big things happening, there's no need to get a dispute transaction within some amount of time. So this kind of danger does not exist. If you use as your knowledge proof-based layer 2. Anna (00:20:54): Ah. I see. Are there any other disadvantages to the small blocks? Georgios (00:20:58): No, I think that that's pretty much it. Anna (00:21:02): Cool. So I have a, a followup because I just realized as we're going through this sort of large block versus small block comparison, I'm not actually particularly familiar as to where does Bitcoin fall? Where does Ethereum fall? And where do any of the other protocols that maybe we've talked about on this show fall? Is there a spectrum and like, can you place protocols across that? Hasu (00:21:24): Yes. So Bitcoin Ethereum actually very hard to compare because they don't have the same bottleneck for scalability and validation. So I think that Bitcoin's block size is actually larger than Ethereum's, which if you, like, if you ask someone on crypto Twitter, they would probably like 99% would say that Ethereum block sizes larger, correct. Like, let's say per hour or something. Right. However, the bottleneck in Ethereum is really the state growth because transactions in Ethereum can have, like, they can affect the, the state in very complex ways. And every transaction can trigger like really an unlimited amount of state updates. So it's much more complex, I think, to replay this as well. Whereas in Bitcoin and Bitcoin, I think the bottleneck is signature verification, but I would defer also to you Georgios on this. Georgios: Yeah. I guess in a more concrete way to compare, to compare the two is that when you make a Bitcoin transaction, you specify, I want to destroy this, this and that UTXO, and I want to create this or these new UTXOs. Georgios (00:22:47): So the system already knows what kind of state will be touched before and after the transaction gets executed. So it allows you to do a lot of more optimizations around it. Why in Ethereum, you cannot know the full result of the computation because as you're executing, like different things might happen because your contract call might call another smart contract, and that calls another smart contract. And so on that plus the fact that when all of this contract in their actions on Bitcoin eventually is just, just a list of UTXOs, which says that these are the unspent transactions, and these are the ones which may be used for future payments while for Ethereum, the state, there's a bunch of addresses, which have some storage and each one has its own different logic and so on and so forth. So it really is an additional state. The verification cost for Ethereum is a direct result of its statefullness Anna (00:23:52): For any of the other protocols that are coming out or who that have come out is block size something that's like deeply debated or considered, or is there sort of a standard that's kind of being used for these new systems Georgios (00:24:05): In my view that there's really, no, I'm not aware of any blockchain that goes for lower validation costs. Like that goes on this side of the spectrum. No one wants to beat Bitcoin or Ethereum in that regard, they all go for more throughput at the expense of validation... Anna: So a bid on the smaller side and... Georgios: On the bigger side. Anna (00:24:30): ...your side. Oh, so then a bid on the bigger side. Georgios (00:24:33): And also, if you look at basically all of the chains that are being validated by professional Proof-of-Stake validators which, and I understand that you also have visited... Lego.. plugable. Yes. All of the, all of these chains, they, they do not have nodes, which are easy to sync on your laptop, or even on a home server. Typically they require many more computer resources. And and so they, you can think that the end user of the Bitcoin or Ethereum node is, you know, the average Joe, while then user of their Proof-of-Stake, high performance blockchain, because the proof of stake validate order and the user is expected to get the data via a trusted endpoint. So it's almost as there is there's a different kind of market being targeted by the truth. Anna (00:25:31): I see. Okay. So then let's look closer at the like specific Bitcoin, you know, scenario, has there been a debate between like smaller blocks and larger blocks? How long has that been going on? Is this a, is this a forever thing that I'm just stumbling in on? Hasu: Yeah, it has been going on forever Georgios (00:25:50): Hasu, why don't you walk us through a few of the past Bitcoin block size proposals, whether they were formally stated in a bit, or just discussed on and you know, maybe we can talk about that a little more. Hasu: Yeah. So the block size is probably the most richly debated part of Bitcoin. For the reasons that we mentioned, it's it really like whether you prefer larger blocks or smaller blocks comes down to what you envisioned Bitcoin to be in the future? Like what your assumptions about the world are, like how Bitcoin should compete with other payment systems, mainly basically what you see it's product market fit. Right. And that's where all these debates come down to. Anna (00:26:39): So are you, you're kind of talking, I guess, here about like the Bitcoin is store value versus Bitcoin as a transaction medium. Yeah, pretty much. Yeah. Yeah. If people think it should just stay like you should buy it and hold it, then maybe it doesn't matter how fast or good or cheap it is to do the transactions. Whereas if you want to use it as payment, then it has different requirements. Hasu (00:27:01): Yeah, exactly. And that this long going debate then ultimately led to the fork or like the creation of Bitcoin cash as an altcoin in 2017. Anna (00:27:15): You know, I don't think we've ever really touched on that on the show. And actually like, since we're talking about it, who wanted, what, Bitcoin core versus Bitcoin cash, is that how you... is that the differentiation, Hasu (00:27:29): We haven't shot it over, you prepare it over the different proposals. And then I, I think it would be a bit more clear what different people wanted after going through them. So the original block size limit was added by Satoshi in 2010, but the limit was introduced in secret. And it also didn't really matter until 2013, because there was a secondary limit in place on the number of database locks. And this, this limit effectively kept the block size somewhere between half a megabyte and 0.75 megabyte. And in 2013, this limit that no one was really aware, even existed. It actually accidentally caused a chain split in Bitcoin. One of, I believe three major bugs that happened in Bitcoin that were exploited or triggered accidentally. And in reaction to that, then the, the lock limit was removed and there were one megabyte limit what's the new official limit. Hasu (00:28:42): So it was pretty much an unofficial limit before that time, but ever like during the solid time there were proposals to, to change the limit to various numbers, starting with BIP-100 by Jeff Garzik. And he, he suggested that a miner can vote on the block size within a range from one to 32 megabytes. So you basically give miner the power to decide how large blocks should be. I mean, this was pretty early, but nowadays, like we know that this has some incentive incompatibility issues for the reasons that we talked about earlier. So this, if you allow minors to make the blocks as large as they want, then like you get the larger miner the power to get an unfair advantage over smaller miners. And you give like better connected, it's better connected mining pools and advantage over more poorly connected one. So for example, it would have been extremely difficult for European or US-based mining pools to compete with Chinese mining pools, like when with 80 or 90% of hashrate were in China. Hasu (00:29:59): And then you increase the block size and increase the already high propagation delay even further. Then you effectively make it, you lock mining into China at that point, you say, okay, mining is going to stay in China because we are going to make it impossible for non-Chinese mining pools to compete. And this, this was followed by BIP 101 by Gavin Andresen. And he suggested to increase the block says to eight megabytes. And then I think starting in 2016, it was supposed to double it every two years. And this, this is kind of the first time that we see this algorithmic increase. So this proposal letter turned into Bitcoin XT by the way, a failed hard for contempt. Anna (00:30:49): So that's actually that that's, I was curious as you're going through it. So did BIP 100 go through? Hasu (00:30:55): No, none of these went through that. We are going to talk about, Anna (00:31:00): Okay. And BIP-101, they proposed it. Some people were into it and that caused this fork. Hasu (00:31:08): I think it was a few years later, actually that it was spun into Bitcoin XT, but this, there was no popular support for Bitcoin XT, and that's why the basic hard fork attempt failed. And I don't know if you've read this famous blog post by Mike Hearn "The resolution of the Bitcoin experiment" that this, this was in like that's when he resigned from being a Bitcoin developer and basically you handed in his resignation Anna (00:31:41): Because of this because of the BIP one Oh one. Hasu (00:31:45): Yeah. Because yeah, exactly. Because Bitcoin XT, no, he was, he was like a big proponent of this. So he wanted this he wanted this to succeed first in Bitcoin and then in Bitcoin XT, but Bitcoin XT failed. It did not have popular support and he blamed it more on I think censorship on like Bitcoin talk or whatever, like this was a big topic, like BIP-102 by Jeff Garzik was suggested to increase the block size to two megabytes. I think this was like one of the precursors that, that to the SegWit-2X proposal later, which was supposed to be a compromise between those parties who wanted a, to like an increase to two megabytes and those who wanted SegWit activated. So, you know, but yeah, it did not have popular support. Anna (00:32:41): What were the year differences between this like BIP-100 to BIP-101 to BIP-102? Hasu (00:32:46): That's a good question. I think BIP 100 was very early. Yeah. 2010 or 11. No, the BIP system did not exist back then. And I don't know when it was created actually. Anna (00:32:56): I'm just wondering, is this like, are they like coming out every two years, five years, ish. Hasu (00:33:01): This Bitcoins prog power. Anna (00:33:04): Okay. That comes up every time. What I find interesting here though, and like, realize I'm really, I'm really living outside of the Bitcoin world, but like, was there no other bips between these? It was just BIP 100 to BIP-101 to BIP-102. And they're all about the same thing. Hasu (00:33:20): No, I think they are actually organized by topic. Right. So I think you can, like, if you made a BIP today, you could get like a number in the high hundreds, like yeah. What do you want to do? Anna (00:33:32): Okay. Got it. Got it. So that's why these were all the ones around the block size. Hasu (00:33:37): I think so. Yes, I think so. Anna: Okay. Georgios: The addition of new opcodes and all of that, or adding new opcodes or changing it has been going through the BIP procedure. So it's not like only the blocks size that is discussed in the BIPs, but it's the most, let's say content thing. Anna (00:33:57): So now I'm curious to hear what was the last one. Hasu (00:34:00): Oh, there are a few more so, Oh, actually Pieter Wuille, who was, I guess today like known as like one of the most prolific developers in the Bitcoin core camp, which just send standard the implementation of Bitcoin. And you could say that the Bitcoin core won the popular vote during the block says for like to be the stewards of the main Bitcoin implementation. I mean, Bitcoin software that everyone uses, you would say a, a proposal to increase the block size by actually around 18% annually. So he introduced or he, and I think was it in json? Yeah. So he, they both made proposals that they'd rely on what we now would call a like technological constant. So the idea is that consumer hardware and bandwidth always increase or improve over time. So we can increase the box size because the validation cost actually goes down all the time. So we can always max that out if we want Anna (00:35:06): Kind of counterbalanced themselves and end up at a similar level. Hasu (00:35:10): Right. Exactly. So at least that is the case. If you ignore the third benefit of larger blocks or like, I guess one and a half of them, because the unfairness property still exists, but it also goes down over time as miners become better connected. Now there's proprietary software, or like even this isn't very good public software, like the miner, so they don't really, I'm not informed on this, but they don't really propagate the blocks over the Bitcoin network. I don't think, I think they have like their own blocks, but their own network for propagating blocks that it's like highly optimized. And the final one that was then activated the only change to the block size limit after Satoshi edited in 2010 was the SegWit update introduced in 2016 and activated in 2017. And it actually increased the next block size to around two and a half megabytes achieves this via an extension block. So that is the only time the block size was ever changed. Anna (00:36:18): So then what Bitcoin cash was? Smaller? Did it keep the original size? Hasu (00:36:24): No. Bitcoin, the Bitcoin cash proponents were pushing for larger blocks. Whereas what we now know is like Bitcoin, as we know, Bitcoin camp. They were pushing for the block size actually to stay the same. And then there was actually the, I don't, I mean, I, I, to this day, don't really understand why SegWit at this block size increase. I mean, I wasn't around at the time, but I know that I would have, I would have resisted that pretty hard picture of it. Georgios: So Hasu why would you be against SegWit or not against SegWit, but against the blocks has increased in SegWit? Hasu: Oh yeah. I would have, I would have been against the block size increase because I think we should not, like Bitcoin has this assumption that the chain needs to be always congested. So there's enough fees to pay for security. And I think it's very dangerous to increase the block size until we know that this condition is satisfied almost all of the time. And it really wasn't. So nowadays fees are like 11 years into Bitcoin. And let's say another 11 years before the block subsidy is pretty like it's very small and the fees are very, very small in Bitcoin and far from enough to pay for security. Anna: Oh, wow. Hasu: So they're really threw a wrench in this developing block space market where users were actually paying or willing to pay fees. Anna (00:38:03): And you're talking about Bitcoin core here. You're talking about the SegWit, the one that sort of get like most people would be using today. Hasu (00:38:10): Yeah, right. Yeah. Unfortunately. Yeah. Anna (00:38:13): So wait back to that though. Was Bitcoin cash bigger then? I still am not... So that's an even larger block size? Hasu (00:38:20): Bitcoin cash raise the block size. Yes. Anna: Okay. Hasu: I think around, eight megabytes. Anna (00:38:26): Ah, like that first or earlier proposal similar. Yeah, Hasu (00:38:31): No, they are in the range of like 32, but then so even inside the Bitcoin cash camp, there was later another hard fork, another group of people that split off, which was Bitcoin SV. Satoshi Vision, because they wanted even larger blocks. Right. So Bitcoin cash and Bitcoin iron, more assimilated thinking nowadays, what, what, like, what does safe block size limits looks like then Bitcoin SV, which yeah, they have like, they want their blocks to be like a gigabyte Georgios (00:39:07): Hasu so far we've talked about only constant changes basically or things which do not take other inputs from the system. They just say, either we set the block size to be this number, or we say, make the block size grow with this percent that via the technological constant. Are there any other proposals which take into account other inputs, such as miner preferences to change the block size and so on. And could you talk to us a bit about them? Hasu (00:39:41): Yeah. So blocks, like we discussed how they need to be the right size, but it's very hard to get that number right. And further like what this right size is, can vary dramatically based on external conditions. And I give you a few examples for that. So hardware and bandwidth can improve and then the validation costs would go down and maybe a block so said was unattainable a few years ago, might be fine today. Or transaction fees are higher than what we deem is enough to pay for security, and then we could safely increase the size without killing that security or the demand to transact is lower than the supply of block space. And then we are really in that scenario where there are no fees, no security, and we want to lower the block size and hence the supplier to create this artificial congestion in order to bootstrap security again. Hasu (00:40:37): Yeah. There's a weird problem where you want the block size to be something different based on different conditions and another popular one that, that one that actually received a lot of attention back then was so what if there is burst demand to transact right now because of a specific market event? So let's say that demand to transact, let's say five megabyte or 10 megabytes for a short time on the Bitcoin network, but it can't really support this. And if we allowed this, it would be neither bad for security because maybe the fees already high enough, or it wouldn't be bad for validation costs because in the grand scheme of things like over a year of blocks and the blockchain, maybe like a few 10 megabyte blocks, they don't make a huge difference. Right? So they don't really increase the validation costs very much. So there has always been this wish to be able to support bursts demand. So you can make blocks, select a few bigger for some time in order to satisfy that demand, but without increasing it permanently. And that's like all of these things kind of culminate in this idea of elastic block size proposers, and this is the second class of proposals where the block size changes dynamically based on external conditions. Anna (00:42:10): And does this lead us a little bit into kind of the conversation about Ethereum and this EIP-1559? Hasu: Absolutely. Anna: Very cool. Cause that's actually, that's sort of where I wanted to, like, I know that one of the things that we definitely want to cover in this episode is this EIP. So EIP being Ethereum improvement proposal. We actually did an episode a while back on that whole process and the governance around it. But so you just defined this, the elastic block size proposal. So would you, you would say that this particular proposals is, is that the EIP-1559 is an elastic block size proposal? Hasu (00:42:51): So 105 was not implemented. But there was a second proposal, called flex cap that was actually more popular, but weirdly enough this was also before, like our time in crypto, but it also suffered from the same problem. Instead of paying with difficulty, the minus would pay by deferring. They would basically not claim part of the block reward for that block and that block reward would go into a pool. And basically that would be like a rolling 2016 block window that determines how large blocks can be. And if whenever, miners like withholds it or don't claim a block part of the block at what then the max box size goes up and if miners remove money from the pool and they claim it back, then basically the limit goes down. But this suffered from the exact same problem as BIP-105, because again, the miners need to be able to increase the block size immediately. Otherwise you have this collective action problem. Yeah. So this brings us pretty much EIP-1559 because 1559 it does not reference any of the Bitcoin proposals, but it is, it achieves a similar thing in a much better and more incentive compatible way as the Bitcoin proposal 102. Anna (00:44:17): So you think it, but it was probably influenced by that previous, like even though it was a different network, do you think a lot of the people who were thinking about this? Georgios: I don't think that's true. Anna: No? Georgios (00:44:26): So, so in all of our, like previous research in the EIP-1559, we never found any reference to any of the Bitcoin elastic block size proposals, which kind of highlights the segregation between the Bitcoin and Ethereum communities on how they should talk more to each other in order to not have overlapping words. Anna: They've reached the same conclusion in a way that had to go a long way around. Georgios: Not so much to the same conclusion, but more so that some, some discussions could have been skipped because they've already been done in the Bitcoin mailing list, but Hasu, could you explain to us in a few sentences, what is EIP-1559, and how it works? Hasu (00:45:07): Yeah. So yeah, EIP-1559, you have also a longterm gas limit. Gas is how block size is measured in Ethereum. It's not measured in the same term as in Bitcoin of 10 million gas per block. And this was recently changed, but we were ignored this for now. And you only have a short term cap of 20 million gas per block. And so this really means that like the, the block size can go up to 20 million gas per block and the miners can decide themselves the size of the block they want to mine immediately, but there's a fee they miners need to pay in order to fill these blocks. And this fee that just called the base fee, it changes based on the distance of the recent block size to the target longterm target block size. So you can imagine that there's now a fee that you need to pay as a miner and the miner then recoup this fee fully from the user. So as a user, you can just imagine there's no a fee that you need to pair. And the fee is no longer set by supply and demand, but it's set by the protocol. Anna: Does this just look like higher gas prices to people? Hasu: No, I don't think, I don't think so. Okay. You disagree? Georgios (00:46:29): Well, if the thing is, if miners keep mining blocks with more than the 10 million gas gas prices, indeed like on a national basis, they did, they do go... Hasu (00:46:39): The way about that. The way that the fee works is whenever the last block was above 10 million gas, it was larger than that. Then the base fee would increase for the next block. And whenever the recent blocks were below 10 million gas utilization, then the base fee would go down. So you can think of it like, like this. If there are a lot of blocks mined below the utilization limit, then the base fee would go effectly go to zero and then it costs, costs nothing to transact, same as it would in Bitcoin when the blocks sync on foot. But if we mine for a time blocks that are larger than 10 million gas, then the fee would increase in order to discourage transaction that demand and basically encourage miners to mine blocks again, that are smaller. So the utilization of blocks is always around 10 million gas in the longterm. Anna (00:47:38): I see, I think my question, I think that the misunderstanding that I just had was this fee, the word fee that you're using, this is the fee affecting the minor themselves. So the miner pays a fee in order to have access. So this isn't the fee that the end user... Hasu (00:47:53): It is, it is the same fee. So the fee actually gets burned. So it basically works like this in order to put a transaction in the block, the miner must burn a certain amount of ETH and that amount of ETH as determined by the base fee. And of course the miner doesn't want to, like, they don't want to put in any transactions that are not worth it to them. So they, you know, they only include transactions where the user actually pays that fee. Anna (00:48:21): A high enough. And, but it's, that's, that's the question is like, does the gas fee need to be high enough for them to then sink and burn that fee for them to actually do this action? Hasu (00:48:32): Yes. The protocol is sets the fee and the users need to pay this fee. And it does no longer depend on like supply and demand. Not at least not directly, but on the distance from the previous blocks to the target level. Anna (00:48:48): Got it. Yeah. Okay. This is, that was actually the connection I was looking to to better understand. Hasu (00:48:54): Yeah. So the interesting part here also is that the fee does not go to miners. No other blockchain does it pretty much, but the fee is burned. And that is necessary because if the miners got the fee, then they... Georgios: They would be able to add their own transactions in a block. Hasu: Oh yeah. Georgios: But with no cost. And that would result in them inflating like pushing the up the base fee because they would be creating full blocks at no cost because all the fees go back to them and then this would be bad for other users because they would need to pay a higher fee than they would be paying before. While with the base we've been burned. This means that if a miner tries to add fake transactions in the block, in an effort to prop up the block, that the base fee they have to pay for it. And there's no way for them to work around it. Hasu (00:49:51): Yeah. Georgios. Exactly. Right. If you have a minimum fee in the network, then you can't give the control over this minimum fee to miners. Otherwise they will just use it to jack up the cost for users by including their own transactions. So you really have to, you have to charge miners this fee and that's what EIP-1559 does by burning it. And that forces the miner to recoup the cost from the user. And this is also what this proposal could not be copied and implemented one-to-one on Bitcoin because Bitcoin relies on things going to miners to secure the network. But Ethereum does not, Ethereum can afford to burn the transaction fee because it has a permanent block reward or block subsidy, that woulld secure the network. Anna (00:50:48): So like, from, from the perspective of the user, like what is, what does EIP-1559 actually mean for them? Hasu (00:50:56): The scope of EIP-1559 is pretty large and it goes like way beyond the scope of these smaller proposals in Bitcoin. So first there's the mechanism. That is, that is if the world of the Ethereum community for some blocks can be larger, as long as others are smaller, this is this thing with reacting to burst demand. But that's pretty much where the similarity ends because you have EIP-1559 introduces a new way of how users even interact with the block space market in the first place. In Bitcoin, you have something called a first price auction. So users publish their transaction together with a bid for inclusion. When a block comes in and that bid is high enough to be included, then you get in, otherwise you might waive it. And it's, it's really pretty unintuitive user experience because outside of when, I guess outside of Bitcoin, people are not really used to bidding for something as simple as inclusion in a block. Hasu (00:51:59): And the way that EIP-1559 changes, that is you have this base fee that every user pays and the block, and it's the same for everyone. And the best fee is also known ahead of time for the next block. So you can quote the user a price. And if the user is willing to pay that, then unless there's like a burst of demand, the blocks will fill up, then this fee where always be enough to get into the next block. So it's way more similar to going on Amazon being quoted their price and buying it, than having to speculate how much others are going to bid. So it really removes some of that complexity there. So that is because the transaction fees are burnt. It uses Ether as the fee paying asset on Ethereum. And this is more important than it may sound because like all blockchains have this problem of, it's quite economic abstraction, where basically the, the main asset is, is abstracted out from the market in the sense that the users can pay miners in any currency they want. So for example, you, in Bitcoin, you could, if you have a transaction stuck in, you can use something called a transaction accelerator, and you can pay with PayPal to bump your transaction fee like this. Anna (00:53:26): Wow. Even after you've already submitted it. Georgios (00:53:28): Yeah. This is called the child pays for parent transaction. Hasu: It's actually, if it's just a transaction accelerator, then the pool would simply like, it would simply mine your transaction, even if it has a lower fee, because you paid the, like, you paid like 10 bucks on PayPal or whatever... Georgios: Because you paid the pool directly. You mean? Hasu: Yeah, exactly. So that's how that transaction accelerators work. Yeah. But I mean, if this happens on a large scale, then this would be really bad for the native token. And in the example, like in the case of Ethereum of any asset affiliates, it's bad because anything that's or any asset, and yet for a business that has a block subsidy, this, it prints this asset that then gives to miners. And if the less this asset is worth than the less of can spend on security. So Ethereum really wants ether to be worth a lot. Hasu (00:54:22): So basically it has to print less ether in order to secure the network. And this is what the fee burning gives you. It ensures that fees can only be paid in Ether because the miners need to burn Ether in order to process this transaction. And finally, I mean, we already cover this a lot, so keep it very short, but it untangled its network security from transaction fees, or this is something that Ethereum does generously. So Ethereum has like a permanent block subsidy that pays the minor. Some gives them an incentive to move the blockchain forward and stabilize as consensus. So they, they really don't need these additional transaction fees to subsidize miners. This would just mean overpaying for security, if the lock subsidies already enough. So they can just say, Hey, okay, maybe 2% per year, or maybe 1% per year, it's enough to pay miners. And then if there are any fees on top of that, and we just burned those, and we don't really know how high fees are going to be, but we don't need to. Maybe fees are like, maybe we burned 3% of Ether per year and pay minus 2% of Ether, then we'd have an effective, like there would actually be less Ether year after year. So that is also possible. But... Anna (00:55:41): Is that good or bad? Does it matter? It's like, is this a good thing? Hasu (00:55:46): I think that's a good thing. It's basically like paying Ether as a dividend, but it works like stock-buy asset, for example, that got a lot of attention and stock-buy assets are... like they are similar to just paying a dividend. Okay. So if you have an asset that there's a force or like a party out there that buys some other asset every year and then burns it, then that's good for you because it's like a constant bid in this market. That's why I really like, yeah, yeah, EIP-1559 personally, I mean, I like all of those things, but I think it's great that how the Ethereum community like values, consensus, stability, and has this like permanent block reward, but it doesn't mean that like they there's higher inflation than in Bitcoin, just because you don't know how much fees are going to be burned. Georgios (00:56:38): So how so, so far you did us a walk through from Bitcoin proposals. Now we talked about EIP-1559 in the context of Ethereum, but I'd like us to go back to Bitcoin. And I know that you have some ideas last proposal in the works which you could perhaps share some details with us. Hasu (00:57:02): Yeah. So all of the blocks like elastic blocks size mechanisms that we discussed, including the ones on Bitcoin, they're always focused on preserving fairness and like serving burst demand in the network. And those are two of the three reasons that we covered, why blocks can't be too large, but they never covered the third one, which is then we need sufficient fee revenue, at least on Bitcoin. So Ethereum, is immune to this, but Bitcoin isn't because of how it is set up. And that's why like we, you and me H have been looking for like only a brief period so far, but looking at dread different kind of elastic block size mechanism that would selectively lower the block size instead of increasing it to satisfy this condition that the Bitcoin network must be in permanent congestion. And the idea is to observe fees paid to miners. And if that is below a certain level and the protocol would lower the maximum block size to slightly undershoot, the observed demand to transact. And that's how we would create congestion and ensure more heavier level of fees to miners, Georgios (00:58:20): The way that they, I thought about, Hasu, you should kind of embrace congestion as a good thing, rather than trying to remove it from existence. You have to have healthy congestion in order to have a stable chain. And that is how we want to kind of target design your mechanisms around. Yeah, Hasu (00:58:41): Yeah. And this this mechanism would be compatible with other mechanisms that maybe at burst demand. It just also observes that like there's a minimum level of congestion that like, if there's a lot of demand and fees are higher than they need to be in order to pay for security, then the block size could still increase on the upside. But if the fees are too low, then it could also increase on the downside. And that is really the new part of this mechanism. So we briefly touched on this miners can't really charge what we would call were optimal for the prices. They can't set their own prices. Because when they don't include a transaction with a few that they don't deem high enough, then there's always a next miner who might include it. And this is really good for censorship resistance in Bitcoin, because basically it puts the number of miners that need to collude with each other at a very high level before they can permanently censor you, if like a smaller number of minor censor you then the most they can do is delay or transaction. Hasu (00:59:48): But the downside side of this is that they can't set their own prices. So this would simply be a mechanism to break this collective action problem where the one miner can't set a minimum fee for users without another miner, like then coming in and farming these transactions for themselves. We asked the very early with this and there might be problems. So we haven't yet discovered. So, I mean, if anyone wants to collaborate on this idea, then please reach out to Georgios or me, because we would love to find more people who are interested in this. Anna (01:00:27): Oh, nice. I have this question of like, what's next for both of you, but I feel like you've answered at least part of what's next. Is there anything else that you're working on that we should keep our eyes open for? Hasu (01:00:40): No, I mean, I write day, like I write an article every other week for Deribit Insights. So if you wanna, if you wanna follow that then yeah. Usually it's enough to follow me on Twitter and we also launched a podcast recently and it's called "uncommon core" podcasts, I do it with my, with, with Su Zhu who is a, well, I might call, author in Deribit Insights. Yeah. So I'd love if you could check that out. Anna (01:01:06): Very cool. Thanks for sharing that with us and Hasu really nice to meet you. Thanks for coming on the show. Hasu (01:01:12): Yeah. It's one of my favorite podcasts in crypto, so happy to be invited here. Thanks for having me. Anna (01:01:20): Yeah. Thank you so much for walking us through all this and Georgios. Thank you for returning and guest-hosting slash guest-being again. Georgios: Always a pleasure, Anna. Anna: All right. And to our listeners. Thanks for listening.