0:03 Paul, Obi, you guys around? Just checking. All right. So anyway, I'll introduce our moderator for – sorry, just give us a minute while we get set up for the next one. 0:33 Thank you. 1:03 Thank you. 1:33 Thank you. 1:34 Okay, guys. Thank you. Thank you all for waiting. 2:05 So we've got our next panel, and I will just introduce our moderator, and he can introduce everybody else. So Aaron is a long-time Bitcoin journalist. It's interesting. If you look on his Twitter handle, it's actually OG at Bitcoin Magazine, so take that for what you will. 2:24 He's well known for breaking things down in a very accessible way, and please, everyone, welcome Aaron, and he will introduce everyone else on the panel. 2:47 Hello, hello. All right, there we go. 2:50 All right. Hey, everyone. 3:00 Yeah, so this is the panel on sidechains and L2. Lisa just gave a great introduction on what that actually means, so I don't think we need to go over that. 3:08 I will let you guys introduce yourselves, actually, as opposed to what Stefan was promising you. Let's start from the right, or your left, Lisa. 3:19 Hi, everyone. I'm Nifty Nye. I work at Blockstream on Core Lightning. 3:24 Hello, everybody. My name's Obi Noisu. I am one of the cofounders of Fedi, which is powered by FediMint. 3:32 Hi, my name... Hello. Okay, there we go. My name is Paul Sztorc, and I'm behind BIP300/301, which are about sidechains. 3:44 I'm Adam Back, and cofounder of Blockstream, which does a few Layer 2 things, some early Fedi stuff, some Lightning stuff that Lisa talked about, and also Liquid, which is a different sidechain variant to what Paul mentioned, which is a Drivechain. 4:02 All right, so the topic of the panel, as mentioned, is L2 and Lightning, which are two very big topics in their own right, and we have four very knowledgeable panelists as well. 4:16 And we only have, like, 25 minutes, so the way I figure we're going to do this is we're going to sort of zoom in on one angle specifically, which I think is an interesting angle, because I know there are some different views on this topic. 4:33 So that's scaling, because other angles we could take is privacy or smart contracts, but scaling, I think, is one that there's some divergent views on. 4:44 So on that note, I'd like to start with Paul, because I think Paul has the most alternative view of anyone on this panel, maybe, about scaling, because you don't believe that Lightning is actually a scaling solution. 4:58 Am I misrepresenting your view? 5:00 Well, that's a little bit of an extreme way of putting it. 5:02 I mean, I think there's no – Lightning doesn't really help with onboarding, so that – to onboard to the Lightning network, you need a Layer 1 transaction, and that – once you're onboarded, it helps tremendously, but the – you know, you have to onboard someone before they can do anything else, so it's kind of like the first hurdle to jump. 5:22 And that is why – this is the main difference between the sidechain scaling strategy and the Lightning scaling strategy, so that's why maybe I mentioned it to you, and maybe the view sticks out especially, but I think this – part of the issue with the sidechain scaling topic is that right now, people think of Lightning as kind of like a scaling messiah, that it will fix everything if you just don't think about it too much. 5:47 And if you really talk to the big Lightning experts, they are the ones who try to pour some cold water on that, and so the question is what do you do instead, and this is the answer. 5:58 So can you break down why that is? So what is the onboarding issue for people that don't know this? 6:03 Well, every – the Lightning network is made up of channels, and every channel is a multisig output on Layer 1, so you must broadcast something into the blockchain that has the output at some point, and so that will take at least like 30 or 40 bytes, 43 bytes if it's taproot, I think, so per output, and so that number is greater than zero, so it means every time you want to onboard a new person, you need more Layer 1 bytes. 6:32 And those are the Layer 1 bytes. The whole point of this is to get stuff off of Layer 1, because Layer 1 has the fixed block size. 6:39 Yeah, essentially for each person that wants to get on Lightning, you need a transaction, and the number of transactions that Bitcoin can handle means that would take decades to onboard the whole world, right? 6:50 Yeah, in practice, it would take a lot more than 43 bytes per onboard because you need usually about one input per output, you know, usually. 7:00 Lisa, is this something that Lightning developers indeed agree with? Are there solutions for this? 7:05 I mean, I think that's correct in that, like, so we were talking earlier about, like, multisigs, and the Lightning one is a 2 of 2, right, which means that every time you want to have a Lightning relationship, so to speak, with another peer, you have to create an on-chain transaction. 7:23 So I think that's pretty accurate. I think that there's probably some ways that we could change the protocol in the future that maybe makes that a little less restrictive in terms of how many on-chain transactions you need to establish new channels, but that's all, like, kind of future research stuff. 7:40 So I think in today, in terms of the protocol, I think that's fairly accurate, yeah. 7:45 So then, do you want to weigh in on that, Adam? 7:49 Well, I was going to say that there doesn't seem to be a silver bullet so far, though we haven't yet talked about FETI, which is another trade-off. 7:56 So everything has trade-offs, and I think you can sort of benefit from extra layers, so you can have Lightning on top of Liquid, which is itself a layer 2, so kind of a layer 3, and that would kind of reduce this channel onboarding challenge that each and every channel, this is Paul's point, right, that each and every channel that is in the Lightning network corresponds to a transaction on a Bitcoin network, 8:25 and if you're unlucky, you might need to close it and reopen it or splice it. 8:29 So you want the channels to be reused a lot, and you want it to be rebalanced, and that's improving over time, but it's still, you know, like, if you want billions of people on there, it takes a while to get a billion transactions through the Bitcoin network, like, years, right? 8:43 So the other way to do it is say, well, let's use Lightning channels on top of Liquid, and the core Lightning implementation that Lisa works on at Blockstream and, you know, some open source contributors as well, you can, it's had support for Lightning on top of Liquid for a number of years now, and a lot of people don't realize that Lightning can work on top of other UTXO things, right? 9:03 It could even be shared across multiple UTXO chains. 9:06 So the point there is that Liquid itself is a form of scaling because it has UTXO space that's not on the main chain. 9:14 People can buy UTXOs on Liquid without there being a corresponding UTXO on the main chain, and so there's an opportunity to scale there, and I think it's reasonable that you can get a certain amount of scaling within limits on Liquid or Drivechains 9:30 because the point for a blockchain is that people need to be able to verify it, and that's why the Bitcoin blockchain is kind of optimized for verifiability and compactness. 9:40 But with a sort of opt-in layer 2, you can push the envelope, let's say, you know, uses 10 times as much space or 20 or something where it's still reasonable for a power user to catch up and keep up. 9:51 If you go too far, it loses the point. 9:53 If you can't verify it, it's not really a blockchain. 9:56 Now, the FEDI protocol is not a blockchain, and so that has different tradeoffs but has possibly improved scalability as well, so we should talk about that too. 10:05 Yeah, I think at scale, if you can get a global scale with billions of users, you're correct. 10:11 There is a limit to the Lightning Network. 10:13 However, sorry, my voice went yesterday. 10:17 All right. 10:18 So I'll stay very relaxed so it doesn't get worse. 10:22 But if you consider a Lightning Node as a person, you're right. 10:28 But if you consider it as a group of people, then you can scale. 10:32 So each Lightning Node needs an on-chain transaction. 10:37 However, a Lightning Node could represent tens, thousands, even hundreds of thousands of people, and that's what we are doing with FEDI and the FEDIMINT protocol. 10:49 Each federation can have one or more Lightning providers providing access to them. 10:56 Now, again, at global scale, right now, most people acquire their Bitcoin by buying it. 11:02 A few people acquire their Bitcoin by being gifted it by someone else, and very few acquire it by earning. 11:08 But at global scale, the vast majority of people will earn it, and a few people will get it gifted to them by friends and family, and then a very few people will buy it. 11:18 And at that scale, most people will be acquiring their Bitcoin over the Lightning network. 11:23 Only Lightning gateway providers will be the people who are making on-chain transactions. 11:28 So in this world, and I think this applies to both FEDIMINT and sidechains, would it essentially mean that most people would just never touch the main chain? 11:39 Is that the vision, so to say? 11:43 Yes, I think so, absolutely. 11:45 The sidechain conception – and I'm not really trying to say like anything is doomed or anything is clearly much better than something else. 11:52 That's not really what I'm saying. 11:54 I do – the sole spectrum idea, the tradeoffs idea is the key idea that people are very different, and each transaction is very different. 12:02 Like you may have some transactions that need to be private or need to be very censorship-resistant. 12:09 And then two hours later, you may make the coffee transaction that may not – but one could be on the large block sidechain or whatever, and the other could be on something else, Lightning network or the main chain. 12:23 But I think the spectrum idea and the tradeoff idea are key. 12:28 The vision with the sidechain onboarding is that someone – one guy can just send lots of coins over from layer one to layer two in one transaction over there. 12:38 And then since they have 10,000 coins over there, you can onboard people directly to layer two. 12:45 And that is a lot like when you open a – I don't know the European equivalent, but we have like Wells Fargo. 12:50 We have like commercial banks in the United States, and those banks are all part of the Fed, and then the Feds, they all have Bank of International Settlements or something. 12:58 When you onboard or you open a checking account, you don't get an account with the Fed or an account at the Bank of International Settlements. 13:06 You only get the account at Wells Fargo or whatever it is, Bank of America. 13:13 I remember – Adam, this is a question for you. 13:17 I remember that a couple of years ago during the scaling debate specifically, developers were claiming or they didn't think that sidechains could be a scaling solution at all because in the end it's still a blockchain and it has all the limitations. 13:32 Has that view changed or is that still something you think is accurate? 13:38 That seems like something you would disagree on then. 13:42 I think Paul and I are on the same viewpoint on this, which is that it does scale a bit, but you don't want an enormous blockchain where only data center located nodes that are very expensive, thousands of CPU cores, gigabits of bandwidth can keep up because that's a high availability database. 14:03 It's not a blockchain. 14:04 It's a blockchain when power users and individuals can verify it. 14:09 Then you're talking about what is the investment or the maintenance cost to stay on the network, to verify everything and to catch up. 14:17 For Bitcoin, that's very low. 14:19 What we're saying in the sense that a sidechain or Drivechain could be a partial scaling solution is that we could probably tolerate being 10 or 20 times higher and still fit within the bandwidth envelope and the desktop CPU of modern equipment. 14:34 Liquid has that characteristic, in fact, because its blocks are the same size as Bitcoin, maybe a bit bigger if fully utilized, and they're 10 times as often. 14:43 It's a bit bigger and it generates a lot of signatures because of the confidential transactions, a lot of crypto loads, so it's more CPU heavy. 14:50 It could be pushed a bit further, but I think if you push it too far, if nobody can verify it, it stops becoming a blockchain. 14:57 You see this with some altcoins that basically the number of nodes is shrinking and in some cases it dropped to zero and they lost some history and clearly just not a blockchain. 15:05 Or if it's only running in data centers, it's also not really a blockchain because you can have accountants auditing books from databases that live in central servers and that's going back to pre-Bitcoin. 15:17 I think it just needs to be verifiable to a reasonable number of people and you can have some of the decentralization. 15:25 So less than Bitcoin, right? All these trade-offs are always a little bit less than Bitcoin. 15:29 Yeah, I guess the question would be why use a big block sidechain at all instead of, for example, Federmint, which is more centralized, but a big block sidechain would be centralized as well. 15:40 I mean, so not to speak for Obi, but I think the point with the Federate, Trummy and Mint is it's making different trade-offs. 15:50 So all of these, the main chain is the most secure, doesn't have so much privacy and isn't so scalable. 15:57 Then a sidechain can be a bit more scalable if it has confidential transactions, which Liquid does, then it has a bit more privacy, but it still has some scalability limits. 16:07 But you can audit it, so it's a blockchain, whereas the Federmint, the Mint, it's not auditable, but it's extremely private, like it's more private than confidential transactions. 16:18 And those things are sort of side effects, right? You get the privacy, but the side effect is you can't audit it. 16:23 Nobody found a sort of efficient, scalable way to audit that kind of crypto. 16:29 But on the plus side, it's scalable, and you can't audit it, so you have to choose whether that... 16:33 So you basically have to use the right tech for the right trade-offs for what you want. 16:37 Do you both agree on this? Are these the trade-offs? 16:39 I will echo that. Privacy is also very important for us. We think privacy is paramount, at least within your community. 16:47 You don't want your neighbor or your brother or sister to know your exact wealth. It can lead to negative externalities. 16:55 So by leveraging the Xiaomi and eCash protocol, we have the potential for some of the best level of privacy you can imagine. 17:06 And it also has the benefit of being able to provide what we call effectively layer-free scaling. 17:13 There are always trust trade-offs with any model, including sidechains and Federmint. 17:20 It just depends on who you are looking to trust. 17:23 And it's just important with all of these systems to be very open and honest that there is always a trust trade-off. 17:30 Do you want to weigh in, Paul, or do you disagree? 17:32 Well, I think I definitely agree with basically everything that Dr. Back said. 17:41 The unfortunate thing is if you defend the large block sidechain, it makes it look as though you're defending the large blocker philosophy, 17:48 which is really not at all the case. 17:50 But it's just unfortunate that it resembles that to such a great degree that you kind of look like a guy saying that there should be... 17:56 And even I've done math, like napkin math, about what does a one-gigabyte node cost, but that's obviously going too far. 18:03 But it's worth just doing the napkin math to point out that you really only need... 18:10 You could have something like 10, 11, 12 sidechains that had... 18:13 Maybe if you pushed the envelope to 100 megabytes or something, which since it's now 4 megabytes, it's only 25 times larger, 18:22 you could really hit the entire planet's transaction usage, and you could onboard all those people tomorrow. 18:28 So that's just an idea of one extreme, if you pushed it to the exact extreme. 18:35 And I just think that's something people should keep in mind, because all of these other things have their own trade-offs and flaws. 18:42 I'm not sure. I don't know about with Fediman, like the user's going to open up the software, 18:47 and then they're going to start to choose which group should you join, and there'll be this big list of groups. 18:52 I think most people would just be like, what? And then close the software right after that happens. 18:57 No, I think that comes from a sort of centralized thinking mindset. 19:03 You have to understand that people will join groups based on their existing social second-party relationships, 19:11 so friends, family, church, or work. 19:16 So the way you will find them is you would talk to your friend and say, hey, where do I buy Bitcoin? 19:23 And that friend would, instead of saying, go to this exchange that I really don't want you to go to, and I know it's bad, 19:31 and I'm also not going to tell you, sort of figure out first-party custody because I realize you're not ready for it, 19:37 just download this app and connect to this, scan this QR code, which is my federation that I'm already a member of, 19:45 and it's made up of our friends. That's how we find it. 19:49 So there's not this centralized database in the cloud. It's hundreds of thousands of relationships. 19:55 I mean, it might work. People have Discord servers, so it might work, but I don't know. 20:00 You just talk to a friend. You don't need a Discord server. 20:03 I'm just saying that's an example of something where people make lots of different little rooms and groups, 20:08 but I don't know if it's the same for your lives. 20:11 Let's zoom into Lightning a little bit more. So we've discussed the onboarding bottleneck. 20:17 Are there other scaling issues? I guess this is a question for Lisa. 20:22 The onboarding, is that the main one, and what are other scaling bottlenecks? 20:27 Yeah, I think the onboarding one is probably one of the biggest ones. 20:31 I think the other scaling problem, so to speak, with Lightning is, given the current protocol, 20:40 if you want to be on Lightning and you want to be doing it in a way that's self-sovereign, 20:47 which means you're not depending on a service to run the Lightning node for you, 20:51 now you have to be keeping a server online all the time. 20:55 So I think there's definitely a scaling issue in terms of technical capacity or capabilities 21:02 in running a Lightning node. That's something at Blockstream we're working on. 21:07 Greenlight, which hopefully will help with that, because that helps. 21:11 Basically, we're building a protocol or project that will let you still main sovereignty. 21:19 You're going to still be able to hold your private keys, 21:22 and you're going to offload a lot of the infrastructure requirements 21:25 or the burden of running infrastructure to Blockstream, 21:28 who will help keep your node up and do watchtowers and keep the data, etc. 21:34 I think that looking past this, every new relationship on Lightning requires an on-chain transaction currently. 21:44 There's currently a lot of overhead in terms of keeping that node online, 21:50 because it is, to some extent, like a hot wallet. It has to be always available. 21:54 Yeah. A quick note for the organizers. I don't have a clock here or anything, 21:58 so I assume someone will wave at me at some point if we're out of time? 22:02 Or we'll just keep going forever. 22:03 Yeah, we can do that. 22:05 But one thing I want to do is... 22:07 Go on. 22:08 Yeah, so one thing that I don't think we really talked too much about, 22:12 for those who aren't super familiar, one of the cool things that the FedEvent proposal, 22:17 my understanding is the idea is you create a community bank. 22:22 I was talking earlier, you get these eCash tokens. 22:26 Those eCash tokens are only good at your local bank. 22:30 I think Paul was mentioning Wells Fargo earlier. 22:33 So you would have some Bitcoin you deposit into your local FedEvent 22:37 with all your besties, maybe it's your church group, 22:40 and you get some church group tokens. 22:44 The cool thing is Lightning then creates this tissue. 22:49 I don't know, what do you call it? 22:51 Connective tissue for the wider ecosystem. 22:54 So there's this cool opportunity to link these different Layer 2 technologies together. 22:59 So you could have a local balance at your local FedE cash bank, 23:06 but you'd still have access to the rest of the Bitcoin payment network 23:11 because you could use those tokens to pay a Lightning invoice, so to speak. 23:16 So I think that if you look at each of these things individually, 23:19 they each have their drawbacks and things that they're good at 23:22 and things that they're not so good at. 23:24 But I think there's this new dawn coming in Bitcoin Layer 2s, 23:31 which is we have these things like Liquid and FedEvent, 23:34 which are federations and different ways of doing accounting. 23:37 And then what if we can connect them all together 23:39 with these cool Lightning channels? 23:41 And so I think we're going to see in Bitcoin and Layer 2 space, 23:46 not like one scaling solution which fits all the problems, 23:49 but I think we're going to start seeing more interconnectivity 23:53 between how do we link all these little multi-seg projects together in cool ways 23:57 such that we can all transact with Bitcoin 24:00 and the unit of account across the entire ecosystem will be in Bitcoin 24:06 and you'll be transacting in Bitcoin. 24:09 But the method and the accounting systems that we're using 24:12 and the technology will kind of be, hopefully, 24:15 like a hybrid of a bunch of kind of different protocols 24:18 that have different trade-offs and stuff. 24:20 Basically what Lisa said. 24:25 But I mean, yeah, when we first looked at FedEvent, 24:31 when I first saw it, I thought it was an incredible new form of custody 24:37 where you had third-party, what I call stranger custody. 24:40 You store it with a stranger who may go off and gamble your money 24:43 or lend it to people who will gamble your money, 24:45 like regulated exchanges. 24:47 Or you've got first-party do-it-yourself custody, 24:50 which is the best form of custody you can have, 24:52 but for many people it's currently out of technical reach from them 24:56 or economic reach. 24:58 And this is this form of collaborative community custody. 25:01 The only closest example is Galoi. 25:04 But the more we looked at it, in fact, I remember I was at Oslo Freedom Forum 25:10 and I met up with Rene Picard 25:14 and he was telling me some of the scaling challenges he saw in Lightning. 25:19 But we realized in that conversation that there was the potential for federations 25:25 and this world where there are hundreds of thousands of federations out there, 25:30 FedEvent federations, 25:32 where the onboarding problem is solved at scale 25:35 with most people, users, receiving their first Bitcoin through earning it, 25:41 which is going to be the norm at global scale. 25:44 Most people will earn, they won't buy, as is any other world reserve currency. 25:50 And in that scenario, the people who need to settle, 25:53 because the transaction for you, whether it's internal to a federation 25:56 or to another federation or to someone with their own sovereign Lightning node and wallet, 26:03 appears to be the same. 26:05 It just looks like a Lightning transaction. 26:07 The federation and the Lightning gateway providers handle all the details. 26:12 But what happens is the Lightning gateway providers, 26:16 the people who are providing access from the federation to the rest of the Lightning network, 26:19 are the ones accruing large amounts of these Zcash tokens in different federations 26:24 and they're the ones who have to settle on-chain to rebalance. 26:28 So it's only the large, experienced Lightning gateway operators 26:31 who are the ones who are incurring that onboarding cost, not the user. 26:35 And that makes sense at global scale. 26:38 Yeah, we have about five minutes left, I think, and this will be a question for all of you. 26:44 But I'll start with Lisa. 26:46 What protocol change would you really like to have on Bitcoin to, in your case, presumably help Lightning? 26:53 Yeah, I do have a favorite. 26:55 I'm really excited about this new protocol called L2. 26:59 It's not new, it's been around since I've been in Lightning, as of like four years ago. 27:03 But in order to get this, we need a base layer, a layer one change for something called APO, 27:09 Any Previous Output, it's a Zcash change. 27:12 So I think that it would be really awesome, not only for Lightning, but for other protocols. 27:17 Like we saw Revolt guys yesterday, I think it helps them. 27:20 I think it helps some state chain projects. 27:22 So my layer one would love to see is the Zcash Any Previous Output APO stuff. 27:31 Right. Obi, you can make one change to Bitcoin. 27:34 What would it be? 27:36 No changes. Right now it does what we need it to do. 27:40 Yeah, it's a good answer. 27:42 But anyway, since I'm the author of BIP300, I have to say that. 27:46 So it's a question. 27:49 Is there something you can explain in a minute, you think, what it is? 27:53 Well, I don't know if I can explain it in a minute. 27:56 But basically, it lets you add, remove sidechains and send coins to and from them. 28:03 But the sidechains are all ignorable. 28:06 So that is the scaling comes from the fact that there would be like 10 sidechains or whatever. 28:12 That would have maybe a larger block size. 28:14 But you would tend to only use one. 28:17 You would use like the Europe one or US East or something. 28:21 And so you could ignore the other nine. 28:23 That is the sort of the strategy. 28:26 So that's it in a nutshell. 28:29 Adam, one change to Bitcoin. 28:32 Simplicity, which is next generation smart contracting upgrade for Bitcoin. 28:38 Would that be a protocol change? 28:40 It would be a soft fork. 28:42 Oh, OK. I didn't know that. 28:44 The point is it could be the last soft fork because Bitcoin becomes self-extensible with that. 28:50 And so the two things that Paul and Lisa were talking about could be directly implemented in simplicity. 28:56 I think even confidential transactions could be implemented in simplicity. 29:00 You can implement a lot in simplicity. 29:02 And then the sort of efficiency drive becomes a kind of upgrade to make the node more efficient to handle commonly used extensions, basically. 29:14 But it's done in a way which fits in with UTXOs. 29:20 It's a similar model. 29:22 It builds on the current model. 29:24 And it's sort of formally secure. 29:28 It has formal security semantics so you can get good confidence in the security of the system through that. 29:34 So people want ossification. 29:36 So I think simplicity is the best path to ossification. 29:39 And there's an old Satoshi quote somewhere on Bitcoin talk that says he added the contracting system to Bitcoin at all so that he could freeze it so it would never need to change after it was launched. 29:51 So it turns out he was wrong. 29:53 People who have been involved in Bitcoin have added quite a few opcodes since then. 29:57 But simplicity finally makes that realistic, I think. 30:00 And so hopefully we'll get that into Liquid relatively soon. 30:03 And it takes many years for things to make their way from Liquid or other proposals into Bitcoin. 30:08 Like Schnorr was in Liquid probably five or six years ago and finally last year in Bitcoin. 30:14 So something like simplicity coming to Bitcoin would be pretty exciting to me. 30:20 Just interesting. 30:22 I didn't mention but with FediMint we have a module-based capability where you can add modules of functionality. 30:30 In fact, all of the base functionalities are modules in the system already. 30:35 Multi-sig Bitcoin, Charmin eCash. 30:38 And one of our co-founders, Justin Moon, made a FediSimp adding simplicity functionality to FediMint. 30:49 And that took, I think, an afternoon at a hackathon. 30:54 Do we have time for a follow-up question? 30:56 I think so, right? I'm not being waved at yet. 30:58 All right, so we have Simplicity, BIP300 and Anyprevout, right? 31:02 Why don't we have it yet? 31:04 Let's go the other way around. 31:06 Why don't we have Simplicity? 31:08 So we don't have Simplicity yet because it's still in development and it's security first. 31:12 And I think generally Bitcoin is cautious and careful about making changes at the base layer. 31:20 It's much easier and faster to innovate on layer two. 31:22 So that's why FediMint and Lightning can make changes more permissionlessly without needing core changes. 31:31 And Liquid can innovate a little faster. 31:33 We've got a few iterations there and we should get Simplicity there first. 31:37 But why don't we have BIP300 yet? 31:39 One reason is that the protocol is ossifying. 31:42 You can just look at how many soft forks there were per year in the past. 31:47 A long time ago, there was two a year on average. 31:51 But now there was only SegWit, which took a very long time, and Tapper, which took twice as long. 31:57 So already it's slowing down. 32:00 I think with BIP300 in particular, it really is just the misconceptions around the idea. 32:06 The idea is very old. 32:08 I published it in November 2015. 32:10 In the post, I wrote about how it would be misunderstood, and I was right. 32:14 And people just do not grasp the idea that you can just have something with a larger block size for free 32:23 that doesn't increase any of the Layer 1 node costs or node requirements. 32:28 Or that you can just... 32:30 Maybe it seems too good to be true or something. 32:32 But I think people don't understand merge mining. 32:34 People don't understand sidechains. 32:36 So I think you can't have consent for something unless it's informed consent. 32:41 And so people need to really understand what the idea is before they can agree to merge it into Bitcoin Core. 32:50 So that is the real bottleneck, I think. 32:53 Do you agree with this, by the way, Adam? 32:55 Is this the main reason? 32:57 Can't you see a different version where I published this thing in November 2015, 33:02 and then everyone was like, oh, that would just fix the block size war, 33:06 and then everyone kind of coordinates it? 33:08 Or do you think that's a complete delusion on my part or something? 33:10 I mean, I think it's... 33:12 I mean, I think that Bitcoin has... 33:17 The opcodes that get added as soft forks tend to be simple and self-contained and win-win. 33:25 So I think Bitcoin is slower and has more difficulty bringing things in with tradeoffs. 33:32 Well, that's true. 33:34 But you know that SegWit doesn't really apply for... 33:36 SegWit was very different. 33:38 It changed the entire structure of the block. 33:40 It was a mandatory block size increase. 33:43 So SegWit is kind of like the hair in the soup of that premise. 33:48 I agree with that premise. 33:51 And then Tampered is also not really an opcode, right? 33:53 That's not just like check-lock-time-verify or something. 33:57 I think the other thing is that there has to be, kind of building on what you said, 34:00 there has to be some kind of excitement and demand from the wider community. 34:06 So people get excited about something like Lightning, 34:08 and then they want the features that Lightning needs. 34:10 And it's also the open-source contributor phenomenon 34:14 where people will work on what they're excited about 34:17 or what other people seem to be excited about. 34:19 So maybe there needs to be some kind of community demand for it. 34:24 I think Drivechains and sidechains that are more peer-to-peer are pretty cool. 34:29 But for whatever reason, that's not something that's progressed as fast 34:34 and arguably could have been more important or useful than, let's say, Taproot. 34:39 We've got to work towards the end of this panel. 34:44 Okay, Obi, you didn't want any changes to Bitcoin, right? 34:47 So you should be happy. 34:49 But there is a point here. 34:51 There's a trade-off between the need for ever-greater scrutiny on changes 34:58 to what is going to be the next world reserve currency at the base layer. 35:03 And that's going to continue, and it's needed. 35:05 But at the same time, we have to recognize that there's a desire for experimentation and so on. 35:12 And a lot of the challenges are how do you sort of square that conflict? 35:16 The approach. 35:18 One approach is with something like FediMint and federations 35:22 is that effectively you have this sort of sharded opt-in layer-free. 35:28 Each federation is able to add any modules they want. 35:32 You don't have to have everyone implement a module. 35:36 And so you have alternate levels of experimentation. 35:38 You as a group of friends could set up a module adding a Drivechain as a federation 35:45 and see if there's demand. 35:46 If there's demand, other federations will take it. 35:50 And over time, if it becomes a large percentage of people who have chosen to elect to add that, 35:55 that allows you for the community to communicate the fact they find that valuable. 36:00 And then it could get more credence as a layer-one implementation. 36:04 Right. 36:05 Okay, last question for Lisa. 36:07 Why don't we have any prev out yet? 36:09 What are we waiting for? 36:12 I think, you know, changes to the Bitcoin core require consensus. 36:16 And there are a few things that happen with APO. 36:19 My understanding is like, so APO, I don't know if it's proposed. 36:24 Well, L2 is proposed by their three co-authors on the paper. 36:27 I don't know what the relationship between that and L2 is, so to speak. 36:31 But one of the main kind of proponents behind the APO push is Christian Decker, 36:36 who works at Blockstream. 36:37 And my understanding is he didn't want to, it would have been, we would have APO 36:43 if APO had been bundled with Taproot, right. 36:45 So that was one potential way that we could get APO. 36:48 Christian Decker, who is kind of like the main force behind a lot of the spec proposal for APO, 36:53 decided that he didn't want to have contention in terms of coming to consensus 36:58 about Taproot around the APO project. 37:00 So I think it's like, there's a little bit of political scheduling, so to speak, 37:05 around how we were going to build consensus around this particular update. 37:09 So we built consensus around Taproot that just went in last November, right, 37:13 got activated. 37:14 And so APO is like one of the things that I really hope gets into Layer 1, 37:19 you know, Bitcoin core at some point. 37:21 But that requires consensus, which requires people at the protocol layer 37:26 like championing it, kind of like I'm doing right now, 37:29 and people learning about like what it adds, why it's cool. 37:34 And so, yeah, we don't have it yet because we haven't reached consensus 37:38 that it's a thing that we all want and need. 37:40 Part of the way we reach consensus is by talking about it. 37:43 Yeah, so I think it'll come eventually. 37:45 All right. 37:46 Well, that's our time. 37:48 Please give a hand of applause to our panelists. 37:50 And thanks for being here. 37:57 Thank you, everyone, for that panel. 37:59 Aaron, Adam, Paul, Obi, Lisa, fantastic panel. 38:02 Now we've got a coffee break until 12.20, 38:05 so I'll see you guys back in here at 12.20. 38:07 Thank you. 38:17 Thank you.