0:05 Welcome to Drivechain Twitter Spaces. 0:13 We are excited to have another conversation 0:17 with our many followers and fans 0:20 regarding Bitcoin Improvement Proposal 300 and 301. 0:27 There has been a lot of excellent 0:29 contributions to the discourse on these topics lately from Fiatjaf, Moon Settler, and many others 0:37 who have 0:38 analyzed the technical details of 0:41 Drivechain and 0:43 commented on it. 0:46 The discourse on Drivechain evolves 0:51 each year as the fee market rises and falls as 0:57 the discussion on scaling Bitcoin 1:00 evolves and develops and 1:04 there's also 1:05 important conversations about the potential to bring privacy protocols to Bitcoin. 1:10 Adam Back of Blockstream, from time to time this year, has tweeted about the exciting potential to have a Zcash 1:18 based blockchain 1:21 existing as a Bitcoin sidechain 1:24 where the Zcash 1:27 fungibility technology 1:28 would be present but the native unit of account would be 1:35 Bitcoin and that's the the win-win opportunity with Drivechain is to have 1:41 the technology that currently only is available in a peer-to-peer format on altcoins 1:47 copied to Bitcoin sidechains so that the Bitcoiners can benefit from the technology of 1:55 the altcoin 1:58 but using Bitcoin's unit of account. So the relationship there is, as 2:04 Adam Back has tweeted, innovation maximalism with altcoins seniorage 2:10 avoidance. 2:13 Today 2:15 we expect to have a special conversation with one of our frequent guests, Moon Settler. 2:22 Moon Settler is an expert on 2:26 the technicals of Bitcoin and other protocols and 2:31 has tweeted and hosted Spaces and 2:35 he is expected to come today to chat about the topics of the day. 2:41 So we're looking forward to that 2:49 and we'll wait for him here. 3:11 You 3:15 Another item that I wanted to share with you all whether you're listening live or in the 3:25 in the on-demand option because these are recorded Spaces. 3:30 We have some listeners who listen on-demand. 3:33 I wanted to bring up a great tweet from 3:38 Mr. Brad Mills. 3:40 Brad Mills is a Canadian Bitcoiner and 3:45 very well known in the Bitcoin community for his intelligence and friendliness. 3:51 Brad has spoken with me probably 200 times or more on 3:57 social audio over the last 4:00 approximately two years 4:03 on many topics mostly within 4:05 mostly within Clubhouse, but also elsewhere here in Twitter. 4:14 So we're gonna share this tweet of his and chat about it. 4:21 There it is 4:24 in the nest. 4:27 This is a tweet I found when reviewing Brad's 4:30 tweets in the past. 4:32 Brad wrote 4:34 Down the line when BIP300 is activated we can have more trustless sidechains. 4:48 And he continued 4:50 There's a lot of things being discussed in Bitcoin right now 4:53 to add extra functionality without 4:57 adding shit coins. 4:59 Jeremy Rubin has some stuff up his sleeve as well. 5:03 Martindale has fabric, etc. 5:08 There's a great back-and-forth you can hear you can you can see in that thread. 5:17 Our guest, our planned guest, our invited guest is here Moon Settler. Moon Settler, if you're free 5:24 I've invited you to come on up and 5:27 begin our conversation. 5:33 Let's see if he can connect. 5:44 Oh great, you're on stage. Thank you for being here and thank you for joining. It's always great to talk with you. 5:51 It's always great to talk with you. 5:58 You can unmute and then we can begin our conversation. 6:03 Moon Settler, are you able to unmute? 6:30 Looks like Moon Settler is maybe having an issue with unmuting. 6:33 Oh, there you are. Hello. 6:38 Sorry, I had a little trouble. A lot of times when I come on as a speaker, my headset just disconnects. 6:45 So I didn't really hear anything that you said. Sorry. I heard that you are talking but I was not 6:53 there and so I can now speak and I can now hear. Great, great. 6:58 Well, welcome to our space. As always, we were just getting started. 7:02 I was just making some introductory remarks as I usually do. 7:06 It was very nice of you to chat with me in messages recently, one-on-one, 7:11 about the Bitcoin improvement proposals that are out there and 7:16 you had mentioned some interesting ideas and I wanted to just hear you, you know, speak whatever you'd like to say. 7:23 You know, our goal is just to talk about 7:26 drivechain and things, you know, related to that topic. So share your thoughts. In the past, we've discussed such things as 7:34 you know, the security budget. We've talked about the huge potential of sidechains and 7:40 we've talked about your personal passion for technology and 7:45 innovation and how that brings you to be aware of sidechains and have an interest in them and drivechain. 7:53 Why don't you give us some of your latest thoughts on the topic of 7:59 peer-to-peer sidechains and how they're relevant in our time? 8:06 All right, so lately I was pretty preoccupied with ARK, 8:12 Brock's 8:13 idea of 8:16 another related but separate layer 2 for 8:21 Bitcoin aside from Lightning. So ARK is highly interoperable with Lightning, 8:27 but it's not really Lightning and 8:30 I 8:31 was very much, you know, digging into that and trying to understand it and 8:38 the most important thing 8:40 about ARK is 8:42 aside from understanding the liquidity requirements and what the dynamic might be, 8:49 of course, people are 8:52 immediately going into the adversarial setting 8:56 because ARK is aiming to be, you know, non-custodian. So 9:01 you are holding your own keys. They're just not 9:04 manifesting on-chain as UTXOs. You have these virtual UTXOs 9:10 that you may or may not push on-chain. 9:12 So this is how ARK is trying to scale Bitcoin and trying to save us block space. 9:18 But if the 9:21 ASP, as they call it, the ARK service provider is 9:25 not cooperating, so to speak, 9:29 ARK is set up in a way that after four weeks he can basically spend these UTXOs with a single signature. 9:36 So unilaterally he gets to swipe everything because normally before the four-week expires people would be 9:44 swept over to a new pool transaction. 9:48 So they would abandon their old UTXOs and and they would get new ones and 9:54 this 9:55 this swap over is the interesting part of ARK, how this is working. 10:02 The Encore TimeLock transactions and Encore TimeLock contract transactions and the 10:08 Connector transactions. This is the big magic, 10:12 the invention of Burak that 10:16 is the most significant in all this and it's really cool. 10:20 But people immediately start to ask how in the hell I'm going to enforce a one or ten Satoshi 10:28 virtual UTXO on-chain, right? 10:30 Because that is just not possible on Bitcoin. 10:35 Not really possible. 10:36 Even if you even if you pad these outputs up a little bit like Burak proposed, like you are adding 10:44 600 Satoshis to one Satoshi 10:48 and 10:49 you are getting this 10:51 641 or 661, something like that Satoshi 10:56 virtual UTXO output that represents one Satoshi in the protocol. 11:01 So this means that the ARK provider is losing a lot of SATs if someone is pushing that on-chain 11:07 but so will the person that is pushing that on-chain, especially in a high fee environment. So 11:12 this is more like 11:14 this is more like a mutually assured distraction scenario where everyone is just losing with pushing things on-chain. 11:21 There are no winners there. 11:23 For these low amounts, right? 11:26 And 11:27 some people are asking that question. How in the hell if you are going to have 10,000 or 30 or 50,000 11:34 Satoshi transaction fees on average? 11:37 How in the hell we are going to be able to enforce our property rights in an adversarial 11:44 scenario? 11:47 There are no reassuring answers to this really. 11:51 So if we are going to get to a Satoshi dollar parity and 11:57 the average person is going to have life savings below $30,000, I think 12:03 if we take a global average, most people's life savings are below $30,000. 12:11 And if we take that and 12:14 assume that just pushing a single UTXO could be in that 12:18 hallmark, but certainly pushing five or six transactions on-chain is going to just eat it up, 12:24 then you get into this weird situation where you are not in custody 12:29 in the same way that if you are using a lot of Satoshi or Strike or Chivo or whatever else, 12:34 you are not in custody, but you are not really actually able to enforce 12:39 your property rights on-chain unilaterally. So you are still somewhat at the mercy of the ASP. 12:46 It's just a different ballgame really from 12:49 him being able to run away with your money and you not being able to do anything about it because you can actually 12:56 make them pay dearly for it. 12:59 Or maybe users together can make him pay dearly for it, but it's going to be a lose-lose scenario for most people. 13:07 And this is where potentially sidechains come in because it is expected that sidechains 13:14 all together are going to have oblong block space between them. So 13:19 block space on the sidechain is probably going to be cheap. 13:22 I don't know if it makes sense to create sidechains that really are 13:29 capable of going up to one gigabyte or block size or anything like that. 13:35 But let's assume something more sensible. So let's assume you have a sidechain where 13:41 every one million vbytes is going to require 13:50 the doubling of your minimum fees, basically, and this fee becomes 7.4. So the first one million vbytes, 13:59 you are going to have one sub per vbyte minimum fee. The second megabyte, let's call them megabytes, 14:06 similar. So in the second megabyte 14:11 range, you are going to have to pay two subs per vbyte, and in the third, you are going to 14:16 have to pay four, and then eight, and then 16. You can see that at 10 megabyte blocks, you are paying 14:22 1,000 subs per vbyte. So that is getting sketchy there. And so you have this 14:31 scenario where, you know, the space is there, really, if things, you know, show 14:43 constitutional, how they say. So if things get desperate, people have block space to use, 14:50 or maybe really aggregated. So if you really, really condense and aggregate the economic 14:56 activity, then you can pay really high vbyte fees that might seem insane for normal people, 15:02 but it's not really insane when you represent one million people or something like that. 15:07 So you are always, you always have space, basically, and you always have some limitation on 15:17 the amount, some same limitation on the amount of data that people can swamp your node with, 15:23 and so maybe something like that can play out. I don't want to get too much into this idea. I just 15:30 keep thinking that the best would be if we had expensive block space that was underutilized most 15:38 of the times, but we had space. So when these things have to unfurl on chain, people are forced 15:44 to push on chain. They have the space, right? They are not simply just stuck and 15:53 the whole thing is clogged up, but we don't want the burden to grow, you know, the way it would 15:59 if we put everything on chain. So long cooperation goes on, so long people can play nice 16:07 together, we can really, really compress the block space that we use. It's only the times when 16:13 things turn adversarial and maybe an ASP is trying to steal from people. That's when 16:19 these transactions have to come on chain, but hopefully these periods would be short, right? So 16:24 most people would, you know, especially if the potential for people to enforce their property 16:31 rights exists, right? So if it's economically possible for them to do, the ASP has literally 16:36 zero incentive to try anything but be fully cooperative because he will lose money on it. 16:43 So everyone will lose money on it, but ASP will probably go bankrupt if he tries to mess 16:49 with the users. So this is an interesting game where main chain is probably good for higher VTXO 17:01 amounts like 100,000 Satoshi and 1 million Satoshi and 10 million Satoshi and the whole 17:07 Bitcoin stuff like that. It's probably going to work out okay on main chain, but a thousand Satoshi 17:15 VTXO and below is not likely to be recoverable. And you basically can have an ASP actually provide 17:25 a such a service that your high VTXO amounts are sitting on chain and your low VTXO amounts 17:36 are sitting on a sidechain. And this sidechain can be, you know, liquid or it can be a drive 17:42 chain. It could possibly even be a surf chain. This is not officially coined term for 17:52 for drivechain like space chain like things that are not exactly like that. I can talk about this 18:02 later what are the differences between drivechains and what we can do with Covenants. 18:07 So you can have more block space for these lower Satoshi amounts to have a better game theory 18:17 than you could have on main chain. This is possible. And maybe some ASPs will provide 18:22 this service. Maybe some users will demand this service. Maybe some equilibrium can be 18:27 reached without this, right? So I imagine this will only emerge if we are going to have problems 18:33 with ASPs on main chain and these low amounts that are not economically enforceable for the 18:39 users to recover on chain. So if you are going to have problems, then we will have to find 18:45 solutions for this, right? And so this has been the interesting angle with the sidechains that 18:53 it does look like even if we are doing our best with what we can do with this shared UTXO, 19:00 shared virtual UTXO, shared VTXO schemes that, by the way, give us a lot of privacy and 19:08 flexibility and pretty good user experience and all and it has a decent game theory, I believe. 19:15 Still, we are going to get into this situation potentially where a lot of transactions have to 19:22 hit on chain, like a lot, in a short period of time because these schemes are time-locked. 19:29 So if you have a situation where the four weeks are nearly expiring for a larger transaction, 19:43 maybe thousands of people are in there and it's coming to expiration soon and you are going to 19:49 have a 24-hour time lock on your VTXO. So your VTXO has to hit one day before that expiration date, 19:56 has to hit on chain, so the timer starts, the relative time lock starts and basically 20:06 if you are moving a little bit too late and the mempool is very, very, very congested 20:13 and you can't really feebump these transactions because ORC is allergic to mullability, 20:20 then you can get into an interesting situation where despite everything, how it is set up, 20:26 you are not able to unilaterally withdraw and you are going to be swept up by a malicious ASP. 20:36 So I don't think we will ever get away from the need for some flexibility in the available block space. 20:48 At least I don't know how that could look like. Even with rollups, you are going to need that rollup to be available. 20:58 So I think people are looking for some weird magic that somehow removes this consensus critical data availability problem somehow 21:11 and we are magically scaling to 1 billion people. So I'm not sure we are there yet. 21:21 Moonsettler, thank you for that very, very, very interesting description of your perspective at this moment 21:28 in light of new ideas that have been discussed at the conference and since then. 21:34 It would be great to hear your thoughts on this tweet from a couple of months ago in a thread that you had weighed in on 21:44 where Adam Back had written, we're probably going to need sidechains, drivechains, where we're going to onboard the next billion users soon. 21:54 Do you agree with the idea that, oh, we have another speaker, Paul, coming to the stage. 22:01 Maybe let's take his question or comment first before I go forward. 22:07 Paul, did you have a comment on Moonsettler? 22:09 Yes, I think, why don't we just talk about, I think Ark is the cool thing to talk about. 22:14 I don't know if you saw David Harding's, I mean Moonsettler, did you see his article, I mean his mailing list post about 22:22 how much money would have to be in like basically a hot wallet to serve, like what the exact configuration of users would have to be. 22:30 Because I think he says something like, if you take the one billion, the one megabyte block size and you divide it into people running Ark nodes, 22:44 he had numbers that were like one million people per Ark liquidity person and then he had something like they need, 22:55 they make the transaction turnovers like $3,000 a month like on average, but because there's variability around the average, 23:04 it would be like $9,000 a month of liquidity would be needed per person and that would be like billions of dollars in BTC in a hot wallet 23:15 in order to serve a million users and then they said something like at a very low interest rate, 1.5%, I think he used the capital cost 23:28 would come out to like $1,000 per user per year and then he has a very interesting part where he says, 23:36 even in a situation where it costs $100 per on-chain transaction, which is kind of, that's probably already DOA, 23:45 but even in that situation, the user would have to open themselves 10 different channels, 23:53 they'd have to want to open more than that for it to be cheaper and I thought that was a very intriguing post. 24:00 I don't know if anyone replied to that, I'm going to try to look right now and see if anyone replied. 24:05 Yeah, so the thing with Ark is the velocity of the money, the velocity of the VTX is a real killer, 24:14 so if you just get uplifted into an Ark pool and you are not transacting, 24:20 then you do not actually add any additional liquidity cost to the Ark service provider. 24:26 As you are nearing the end of the period, you will get a free swap over because his liquidity is going to get locked up 24:36 for a very short amount of time, so you get a cheaper or free swap over 24:46 and basically, if people are transacting very frequently, these very low amounts on Ark, 24:53 then it can be quite significant because these low amounts of VTX source, they come at a significant multiplier, 25:05 so they need to be padded to not be dust and that means that tens or hundreds of times larger sized VTX source 25:20 are going to be locked up than what is the nominal value of those VTX source. 25:26 So for these very low amounts, if they move at a very high velocity, then it is a problem for the service provider, 25:34 so it's going to need a lot of liquidity. 25:36 By my calculations, it will need somewhere around 200-300% of what the users hold in the pool, 25:46 but that is not very much far from Lightning, so Lightning roughly probably requires 200% of the logged in capital 25:59 in the network than what users can hold in their balances, and it's not logged into individual channels, 26:11 so the big thing about Ark is this is all quite flexible and whoever needs it can access that liquidity 26:18 and probably the fees will reflect the situation that the service provider has with his available liquidity. 26:27 So one way to look at it is the following. 26:30 Let's say that Ark service provider has most of his liquidity tied up in already issued pools 26:40 and it has an available liquidity pool that he can use for the next ASP pool transaction, 26:52 and therefore people are bidding for that liquidity, not block space, they are not bidding for block space, 26:58 they are kind of bidding for that available liquidity, because as that is the blockchain, 27:04 the ASP is going to have an old pool transaction liquidity released, if these are roughly even, 27:11 then he can then start to roll over, but he always has some liquidity limitation of how much he can take, 27:16 and basically if people just really want to move the money, they are going to have to wait in line, 27:23 like everyone is going to offer some fees to get into the next pool transaction, 27:29 and basically you either fit in or not fit in. 27:34 If people are paying more than you, then you are not going to fit in, 27:37 because the ASP is going to have this liquidity constraint. 27:40 So like I said, liquidity kind of becomes analogous to block space in the blockchain system, 27:46 and you are just not going to be able to move very fast if it's going up, 27:53 and the service provider can't take a loan or source liquidity somewhere and serve people. 28:00 If everyone wants to move suddenly, then it's going to be expensive for him, 28:05 but let's say you can wait a little bit and things clear up, and then you can finally move cheaply again, 28:11 so that's a possibility. 28:13 I'm pretty sure people, just based on the assumptions of how much of their stack people are going to move, 28:21 and at what frequency, can come to very widely worrying results on the liquidity requirements for ARK. 28:31 And I think user behavior is going to be in a feedback loop with the fees, 28:36 and the fees will be in a feedback loop with the available liquidity to the ASP, 28:40 and so this is a bit of a self-regulating system, I think, or could be. 28:52 Well, that's very interesting, but that's also, I mean, I like that idea that liquidity is similar to block space. 28:59 It does remind me a little bit of how payments evolved in the world, the real world of banking, 29:06 where, you know, it's how the evolution of credit actually took place, 29:11 where people thought, well, why do I have to actually move this, you know, 29:16 people compromised on security because they said, well, why do I have to actually move this coin from Bank A to Bank B, 29:24 like a physical gold coin? 29:26 They said $20,000 worth of payments comes into this bank every day, and $18,000 comes out, 29:35 so why don't we just wait until the end of the day or wait until the end of the week to settle? 29:41 But, yeah, I find that – I find ARK to be very interesting because, I don't know, it's just new, 29:50 and I feel like I don't completely understand it yet, so I think that is a neat – this is a neat idea. 29:58 Could you re-explain what you were saying about the low-value UTXOs? 30:04 I didn't exactly understand that. 30:08 Yeah, so the point I try – I'm trying to raise constantly because I myself have been in parallel. 30:17 Before I even knew Burak was working on ARK, which was called TBDXXX back then, 30:23 so before I even knew Burak was working on this, I was fiddling with eCash 30:31 and how we could fix eCash from the perspective of, 30:36 let's just not hand out money printers to everyone around the world 30:41 and then just pray that the 21 million BTC limit somehow will hold available liquidity-wise in the world, 30:51 and we are just not getting into a massive, massive fractional reserve banking hell again. 30:59 You know, history repeating itself. 31:01 So I was trying to develop a scheme of proof of liabilities and fraud proofs for eCash, 31:13 and so I got into eCash a little bit, and I helped implement DLAC proofs, 31:19 prototyped and helped implement DLAC proofs for Koshu, and tried to figure out these things, 31:27 and as I got comfortable with the Chomium blinding stuff, I started wondering why couldn't we just, 31:36 you know, as the fees started to hike, and we got a little glimpse into the future 31:43 where mere mortals may not be able to afford the on-chain transaction stand-alone. 31:50 So the Covenant payment pools and Chomium eCash, if it had a love baby, how could that look like? 31:57 So I had the intuition that you can easily do a Chomium blinded mix, 32:01 a sort of virtual coin join inside such a Covenant payment pool, 32:06 and the chain would only see like a single taproot input spent to a single taproot output, 32:14 and they would have no idea what is going on inside, it would be like a black hole. 32:19 So I made this dark pool proposal that I started chatting with people with it, 32:25 and in the meantime, Burak has been working on this for quite a while, he wanted to fix Lightning, 32:31 and wanted to create a Lightning wallet that makes sense to him, 32:35 and he also arrived to this conclusion that you need to put people under a single UTXO 32:43 where they have a Covenant input to unilateral exit and then force their property right on its own chain, 32:49 but the two protocols are markedly different enough for them to exist, although I really, really love ARK. 32:58 So as trade-offs overall, it's almost certainly going to be a better UX if on-chain remains usable to at least some debit. 33:12 And the point is, we both have been working on very similar things, 33:17 like we had this convergent evolution thing, actually multiple people have been playing with these ideas, 33:26 and when we started talking about it, we were all like, what the fuck, 33:31 that's exactly what I'm thinking about, and stuff like that, it was very funny. 33:36 And the point is, what I wanted to go with, this Covenant-based UTXO sharing, 33:44 privacy enhancing and block space saving techniques seem to be fixing a lot of problems that Bitcoin has, 33:53 but like I said, these small amount virtual UTXOs, ARK is using 10 multiplies, 10 exponents, I don't know how to say it, 34:11 so you are having 1, 10, 100, 1000, so on, virtual amount, fungible virtual UTXOs, 34:19 like if you had virtual banknotes, it's a change system, 34:24 and I, for Darkpool, did not even consider for people to have near and below dust amounts in these virtual UTXOs, 34:36 because I knew very well that it is not an enforceable on-chain. 34:40 Interestingly, Burak actually wants people to hold these virtual UTXOs, 34:46 he expects the ASP to pad them to amounts that can be put on-chain, 34:53 of course to the detriment of everyone involved except for the miners, 34:57 but like I said, this is a lose-lose situation, because you can't economically recover 1 Satoshi or 10 Satoshi or 100 Satoshi, 35:09 even if you had that UTXO, spending it would cost probably more in a high-fee environment than what it represents, 35:20 and so there is this thing where, even though these protocols are very good, very cool, everyone loves them, 35:26 it's still not the same as just having an infinite amount of cheap block space available, 35:31 it's not the same assurances on that you can keep your Satoshis in your wallet if someone turns malicious, 35:40 you are more like just assuring that it can be made very costly for them to screw their users over, 35:49 unlike with a fully custodial model where you have a custodian and he can just run away with your coins, so to speak, 35:57 and laugh about it, right, so you can't really do anything to stop it. 36:02 I think right now Atomic Wallet is experiencing these issues, even though it is supposed to be a non-custodial thing, to my knowledge, 36:11 and we are getting constant reminders of this, that if you do not control your keys and you can't control what happens on-chain, 36:23 then you can very easily lose everything, so I don't know, did I answer your question about the small amount of UTXOs? 36:34 Right, for those who don't know, an output, when you own a UTXO, the UTXO is a very small thing, 36:48 it costs only 43 bytes to make an output, and each output is basically a 32-byte hash plus a 4-byte counter, 36:59 but to spend them is much more expensive, and this is partly why the SegWit discount was a factor of 4, 37:07 because it's like 4 times more expensive to spend something than to spend an output than to create it, 37:15 and in fact, when the fees are high, people often... 37:20 So Roger Ver, who is of course, everyone hates Roger Ver, blah, blah, blah, but he had interesting data on how many people had paid more than $1,000 total in transaction fees, 37:33 because they had many, many inputs they had to clean up, and their wallet would just add them all together, 37:39 and you would pay more in fees because it takes whatever, like 120 or so bytes to select an output to spend, 37:51 and it would cost that many bytes to... the input is like, whatever, like two-thirds the size of the transaction or something, 37:59 of a normal-sized transaction with maybe one input, two outputs. 38:04 So if the on-chain fee is $50 a transaction, then every input you add to that, that would be like, whatever, like $35. 38:15 So if you have any output that's less than $35, then by adding it to your stash, your net worth is going down. 38:23 Yes. 38:26 So, yeah, so I think this is the obsession that people have with the unilateral exit, which also people... this is drivechain related, 38:36 because long ago, I think it was, maybe in May 2018, I think it was May 2018, 38:45 and I met Mark Redenbach, I think, and maybe Christopher Allen in a bar in San Francisco. 38:56 I was just traveling there, and they were really interested in that. 39:01 They said the sidechain should have that, and I was never as interested in this, 39:06 but they said, yeah, the sidechain should have a thing where if the sidechain explodes and is torpedoed, 39:13 there's a way of dragging something back on-chain that pays everyone out. 39:21 And I kind of was never interested, and I think Mark Redenbach even said something like, 39:25 I may be misquoting him or misremembering the situation or misunderstanding what he was trying to convey, 39:31 but I think he said something like, oh, I can only support a design if there is... 39:38 I don't know if he used that phrase, unilateral exit, but I think he was talking about that concept. 39:44 Someone can look him up. 39:46 But you understand why I was never interested in that, because in my head I'm imagining, 39:51 okay, someone makes a large block sidechain with a block size that's like 100 times the size of the Layer 1 block size, 39:59 and then the UTXO set becomes 100 times the size of the Layer 1 UTXO set. 40:04 It's like what transaction or series of transactions... 40:08 I think what they had in mind was some kind of deterrent. 40:11 It was something like you would be able to, over months and months, slowly get everyone's money back in some kind of... 40:23 Some kind of unwind transaction, which, of course, a sidechain developer could create and could make. 40:29 They could make it as an optional thing, but there's no real way of Layer 1 enforcing that the sidechain do that 40:36 without it processing the entire UTXO set of the sidechain, which would, of course, completely defeat the whole point 40:44 of doing it like that in the first place. So there's no way that Layer 1 can enforce that such an unwind transaction 40:51 be constructed. But yeah, people are really interested in this unilateral exit idea that you raised. 40:58 They really are obsessed with that idea, and I do think... 41:01 They wanted the opposite, right? They wanted the opposite of what I was talking about earlier. 41:06 So I was talking about, all right, it's not really feasible to do these low-amount exit withdrawals on-chain, 41:14 so why don't we do them on a sidechain where the blockchain is spacey, the sidechain is decentralized enough, 41:20 then it's still better than being straight up in custody, but it sounds like back then they wanted to do the opposite. 41:27 Right. Well, yeah, and then people would say, it's not economical, so we'll just cut it. 41:33 We'll just kind of drop it, like Lightning originally did that for Dust outputs. 41:38 They said, well, they just go into the fee or something, which was smart, but now then... 41:46 I think that is still true. So below Dust, you don't have over-HTLCs, 41:52 but the commitment transaction is going to have a spread that goes to the miners, 41:57 and basically it's a lose-lose situation. If someone tries to screw the other with these below-Dust amounts, 42:04 then they are just going to eat the loss half and half or something like that. 42:09 That's what people have been talking about, because there was a discussion that Lightning becomes trusted if the fees go up. 42:19 It's going to become trusted for below-Dust amounts because you can't have HTLCs economically enforceable. 42:26 And basically, I find that Ark is doing something very similar here, right? 42:32 Because it is basically playing these amounts, if they are disputed, these below-Dust amounts, 42:43 just playing it into the miners, right? So that's what happens here too. 42:51 Yes. The... Well, I think... So is it actually... In the case of Lightning, when it's paid into the fee, 43:04 like if the HTLC, the person is going to try to broadcast in old state, 43:10 they are the one who would lose because they pay the two weeks and they pay the fee. 43:19 So I guess that is the deterrent. 43:22 Maybe Ampus could tell us how it works. Maybe he is more into this, because he is an actual Lightning developer. 43:33 So I'm more focusing on the Conan stuff and this UTXO sharing stuff. 43:38 But I'm just saying what I heard in the past days and in the discussion. 43:45 And it seems like it's the best we can do. 43:49 So in a high-fee environment, when small amounts are not enforceable on-chain, they become perma-Dust. 43:55 The best we can do is some weird game-theoretical stuff where the miner is going to get that if someone is playing games. 44:03 We can't really reimbuse individual users, obviously, on main-chain. 44:09 And so this is something where I was once again reminded that maybe we should have sidechains for stuff like this, 44:21 where we could expect the fees to be lower. 44:27 I have a funny little story that I'd like to tell. 44:30 It's not actually a story. It's like an economic model, so prepare to be really bored. 44:37 But basically, the story goes something like this. 44:40 If we live in the hypothetical high-fee world that people want, 44:45 and they want to live in the $50-per-transaction world, like whatever, the Dan Howell's world or whatever it is, Piero Scharb world, 44:53 and then many, many of those HTLCs will not really be used. 45:00 They will be in the scenario where you're paying the in-flight amount to the miner in the form of the transaction fees. 45:12 And then actually something kind of funny may happen. 45:15 This is my story. Something kind of funny may happen where if you're a miner, 45:20 you have a comparative advantage in being a lightning service provider now versus someone who is not a miner, big mining pool. 45:28 And so the mining pool, this is a deliberate – I'm forcing this story along these lines, so it's a manipulative story. 45:36 But I think it's interesting nonetheless. I mean, I think it's true nonetheless. 45:39 So like fees are very high, every lightning channel, like 99 – because most payments – I looked all this up at one point. 45:47 I don't remember the exact number, but in terms of quantity, most of the world's payments are very small. 45:52 They're like – like half of them are like $20 or something. 45:56 So a lot of people make small payments, many of them under $50. 46:01 Whenever I looked this up, it was probably like pre-Biden COVID inflation, but I don't know. 46:08 They're very low. So if most transactions are this way, then you have a risk if you are a miner. 46:17 If you're a miner, you have no risk, and then if you're not a miner, you have some risk in being a lightning service provider. 46:23 And as a result, the comparative advantage would end up being most of the miners' mining pools would be the big lightning service providers. 46:34 And then it just becomes like the miners can steal critique of BIP300, except like much, much, much, much worse, 46:43 because they can just individually snipe any channel that they wish kind of with impunity. 46:50 And what's kind of funny about this is this is what like a large block of Bitcoin Cash people would say that lightning will just return us to normal banking or something. 46:59 And I firmly believe that they had no idea what they were talking about back when they said that in 2015. 47:07 But it is kind of a funny little story that they would have that comparative advantage, 47:13 and then it would actually be the same end result, only much worse, the same result of just large miners controlling everything. 47:25 Yeah, it certainly looks like that their prophecy has been full-blown coming to fruition or something like that, 47:35 because we really saw that these huge custodial lightning wall providers are providing a better, cheaper UX to people and sometimes even more reliable. 47:50 Yeah, the wallet of Satoshi was a little bit stress-tested, but obviously they could upgrade and just take the abuse. 47:58 People just sending one Satoshi or whatever around like crazy in these zapatons. 48:06 So it was pretty obviously the best user experience for people who participated in that to have a custodial lightning wallet like the Satoshi. 48:21 I'm not even sure that the wallet of Satoshi to the wallet of Satoshi is not just moving funds in an Excel table, so to speak. 48:31 It's just a database update, really. 48:39 So Hampus is here, maybe ask him about the lightning stuff. 48:46 Yeah, hello guys, can you hear me? 48:49 Yes. 48:51 Yeah, I think you already covered most of Moonsettler, but my worry is more like there could still be consensus failures between the lightning nodes, 49:02 which we tried to fix all the failures, but even negotiating fee can result in a force closure. 49:11 So even though there's no malicious actor trying to enforce a force closure, they can still happen. 49:17 So that's kind of my worry about if the transaction fee goes too high, because I really want to have a more trusted network than having these HLCs. 49:29 But with the current system, you could still have force closures happen anytime. 49:37 We saw that when the fees went up, that a lot of people complained because probably before no one really cared because the fees were so low. 49:45 But now when the fees were high, a lot of people reported their force closures. 49:50 So it seems like it's still a big problem with this lightning node limitations having consensus failures. 49:58 I heard that if two lightning nodes can't agree on the fee rate, then they will force close. 50:05 And that is basically partly a result of high fees and partly a result of when the mempool is not really used for determining the fees, 50:17 because everyone is working around it, because there are all these restrictive policies that people are actually looking to make worse. 50:25 So people are trying to pay out of bounds for the transactions, and you can't make good predictions on the fee rate, 50:32 and people using different services or different methods are going to come up with different fee rates, 50:38 and they're going to disagree, and then the lightning node just disengages. 50:42 So actually it looks like that high fees made it worse multiple ways at once, and people have suffered as a result. 50:51 Yeah, for sure. I think many force closures are because of the fee negotiation fails, because it locks up with each other. 51:03 But I've also seen GitHub issues, but other consensus failures are just pure logical errors and coding failures. 51:12 So there's still a lot of work to make sure that LND, Core Lightning, and the other nodes talk to each other in the best way. 51:21 So that's my worry if the fees go up and just have a lot of money just getting absorbed to mining fee, which is kind of weird. 51:31 But as far as I understand, the problem is mostly for the routing nodes getting screwed, not so much about the sender and stuff. 51:39 But I prefer having a more trusted setup and don't use HTLCs at all, because it's kind of flawed. 51:47 That would be my preferred option, but I've also talked in the past about just using driver chains where we hopefully have lower fees, 51:57 and then we could deploy Lightning over those driver chains instead. 52:01 So that would make HTLCs more workable, I suppose. 52:09 Yeah, I find the idea of the mempool no longer being used, or the idea that the idea of the mempool was kind of like it would aspirationally be the next block for everyone. 52:24 And everyone wouldn't agree, but when the next block came in, there is no the mempool. 52:30 Everyone has a different mempool, but they were supposed to be aspirationally similar. 52:36 This idea is very old. In July 2015, miners told me they had someone who ran a big mining pool. 52:44 They told me, just by the way, there is a private mempool that all the miners have, which is sort of fine. 52:53 But this idea of the out-of-band fees, I think, is fascinating. 52:57 That people don't even pay the fee using the public system, and they have a private mining channel. 53:13 I think that's very interesting development. 53:17 Yeah, it's kind of a failure of the wallets, right? 53:19 The wallets have failed a bit, and also like RBF and child pay for parents. 53:24 It's all because of RBF that started us down this path, I wonder, I don't actually know. 53:32 And it seems like users can't use the tools sufficiently or something, or not at all, I suppose. 53:41 I suppose it's easier to just have a centralized provider like mempool providing the service. 53:46 But it's probably very bad for the longevity of Bitcoin. 53:55 RBF really split the room always, because there were always people who said, 54:01 well, the miners must be revenue maximizing, so we must do this, we have no choice. 54:09 And then there's plenty of other people who just said, no one really wants, 54:14 there's no legitimate, RBF is just like an inducement to replace your transaction. 54:26 In practice, no one actually, it's kind of interesting how it all intersects with fees, 54:31 because when the fees are very low, there's no real legitimate reason for you to fee bump. 54:37 But if the fees are high, then it becomes legitimate. 54:42 But yeah, RBF was one of the earliest disagreements in Bitcoin. 54:46 It was one of the most bitter. 54:49 It was the original Peter Todd versus Mike Kern Bitcoin dev flame war thing, 54:55 and both of them took the emails and they started sharing them with other people. 55:00 And Mike Kern would go around and say, look how crazy these Bitcoin developers are, 55:04 they're the craziest people in the world. 55:06 And Peter Todd would go around and he'd be like, look how crazy Mike Kern is. 55:12 And it was a very acrimonious disagreement. 55:17 But I think we have to, I mean, now with the mempool, 55:22 it's funny because when they did RBF, it was ultimately allowed, 55:27 but there was like a first seen safe version, 55:30 where each individual wallet would like, 55:33 if you could only RBF to something that paid the same destination, 55:40 and there was child pays for parent. 55:43 So it was a very fascinating story about how 55:49 first seen safe is basically admitting that partly, 55:54 it's so weird because it enables one case where you can, 56:01 it seemed like a really good compromise, 56:04 but in reality, it was just maybe one more thing. 56:08 Maybe it should have just been scorched earth mempool, 56:12 revenue maximization, like from the very beginning. 56:16 No first seen safe, no nothing. 56:20 And, you know, sorry for your loss or something like that. 56:24 I don't know. 56:25 I don't know. 56:26 I can actually, I honestly have no idea because I can remember like one, 56:32 a counterexample is like many times someone accidentally paid a huge amount 56:35 of Bitcoin in fees. 56:36 Like they've made their first Bitcoin transaction 56:38 and they selected a 50 Bitcoin block that they mined. 56:42 Then they tried to send themselves like one 10th of a Bitcoin 56:46 and they paid 49.9 Bitcoin in transaction fee 56:50 because they didn't use a change output because they made it themselves. 56:53 And there, 56:54 I can remember several instances of like the mining pool got in contact 56:59 with the person so that they could give them their money back. 57:04 So the mining pools were very friendly or whatever for a while. 57:09 They really almost all the time, 57:11 the block size war being a completely sui generis case of its own, 57:16 where different people had gotten to the miners first and told them about 57:21 what they thought was best. 57:24 Miners never really had any idea what to do. 57:29 Anyway, I find this out of band fees thing to be fascinating. 57:32 And I did not know that if two lightning channels disagree on the fee, 57:36 they will immediately close. 57:37 That seems. 57:39 But I guess they cooperate. 57:40 They cooperate. 57:41 They cooperate of course. 57:42 Yes or no? 57:44 It's unilateral. 57:45 It's a forced closure. 57:48 It's really bad. 57:49 That's why it's dangerous. 57:52 So which one, 57:53 the lower fee or the higher fee? 57:55 I don't recall exactly how it works, 57:57 but I know that if they cannot agree, 57:59 then like they will just force closed immediately. 58:01 And all pending impact issues, 58:03 fees will have to close as well. 58:05 So that's why it's kind of dangerous with the dust limit and stuff. 58:09 Wow. 58:10 That's so bizarre. 58:11 Why would they do that? 58:12 Because they can't know if the fee is different without interacting and they 58:15 can't just interact one last time to cooperative close. 58:19 I think in the future we'll have to like make it more like nice with each 58:24 other because right now it's really harsh. 58:26 As we saw in May with the fees going up and forced closure happening. 58:31 But I hope in the future that it won't be like, 58:34 the first thing they do is just force closed. 58:36 Like they try to somehow mitigate the issue, 58:38 but yeah, 58:39 it's a huge problem right now. 58:41 And the forced close is going to happen with the last commitment transaction 58:46 state. 58:47 So if your last commitment transaction was made in a six per V byte 58:52 environment and you are forced closing in a hundred per V byte, 58:56 then you are never going to get confirmed basically. 59:01 Yeah, 59:02 that's kind of a mess because I can see how if they disagree on fee, 59:06 then what happens if someone broadcasts an HCLC that may pushes you into the 59:11 disagreed range where someone says, 59:13 I don't consent to paying that much. 59:17 That's too much. 59:18 And the other person says that won't be enough to get us confirmed. 59:22 So the whole transaction is dead now. 59:23 So I actually see why they would want to close. 59:28 I don't see why it's in your land. 59:31 Yeah, 59:32 I think, 59:33 I think this is, 59:34 this might be reworked or maybe the, 59:38 the operator will have to acknowledge that if a channel is stuck with a 59:43 message saying in your node, 59:45 you know, 59:46 that the other part is not agreeing on the fees with you, 59:50 what do you want to do? 59:52 And maybe you have the option of, 59:54 you know, 59:55 agreeing with the fees or, 59:57 or just closing like in a, 1:00:00 in a day or something, 1:00:01 because, 1:00:02 because this is, 1:00:03 this is going to cause a lot of grief and people can get accurate fee 1:00:06 estimates. 1:00:07 So I think this right now is not really viable. 1:00:21 So, by the way, it's a funny story because, you know, first seen versus, versus RBF, RBF is, it was such a, such a huge, huge thing. 1:00:34 And, and many people have argued that, you know, unconfirmed transactions cannot be relied on. 1:00:42 And there is just no way to make zero conf work. And the funny thing is that work with ARK and this TX lock actually did in a limited sense made zero conf work. 1:00:54 Because the ASP is so, so disincentivized in messing with the transaction ID of these ARK pool transactions that anything that they commit to can be considered basically final. 1:01:10 Because the ASP is looking to lose a lot of money if they are not final. 1:01:15 Even if the blocks get reorg'd, even, even if they don't get conf in for a while, these transaction IDs are not going to change. 1:01:26 So it's a funny thing that, you know, these connector and encore time lock contracts kind of, kind of solved the zero conf issue. 1:01:39 I don't know, I may have told it already. I don't know if you guys heard it or seen it, but I, it, the whole thing reminds me of back to the future episode, right? 1:01:48 So you basically have a future transaction, you have a future transaction that has not been confirmed to the blocks, blockchain. 1:01:58 So from the blockchains point of view, it does not exist yet. 1:02:01 And this future transaction has a transaction child. 1:02:05 And this transaction child is used as an input in a post that confirmed. 1:02:13 yet. And this future transaction has a transaction child. 1:02:19 And this transaction child is used as an input in a post -ware 1:02:25 -confirmed poor transaction where 1:02:29 you are adding to a virtual UTXO, are adding this on -court time 1:02:35 of contact and that uses as an input transaction that is not even 1:02:41 existing yet, but may exist. 1:02:42 And that is how you 1:02:47 to get new virtual UTXOs. 1:02:52 this basically creates this weird effect that it's almost like somebody is coming back 1:02:58 from the future to the past and does something and for that you have the present that 1:03:02 you want. But if something happens in the future that prevents him from going back in 1:03:07 time, 1:03:07 then your past changes and so your present changes. 1:03:11 Of course, we are not really time -traveling in Bitcoin, but it's just a non -logic that 1:03:15 I like to to help people understand what makes 1:03:20 a spend atomic when the other side is not confirmed yet. 1:03:26 So, it's 1:03:27 interesting. 1:03:30 Yes, it is. 1:03:31 like that analogy. 1:03:34 the subject of ARK, MoonSettler, asked you, I think in a DM, is it a soft fork or a 1:03:40 hard fork? 1:03:42 what was your... 1:03:44 Yeah. What was your thought on it? 1:03:45 means 119, 1:03:46 doesn't it? I think for to really work, to 1:03:52 really start to work in an acceptable way, it either needs any private APO 1:03:58 or it needs a check template verified in CTV. 1:04:02 Those are the minimum amount of changes that will make R 1:04:09 can technically try to do it without a software. 1:04:14 So, can try to emulate Covenance with 1:04:19 music, cooperative music signings. 1:04:25 when you are 1:04:25 are making a new pull transaction, when the OX service provider assembles a new pull 1:04:31 transaction and makes these commitments, if you have a covenant, then you 1:04:36 can be sure that these can be pushed to on -chain and nobody can 1:04:41 basically double -spend them. 1:04:43 They have to go to on -chain exactly like that. 1:04:45 You basically only have to agree to the root of this transaction. 1:04:50 For example, if you want to get uplifted, you only look at this distribution and you 1:04:55 are only signing the root transaction. 1:04:58 It's a much, much simpler and easier thing. 1:05:01 if every person who has a BIP300, in the new port 1:05:05 transaction, virtual transaction distribution tree, they all have to sign 1:05:10 cooperatively in a large multi -sig this whole thing. 1:05:15 then it's a music two or three rounds of interaction per node 1:05:21 industry. And if there is 1000 people in there, then you 1:05:24 are going to have like hundreds, hundreds something nodes 1:05:30 and they all require this multi -step interaction. 1:05:36 one can clearly see that this is going to suck. 1:05:40 Probably there are going to be a lot of signing sessions. 1:05:44 You are not going to get anywhere near to five second time zone between 1:05:49 these output transactions that are going to be a lot of failures. 1:05:54 It's much easier to dose. 1:05:57 if someone, let's say a firm that makes a lot of money on on chain con joints or chain 1:06:02 on a resistor or 1:06:04 someone is looking to just prevent a new protocol 1:06:09 from gaining traction. 1:06:12 They could probably very, very cheaply just run denial of service attacks on this 1:06:18 signing. so there are these issues. 1:06:22 but if 1:06:23 we put that aside and we are a bit optimistic and hopeful about it, or we are just 1:06:28 thinking about proof of concept stuff, then we can do it without a software, 1:06:32 technically. It's just really horribly complex for absolutely no reason. 1:06:38 So really, that's the main point. 1:06:39 There is no reason to make this suck so much and make 1:06:43 it this complex. 1:06:44 Covenants are very, very, very simple things. 1:06:47 And people who actually understand how they work and are comfortable with working with 1:06:53 them. Interestingly, I'm not afraid of them. 1:06:55 this is one of those things where wizards are not afraid from the magic that they have 1:07:00 mastered. It's only the 1:07:02 peasants that don't understand what is going on, are scared of it. 1:07:08 I guess we have a lot of education 1:07:14 to do on the subject, because a lot of people are still trying to play cautious 1:07:20 or over the cautious 1:07:27 We can do so much more, 1:07:32 optimistically and cooperatively, if we work together with the help 1:07:38 of these things. 1:07:39 And they remove so much trust and so much 1:07:42 interaction. 1:07:44 actually, resulting transactions would be validated 1:07:49 faster. So for example, if you use CTV, especially, then the whole thing 1:07:55 would actually lessen the burden on the nodes and lessen the burden on the participants 1:08:01 to 1:08:01 very, significant debris. 1:08:04 so that is the state of things that yes, ideally, we get a soft fork 1:08:10 in, and then arc can be really good. 1:08:13 with additional soft forks, it is possible to make it even better. 1:08:18 What that would mean is you could probably add 1:08:24 additional arshurances. 1:08:31 And only be spent once but maybe it can 1:08:37 reduce the liquidity requirements of this protocol. 1:08:41 So if you could just hand over virtual transaction outputs. 1:08:46 And the simplest way to do that basically, I just want to this quick thing 1:08:51 to give people something to play within their minds and then I said we have to 1:08:57 go. basically if you take an Arc pool that is not expiring after four weeks, but 1:09:03 expiring after four years. 1:09:08 I didn't tell you. 1:09:10 So if you are making an Arc pool that expires in four years and not four weeks, then 1:09:15 you can put 1:09:17 the private keys into these bigger devices like notes, 1:09:23 RFID chips, kind of like an open time. 1:09:26 you can basically hand over the private key to someone and they can sit in the same 1:09:31 virtual UTXO for years. 1:09:34 And then can actually step near the 1:09:37 expiry, near the end of the for you. 1:09:38 You can actually swap it over. 1:09:40 If anyone is familiar with the tap sign, or SADSCART or something like that, you can 1:09:44 imagine that there is this tiny chip, a tiny RFID chip, know, in a paper bill or 1:09:49 prostitute bill. And you are interacting with it with your phone or whatever. 1:09:53 And you can read a public key from it. 1:09:57 Or if you break the seal on a slot, you can read the private key and then you can 1:10:01 actually redeem it or send it to a hospital or whatever. 1:10:05 Or you can actually prolong the life of a cash node that is in 1:10:10 good shape and is near expiry. 1:10:14 basically it solves every problem 1:10:16 that we had with this BIP300 type representations of Bitcoin, if you are using ORP 1:10:22 this way. So it's very interesting. 1:10:24 is lot of ways ORP could be used. 1:10:28 Burak is thinking about basically a moon ballad substitute, where you have this 1:10:34 optimistic shared 1:10:36 on Chainwallet that you can use with Lightning 1:10:42 Interaction. You cannot even pay Lightning Invoices in it. 1:10:48 And that's the main use case because that is the main way people are using. 1:10:53 Who ordered the other Bitcoin? 1:10:54 is the main way. 1:10:55 They are comfortable 1:10:56 with using Bitcoin. 1:10:58 But maybe we want to use Bitcoin in places where there is no reliable internet service 1:11:03 and people do not have smart devices and stuff like that. 1:11:09 And interestingly, EORC provides a pretty good solution there where basically the issue 1:11:13 of having access 1:11:16 unilaterally. Guarantee is that no coins, no satoshis are getting lost. 1:11:22 know, if these paper bills get burned, destroyed, lost, whatever. 1:11:27 So the Bitcoin is not getting lost. 1:11:29 It actually is reclaimable. 1:11:31 But people have pretty good assurances that they can be rugged. 1:11:35 They are holding the 1:11:36 private keys to these things, and it would take years for them to get rugged. 1:11:41 there would be someone who does something about it at some point when these cash bills 1:11:46 are exchanged. so I just wanted to mention this because it's very funny. 1:11:49 think Paul said that he has to go. 1:11:51 I did not actually hear what he had to say, but maybe he he has to go. 1:11:56 yes I think he said he had to leave 1:12:01 at this moment but he heard everything you said for that 1:12:05 it's been very interesting to hear your you too hump us 1:12:11 so 1:12:15 I have to go to thank you very much. 1:12:19 All right. Thank you as always for being here. 1:12:21 Please come again soon. 1:12:23 Moonset where you provide such a technically sophisticated conversation with Paul and 1:12:29 Hampus. Thank you both for the conversation. 1:12:33 People like you who are very careful thinkers 1:12:35 are providing a valuable service. 1:12:39 Take care. 1:12:41 Well, this has been Drivechain Talk. 1:12:43 We've had a great conversation today. 1:12:45 Thank you everyone who spoke. 1:12:47 Thank you to the listeners, the listeners who listen live, as well as the listeners who 1:12:52 listen on demand. 1:12:54 LayerTwo Labs hosts 1:12:55 Drivechain talk Twitter spaces twice per week, every Monday and Friday, 1:13:01 in the morning, and in the morning if you're living on the West Coast, 1:13:07 in America. 1:13:09 everyone is welcome to take part in the Drivechain movement. 1:13:12 drivechain which is Bitcoin improvement 1:13:15 proposal 300 and 301, would make Bitcoin sidechains more peer -to 1:13:21 -peer. It would potentially provide enormous value to Bitcoin 1:13:26 hodlers who want to see the price go up, Bitcoin miners who want to 1:13:32 see transaction fee revenue 1:13:36 Bitcoin developers want to see an increase in 1:13:41 extensibility to build an experiment on Bitcoin in a way that 1:13:47 creates value for Bitcoin without risking changes 1:13:52 to the main chain. 1:13:55 So you can learn more about this complex, very interesting idea called Drivechain 1:14:01 by visiting layer2labs.com, by attending our twice weekly Twitter spaces, 1:14:07 by visiting our Telegram group where over 700 people have joined to take part in the conversation there. 1:14:16 You can find the Telegram group in our Twitter bio link, as well as going to drivechain.info, 1:14:23 that's drivechain.info, and then in the links, you can find the Telegram group link. 1:14:31 We also have YouTube videos, many of them at our YouTube channel. 1:14:37 And there are more resources for you, such as if you're technically competent, 1:14:41 you can download the Drivechain software and run the node and participate in the testnet. 1:14:47 And you can read the BIPs, and you can read the code. 1:14:50 The code is currently being rebased by an extremely experienced Bitcoin Core developer, 1:14:58 who is rebasing the code and will do a pull request to include Drivechain in Bitcoin Core. 1:15:08 This is a powerful idea, eight years in the making, and we're thrilled that it has the support it has today. 1:15:16 So many noted Bitcoiners have voiced support for Drivechain. 1:15:20 There are too many to name, but some of the people who speak very positively about Drivechain include Adam Back, 1:15:27 the co-founder and CEO of Blockstream, Fiatjaf, the creator of Nostr, 1:15:34 Hampus, who is speaking today with us, Michael Tidwell, the co-founder of the Atlanta Bitcoin Conference 1:15:42 and founder of the Atlanta BitDevs, and is also a VP of infrastructure at Zebedee, 1:15:49 and SuperTestNet, and Andreas Brecken, and Sergio Damian Lerner of Rootstock, 1:16:04 and Bruce Fenton, Eden Yago, Guy Swan, John Light, and Brad Mills, Eric Wall, Nick Carter, 1:16:18 and many, many others. We could go on for a long time. 1:16:21 Many noted Bitcoiners appreciate the enormous potential that sidechains can bring to Bitcoin. 1:16:27 Sidechains are all about preserving Bitcoin's monetary policy, 21 million units of money, 1:16:36 but unlocking an infinite amount of software potential. 1:16:41 That's what sidechains are all about, more innovation on Bitcoin without altcoins being minted. 1:16:50 So as Adam Back has said, it's all about innovation maximalism, but altcoin seniorage avoidance. 1:17:00 We'll see you next time. Our spaces are every Monday and Friday. 1:17:03 The next one will be this Friday. 1:17:06 Bring your questions and comments, and we'll have another great conversation. 1:17:11 Thanks all.
