{ "episodeId": "SLP465", "speakers": { "stephan": { "name": "Stephan Livera", "role": "host", "tag": "STEPHAN" }, "stephan_livera": { "name": "Stephan Livera", "role": "guest", "tag": "STEPHAN" } }, "segments": [ { "speaker": "stephan", "time": "00:09", "start": 8.57, "text": "Hi, you're listening to Stephan Livera podcast, a show about Bitcoin and Austrian economics brought to you by Swan Bitcoin. Now, Swan has a new offer I'm excited to share with you. For those of you who are US residents or taxpayers, Bitcoin is generational wealth and you can secure your bright orange future with the Swan IRA. It's real Bitcoin, no taxes. Swan offers both traditional and ro- Both IRA options to best fit your needs. You can create your IRA and start adding Bitcoin in less than one minute. Transfers and rollovers are available and Swan's Bitcoin experts will get you set up with no transfer fees and no minimum balance requirements. This is real Bitcoin, not an ETF or other derivative. Get the real thing and get it at Swan. Go to swan dot com slash IRA for details. Mempool.space is my favorite Bitcoin explorer and I use it regularly when I'm about to target the fee for an on-chain transaction. Mempool.space is a A comprehensive Bitcoin explorer that allows you to see various as-aspects of the ecosystem, whether that's the mempool, the blockchain, or second layer networks like the Lightning Network. With mempool dot space, you don't have to trust a third party. It's free and open source software, you can host it, you can run it yourself, and you don't have to trust other people. Now, if you're with an enterprise, you can use mempool dot space with a customized mempool instance. You can have your company's branding, you can have increased API limits, and more. Go find out Enterprise. Are you ready for something big? BTC Prague is coming June eighth to tenth, so make sure you take out your diary or your calendar, mark those dates, look up flights, look up hotels. This is going to be the biggest Bitcoin event in Europe, so if you're in or near Europe, I really strongly recommend you come along for this one. They are looking to have ten thousand people coming along. Now, maybe three thousand or so of those people will be people who are already Bitcoiners, and let's say those seven thousand people might be newer to Bitcoin. So this is a fantastic opportunity to Bitcoiners, there is an awesome lineup of speakers. Michael Saylor himself is coming, as well as a range of other people. I will be there, I'll be one of the MCs, and I'm looking forward to seeing you there. Get your tickets over at btcprague dot com, use code livera for a discount, and of course, if you pay with Bitcoin, you get a further discount on your ticket. That's btcprague dot com, June eighth to tenth. Now, for the episode today, my guest is Calvin Kim. He is a BitMEX and HRF grant" }, { "speaker": "stephan", "time": "02:30", "start": 150.0, "text": "The UTXO set much smaller, so this could be important for making Bitcoin more accessible, making it easier for more and more people to validate Bitcoin and potentially have some privacy benefits also. So we talk about the ins and outs of this, as well as comparison with other, with other ideas like Assume Valid, Assume UTXO, and get into some of the details about UTXO proofs, UTXO nodes, and all kinds of stuff. So I hope you find this one educational. Calvin, welcome to the show. Hi, glad to be here. Yeah, so I'm excited to chat. I think this is gonna be an interesting one for listeners to learn a bit more about Utreexo, Bitcoin scaling, and ideas like this. I know, you've been working on this for a little while. Can you just give listeners a, a bit of a background on yourself? Who are you and what are you doing in this" }, { "speaker": "stephan_livera", "time": "03:17", "start": 197.05, "text": "space? okay, so my name's Calvin, and, I'm currently working on the Utreexo projects, with the grants from BitMEX. Years now, I've been involved with the research of the project. Now I'm more-- at the moment, I'm more involved in the implementation of, utreexo into an actual Bitcoin node, and, in a few months, we're hoping to release something that, normal users can use. So I'm excited about that." }, { "speaker": "stephan", "time": "03:46", "start": 225.81, "text": "Fantastic. And as I understand, this could help make it easy for people to use Bitcoin in ways that maybe can reduce the download size and reduce their bandwidth requirements. but we'll get into some of the details. So I guess let's just start high level. W-what is Utreexo?" }, { "speaker": "stephan_livera", "time": "04:03", "start": 243.38, "text": "Right. I want listeners to take away one thing. Utreexo is just a fancy Merkle tree. Okay. It's just a fancy Merkle tree. And if, if I go into a little more detail about that, so let's just start from the beginning and let's just talk a little bit about Merkle trees. How I would like to look at Merkle trees is it's just a black box, and if I could put in, element, items to, to this black box, and then it'll generate something, it'll generate results, and if I keep that result, people can prove to me that this item existed in, in the, in the set. So, I guess an easier example would be like if there's an event, let's say there's a guest list, and if there are four people on the guest list, what I can do is I could make a Merkle tree out of that, and then I could only keep a very, compact summary of, of the guest list And each of the guests can prove to me that they're actually on the list. So if it's like a guest list of Alice, Bob, Carol, and David, Alice can prove to me that she's on the list, but I'm not keeping the entire list. So normally what you would do is you would have like, on a piece of paper or something, it's like Alice, Bob, Carol, David, but, I wouldn't, I wouldn't necessarily keep all those four elements. I just keep this one compact summary, and Alice, and List. And I can verify that proof and just check that, okay, this person is indeed on this list. So that's something a Merkle tree can do, and this is really useful for, well, in Bitcoin it's currently used to, summarize, compactly summarize the transactions in, in the block, and we commit like this compact summary into the block header, and that's how we know, okay, this is, these transactions in this block are indeed, connected to like this proof of work. And so, so that's like, Merkle trees, that's how it's being used in Bitcoin currently. so I said utreexo is a fancy Merkle tree. Why is it fancy? so it's fancy because it does two extra things. It allows you to add new things to, to the, to the Merkle tree, and it allows you to delete, things that already existed. So, going back to the example of like the, the guest list, so it's like Alice, Bob, Carol, and David. let's say I also wanna invite, Stephan as well. Like, I think he's kinda cool. So I want him, I want him in the party. And so, with, with the Merkle tree, you would actually have to recalculate the entire thing. So, so thinking of Merkle tree as a, as a black box, now we have to get, five, five elements like Alice, Bob, Carol, David, plus Stephan into the, into the black box. So To add things or to delete things from the list, with the typical Merkle tree, you'd have to have the entire thing again. With utreexo, you don't have to do that. You just need the compact summary, and only with the compact summary, we can still add and delete things. So, with utreexo, if we were to use the guest list example again, but with utreexo, we don't need to do it all over again. We just need to get, get our compact summary and then add Stefan to it. The list." }, { "speaker": "stephan", "time": "07:26", "start": 446.16, "text": "Right, so we can think of it like the compact summary plus the differences rather than recomputing the entire thing. Yes." }, { "speaker": "stephan_livera", "time": "07:33", "start": 452.54, "text": "I would love to have a whiteboard and go over it, but, it's kind of difficult to do that. Yeah," }, { "speaker": "stephan", "time": "07:37", "start": 457.08, "text": "yeah. Yeah, sure, sure, yeah. But I mean, let's, let's try to put it in simple terms. So, I guess today, when you run your Bitcoin node, you know, today it's probably over five hundred and fifty gigabytes. Now, there is a thing called pruning. people can That they are holding what's called the UTXO set, the unspent transaction output set. Right Everything ever, then let's say, you know, the full node, like prune node, and then like a UTXO node, if you could explain that for us." }, { "speaker": "stephan_livera", "time": "08:35", "start": 514.9, "text": "so a Bitcoin node has like different modes per se. so you could be an archival node and have the entire history and have the entire blockchain and also have the UTXO set. So that's one thing you can do. the UTXO set being all the currently available bitcoins that are, that are, that can be spent. but what you also can do is you could just delete the historical blocks from your, your computer, your node, and so you could only keep the UTXO set, and, and you could still validate new, new blocks that are coming in because you already know which bitcoins are available to be spent, and that's all the data you would need. utreexo takes this a step further and says, so we're, we're now shifting the burden. So, let me get, let me get into this, example. So I l- I like the guest list example. So, Alice, Bob, David, Alice, Bob, Carol, and David. Before, i- like currently, a prune node keeps all of the, all of the list. So if we were to imagine like Alice as utxo one, utxo two, utxo three, utxo four, I have to keep everything in order to verify new tr- new transactions and new blocks. what utreexo does is, I don't want to keep your, like your transaction. I don't wanna keep that. You prove to me, I, I only want to keep the compact summary. You bring me the proof, and you prove that you are indeed in the utxo set. So it, it is a shifting of the burden from the node runner to the person that is, making the transaction. Th-what this allows us to do is, it-- this allows us to vary Again, like it compactly summarizes the UTXO set. So, as you said, it makes, so you can now have-- and no, that is a kilobyte because, one, we get rid of like the blocks because they're historical blocks, and then two, we can also get rid of any UTXO that we don't care about. If it's not my UTXO, I don't keep the proof for it, I don't keep the data, and so I just keep my things that I need to prove to others and other- Should prove to me that they exist in the UTXO set, or the, the coins that they're try-trying to spend exist in the UTXO set." }, { "speaker": "stephan", "time": "10:55", "start": 655.09, "text": "Yeah. So, yeah, so as we're saying, it's like this guest list or club example, and say, \"I wanna get in to the club or whatever, \"and I need to prove to you, \"Oh, hey, my name's actually on the list. Here's my proof, and you can then check. \"Oh, so you can see, oh, Stephan's, he's got, his name is on So could you also, I guess while we're here, it might be also good to spell out the difference or contrast with other ideas such as Assume UTXO or Assume Valid. If you could explain, I think, yeah, the Assume UTXO, is there any relation? How are, how are these ideas different?" }, { "speaker": "stephan_livera", "time": "11:36", "start": 696.14, "text": "so Assume UTXO is, i-i-it's related to Utreexo, it, it fits in well with Utreexo, because with Assume UTXO, what you would do is, in the binary, in the Bitcoin Core soft- Offer that you download, it has a, it has the root that is the of the UTXO set. So there's a compact summary of the UTXO set at a certain block, already there for you, and you sort of assume it's valid because it was included with the binary. you're, you have the option to validate from zero to that assumed UTXO set, but what that assumption allows you to do is, it start immediately from the tip, a-and that's really the advantage that is Assume UTXO has, because if, if a new user wants to start accepting, transactions right away with Bitcoin Core, previously they had to sync up and, you know, Bitcoin Core will tell you a message, you know, we're not at the tip, any bitcoins that you received now, it's probably not safe for you to accept them. But with Assume UTXO, there's, there's a small assumption, but it allows you to verify new blocks that are coming in." }, { "speaker": "stephan", "time": "12:40", "start": 760.34, "text": "So just to clarify, as I understand, Assume Valid is already in Bitcoin Core today, yes listeners, so assume valid is generally it's on by default. Now you can turn that off, it's like a flag, you can-- I think you can do assume valid equals zero, and then your Bitcoin node will, will validate all signatures since genesis versus if you have it on default, I think it validates from like six months ago, where that, wherever that snapshot was, right?" }, { "speaker": "stephan_livera", "time": "13:10", "start": 789.6, "text": "So, yeah, assume valid is something where, because these blocks are very, like, they're very historical blocks. There like a couple years in the past, and so, we-- so it's saying, let's just take out the most ex-expensive part of block validation, which is the signature validation. So you do everything else, but you don't validate the witnesses, the signatures, and, that's what assume valid is. Assume UTXO sort of different, you're still assuming, but you're just given like this snapshot of a UTXO set at, at a certain block, and you can just start, a-accepting new blocks from that height on. Assume, well, utreexo, you could do sort of like, assume utreexo, not, not a utxo, assume utreexo, where it, it fills the gap or, or, or it, it's-- with assume utxo, there's still the inconvenience of having to download the utxo set. So let's say, so, so if there is an assume utxo like commitment at block, seven hundred thousand, I still need to download the utxo set at that block height. So that's gonna, that's like four or five gigabytes, that's gonna take me a little while. Assume utriexo, because since it's like a kilobyte, just start right away. It's included in the binary, and so there is no waiting, you just start right away. A-and that's, that's, that's sort of the idea that we have, it's like, hey, we could g-take assume utriexo a step further and have like assume utriexo, where it's even more convenient for users that are getting started." }, { "speaker": "stephan", "time": "14:45", "start": 885.43, "text": "Yeah, and Where you could have that new user start and be able to do, make and take transactions straight away, but in the background, that computer, it-- let's say it's a proper computer, it can still be downloading the full blockchain, so it can kind of give you a quick start way that still eventually gets you to the full validation that having a full node or even an archival node, if you wish. So I guess that's one idea that some of the-- one way that these could be built out." }, { "speaker": "stephan_livera", "time": "15:17", "start": 917.09, "text": "Right, right." }, { "speaker": "stephan", "time": "15:18", "start": 918.01, "text": "So when it- When it comes to the proofs, then, could you talk us through that process a little bit? Because I guess listeners might be thinking, \"Hang on, how do I prove to you?\" You know, like, how's the software working such that we prove to each other? You know, are there going to be special utreexo nodes and clients in order to work in this utreexo context? Because maybe the rest of the network doesn't know about or doesn't care about that, right?" }, { "speaker": "stephan_livera", "time": "15:42", "start": 942.42, "text": "Right. so there will be, special utreexo nodes. they will have A bit that says they understand the UTXO, so, protocol rules. And, with, with these nodes, you will-- So if you are a UTXO node, you will receive the block and the transaction as normal, but you will receive the proof along with the, with the transaction or the block. So there, there is a, a trade-off in that you are using more bandwidth. So, so it's, it's not free, but I-- but we think it's a very good trade-off because, the, the advancements in, like, the internet speeds, like, it's just, it's there, we just need infrastructure for that, and, w-w-whereas like, disk IO, like the disk speeds, they're not really improving that much, or, or like the storage, I guess, costs I can get in, so, so there's, there's a couple things that are juggle, I'm just juggling in my head, and, I can get, I can get into that. Yeah, yeah." }, { "speaker": "stephan", "time": "16:46", "start": 1005.75, "text": "But if you could just contrast then for people, let's say, I guess what you're getting at is the difference between running just a standard archival full node versus running that plus also being Utreexo aware. If you could explain that for us, maybe, and then we can go from there." }, { "speaker": "stephan_livera", "time": "17:02", "start": 1021.72, "text": "okay. So In the UTXO setting, you would have, okay, okay, so, you can have UTXO notes that are actually archival notes. You can do that because UTXO, the only thing it applies to is the UTXO set. So if you choose to, you can keep the entire history of the blocks but choose to prune the UTXO set. So you would still be like a four hundred, five hundred gigabyte node. Except you wouldn't have the, the UTXO set that's like, forty-five gigabytes. What you can also do is you could do like a pruned UTXO node where you get rid of the historical blocks and then you also get rid of, and you also keep the compact summary of the UTXO set, and that's where like the really small nodes come in." }, { "speaker": "stephan", "time": "17:53", "start": 1072.98, "text": "I see, yeah. And so, yeah, then could you explain for us the, yeah, what that would look like if you wanted to have just a really small, you know, this few kilobytes The utreexo pa-component of it would be the few kilobytes, which is the, the proof, and then would you still need to be downloading new blocks as they come in, or would you be fully operating in like a utreexo way?" }, { "speaker": "stephan_livera", "time": "18:16", "start": 1095.59, "text": "Oh, so you would still be downloading new blocks as they come in, so blocks and transactions you would get as normal, except after you validate them, you can just throw them away, just like how normal proof notes would work." }, { "speaker": "stephan", "time": "18:29", "start": 1109.3, "text": "I see. So it's like a download, validate, and then throw it away. Yes. Because what I would do is check, oh, are there any transactions I care about, or are there any transactions that, you know, are coming to me? Obviously, I wanna keep those, and then I'll throw away the rest. That's the model. Right," }, { "speaker": "stephan_livera", "time": "18:43", "start": 1122.55, "text": "right," }, { "speaker": "stephan", "time": "18:43", "start": 1122.75, "text": "right. So it's just-- Yeah. Prudent nodes on steroids. Okay. Gotcha. And so, yeah, so there's all kinds of like, I think this could really open things up in terms of how many people" }, { "speaker": "stephan", "time": "18:59", "start": 1138.82, "text": "Bitcoin node, right? And we know, you know, if you look at the numbers, it's probably something in the, I mean, at a guess, tens of thousands, fifty thousand, something like that, probably around the world today, and we're, we're talking You know, maybe forty or fifty million people today who hold some UTXO. So it's kind of like we're talking a small number of people, and so potentially this could increase the availability or the access for that. So could you elaborate" }, { "speaker": "stephan_livera", "time": "19:24", "start": 1164.15, "text": "a bit on that? so yeah, that's one of the benefits that, I think UTXO, brings to Bitcoin users. there's, there's several benefits I would like to get into, but the, the one is that, hey, nodes are now easier to run. It's easier to- To run, because one, you could do like an assume utreexo thing and just get started, right away. two, just the fact that the node is so small allows us to put nodes where they really couldn't live before. and one of the ideas that we've had was, hey, you could actually feasibly have a node running in your browser as a browser extension. So you could just have, in your, in your Chrome or Firefox, you would just download a browser extension and that's your node. And every time you use your browser, your And so you could feasibly do that. another thing you could also do is have, have a node that is bundled with the wallet client. And so you could have something like Blue Wallet, but, but Blue Wallet is downloading actual blocks and it's actually veri-verifying. And, i-i-it's small enough that it could fit inside, you could-- So with the current Bitcoin set, with the b- sorry, with the current Bitcoin UTXO set, it's like four to five gigabytes. It's not feasible To have that as a browser extension or, or like have it embedded in some app. with utreexo, you can. And so that's one of the, that's one of the advantages that I see that brings to Bitcoin users. And another thing that I do want to mention is that with utreexo, it's possible to have not a node, but a client software that validates blocks. So it's a fully validating, client. Suffer. So we know, so as you've said, there's only so many people running nodes, and if you don't run a node, someone's gonna have to run a node for you, and that takes away the, the, the qualities that we like about Bitcoin. And so if you really want those qualities, you need to run a node. But so the idea here is What if you can validate blocks and you can validate transactions, so you won't necessarily relay them, so you won't be helping others, but can you just validate them so you, you, you, you gain the properties of Bitcoin that, that really is useful? And with UTXO, you feasibly can, and so you wouldn't necessarily be Broadcasting transactions or broadcasting nodes, you would only be listening from, it could be a server or it, it could be from, different nodes, like it could be a P2P network, but you can get blocks and get transactions and validate them, and I think that's, that has a real use case, and I think that will bring, the security benefits and the privacy benefits of running a node into people that really can't Either, you know, they, they don't have the technical technology, they don't have the knowledge to do so, or they're just not bothered to do so." }, { "speaker": "stephan", "time": "22:29", "start": 1348.63, "text": "Right. And so coming back to that example with a browser utreexo node, yes, would that also work in a Lightning context? Like, can-- like basically, I guess the question I'm asking is, can utreexo work alongside a Lightning for a Lightning user?" }, { "speaker": "stephan_livera", "time": "22:43", "start": 1363.38, "text": "I have talked to a few LDK people about this back in, Atlanta last year. At the, at the, Atlanta conference. Tapcon. Yeah, the, at the Tapcon, and, I'm not quite familiar with, the, the requirements that lightning nodes have from a, a Bitcoin node. but what I did her-- what I did hear was that, like, like something like LDK has the option to connect to, like, an Electrum background. So if you have some sort of, like, Electrum server thing running, you can connect LDK to that, and then you'll just have, like, a, a Release that we have, the release that we're doing in a few months, what it will include is the option to have an Electrum server going for you. And so it'll be something like an Electrum personal server where it won't, it won't, index every single address in the world. It's just, it'll index your address. So you'll give it like your, your pub key, your, your extended pub key, and it'll, it'll generate addresses and it'll keep track of your addresses. And so feasibly- Yeah, so you could, because it, it, it will support the, it'll, it'll have Electrum support out of the box, you can connect, your Lightning, Lightning nodes to it or like, like something like LDK to it and have, have it working that way. Right. I'm not, I'm not quite sure how, yeah, so, so my, my Lightning knowledge isn't good enough for me to answer, hey, like, it, it will just work with Lightning or not," }, { "speaker": "stephan", "time": "24:14", "start": 1453.6, "text": "yeah. But I mean, it might make more Yeah, you just wanna be able to quickly, I guess in this example, if, if you're using, if you're trying to have it with a browser, you might not really want the key, the private key is in the browser, but it might be like a watching thing or it might be, yeah, like a way for you to- in the same way that you have like Specter or Sparrow or one of these things where the hardware device is, you know, it's separated from the, you know, but the wallet or the applic- let's say the transaction viewer is," }, { "speaker": "stephan", "time": "24:51", "start": 1490.8, "text": "it could be in a browser, let's say. Right The real story for climate. So," }, { "speaker": "stephan_livera", "time": "25:06", "start": 1506.21, "text": "so there, there is a catch to like the kilobyte thing. the kilobyte only, on-is only for the UTXO set. So like the UTXO set that was four to five gigabytes, it's now a kilobyte. the real kicker, or the real, the real, what the real problem is that The, the headers are bigger than a kilobyte, like the, the entire headers that you would download, that's bigger, like your peer database, like you keep a database of like which peers you're connected to, that's bigger than a kilobyte. if you have like an Electrum personal server going, you're, you're keeping the relevant transactions and the, the relevant, information with them, and that's way bigger than a kilobyte. And so there is a cache, yeah. And so the node itself- Itself, yeah, it's a kilobyte, but if you want to do like, I guess, stuff like wallets or, or be able to actually use the node so that you can, connect your wallets to it, yeah, it's gonna be bigger than a kilobyte. I see," }, { "speaker": "stephan", "time": "26:07", "start": 1566.51, "text": "yeah. So where do you see the most practical uses then? Is it mobile users? Is it, you know, just random web users? Like, where, where is the most practical use case going to be for utreexo?" }, { "speaker": "stephan_livera", "time": "26:18", "start": 1578.32, "text": "I'm really excited about like the client side Bitcoin validation part, and so, 'cause we don't really have that at the moment, it's like, hey, go run a node, but, but I can't tell my mom to go to run a node. I don't, I don't think she'll be able to. It, it's very difficult for, for-- there, there are people that would benefit a lot from the properties that Bitcoin has, but you, you don't get those benefits if you don't run a node, and, and that's a real k-- deal killer for a lot of people, a-and I think that's stopping a lot of people from, from actually taking advantage of this, of the properties that Bitcoin has. And so I think the, the, the client aspect of utreexo is something that I think is really exciting and, and something that I think will help a lot People." }, { "speaker": "stephan", "time": "27:05", "start": 1624.92, "text": "Okay, great. And so let's talk a little bit about the trust assumptions here. So could you help us understand what kind of trust assumptions a utreexo user is making versus not using utreexo?" }, { "speaker": "stephan_livera", "time": "27:19", "start": 1638.63, "text": "so, you know, utreexo is a full node. I think people sort of mis-- like confuse this a lot and think utreexo is like a SPV thing. It's a full node. It, it, it has the same security as a full node, but it's- Consensus-wise, like code-wise, it, it's a little different. So, normal Bitcoin node, when it stores the UTXO set, it, it uses something called LevelDB. So it uses a database and it uses something called LevelDB. so consensus is sort of defined Partly by LevelDB. And I, I'm not saying that there is, but if LevelDB has a bug, then, and let's say some tran- some UTXO doesn't exist, then that is consensus by definition. with UTXO, you don't have that assumption, but you have the, like, the UTXO proof model assumption. So it's, it's, it's different. so you're not I wouldn't say you're necessarily giving up any sort of security. You're still a full node, you're still validating every single block and every single transaction that you're getting, except that if there is a consensus failure, there's gonna be a split. And so that, that is something that users-- That, that is some-- That is a risk that users will have if they run" }, { "speaker": "stephan", "time": "28:38", "start": 1718.08, "text": "utreexo. Yeah. And to be fair, that same ri-- That would be the same risk as if you are running Libbitcoin or BTC-D or Knots or something like this, right?" }, { "speaker": "stephan_livera", "time": "28:48", "start": 1727.77, "text": "It'll Versus if you're running like an older version of Bitcoin Core. So if you're running like Bitcoin Core twenty-one, it's different from twenty-four, and so you could argue that, yeah, I, I think it's fair to argue that, hey, like this is much bigger of a change than different versions of Bitcoin Core, but that there is a risk that is, carried when you switch versions or, or have run a different node software or something like that." }, { "speaker": "stephan", "time": "29:17", "start": 1756.86, "text": "This show is also brought to you by CoinKite dot com. CoinKite dot com make a range of Bitcoin hardware and accessories, most notably the Coldcard Mark IV. So the Coldcard is an excellent device, I find it really reliable, and particularly important is the idea that you don't have to phone home to use it. You can just plug it into the wall, you can spin it up, you can generate your seed words, you can then use it with wallets like Specter Desktop, Sparrow, Electrum or others, and you can use it in all kinds of configurations. There's all And configurations that you can use to help secure your Bitcoin for the long haul. So go to coinkite dot com, you can find a range of gear there, whether that's the cold card or the tap signer or other material, and get a discount on your cold cards with the code Livera. Build on L2 is a community initiative for Bitcoin builders by Blockstream. This is particularly important if you are interested in core Lightning or the Liquid Network. There's a range of technologies that they are discussing on the community forums. You can see discussion about things like confidential transactions, miniscript, liquidity ads, greenlight, and all kinds of stuff. This is an interactive community platform where if you are a builder, a product manager, a designer, an engineer, or just an interested person, you can find out more. There is a mentorship program, there are events Events as well as discussion forums to learn alongside other bitcoiners. So go sign up, it's over at build on l2 dot com. And lastly, Unchained Capital. Unchained Capital provide security services to help you secure your bitcoin, and they do it in a way that's secure, transparent, easy to use, and sovereign. You can create a multi-signature vault where you hold two keys in different locations, and Unchained hold the third key. They can even help you, walk you through the process with a product called Conse Onboarding. So you can buy this package, you can pay upfront, they'll ship you the devices if you need them, and they'll do a call with you to walk you through the process of learning how to become self-sovereign and remove single points of failure in your multi-signature setup in your Bitcoin security setup, and this can give you that additional peace of mind to know that one mistake isn't gonna totally screw you over. So go to Unchained dot com, click Concierge, and use code Livera for a discount there. And now back to the show. So I'm also curious, are there any interoperability concerns? Like, could it ever fall out of sync with Bitcoin Core? I guess that's what you're saying, like theoretically it could fall out of sync with Bitcoin Core, and then those users could be like, kind of up the creek without a paddle, theoretically, of course. I mean, a-as another example, could we see what happened? I'm sure you were seeing, what happened with, BTCd and Barach with those, LND transactions that, as I understand, it was like the way the valid transaction in, to be in a block or in a transaction. So could a similar thing like that happen?" }, { "speaker": "stephan_livera", "time": "32:04", "start": 1924.13, "text": "I'm not saying that there is a bug, but let's say there is a bug in the utreexo implementation, like the actual, like the Merkle tree side of things. If there is a bug there and it says that, hey, like this proof for a block is invalid when it, in reality, it really is valid, but it's just an implementation bug. Yeah, it, it's something like that could happen and, for could happen. But I wanna say it's, it, that, that is the same risk you carry if you're running something like Libbitcoin, like BTCDBcoin. It's just there, there is the risk of different implementation, like different node implementation, but there, you're not really Fundamentally giving, you're, you're still a full node, you're not, you're not, you're not becoming an SP node." }, { "speaker": "stephan", "time": "32:45", "start": 1965.23, "text": "Yeah. Gotcha. Yeah, yeah. And I think that, I think that's fair, and I think, it's, Yeah, I, I think it'll be interesting to see if, if, if utreexo enables new kinds of users or clients, like you said, a validating client idea that, let's say our mums and grandmas could be using Bitcoin in a more self-sovereign way than, let's say, you or I or our, the listeners of this show maybe are probably more inclined to be able to, or at least be able to run their own thing and do their own thing. So, yeah, I, I think that'll be interesting. Aspect. So in order to be a utreexo node, we're still relying on enough people who are running like proofs, right? Or enough people who are serving up, like, do we need there to be enough, let's call it like utxo, sorry, utreo servers, let's say, or it doesn't really matter." }, { "speaker": "stephan_livera", "time": "33:38", "start": 2017.96, "text": "We call them bridges, because- Bridges, okay, yeah. So the proof, someone needs to provide the proof and, those- We can sort of soft fork in that and so say, \"Hey, the proof needs to be included in the Coinbase transaction.\" We're not going that. We're not gonna do a soft fork. So no soft works, but you need these bridge nodes that take in blocks from the existing Bitcoin nodes currently and make UTXO proofs for them. And so we need these bridge nodes to be, to be running. And so if you're like a UTXO node that is like a kilobyte, we call them compact state nodes. And so if you're, if you are this compact state node, then you need these bridges up and running to be able to validate new blocks. So if, if a new block- Block is there and there are no bridges at all, then, unfortunately you won't be able to verify that new block. So there is, new data availab- of data availability, Sort of a trust assumption. it's not different, well, in my opinion, I don't think it's different from the assumption that a prune node has versus an archival node. So, let's say a prune node, it, it- Something goes wrong and, and you need to reindex, you expect there to be enough archival nodes for you to be able to do that. And so I, I don't think that's a different model than the current one that we have today versus archival and, prunes. versus like, so archival nodes would be like akin to bridge nodes and like the prune nodes would be, akin to, compact state nodes. one thing I should mention is that these bridge nodes can also be pruned. So you could be an archival bridge node or you could also be a pruned bridge node. utreexo only applies to the utxo set. So when I say bridge, you are a bridge in the sense that you're bridging the, The UTXO sets, and the UTXO people, not the, the pruned or archival sense." }, { "speaker": "stephan", "time": "35:49", "start": 2149.26, "text": "Right. I see. Yeah, it's like, confusing. Yeah, you're right. So basically the point we're talking about here is the distinction between the UTXO set and the blocks. Because you can be pruned and not care about the old blocks, but the UTXO set is a requirement regardless of how, like, if you wanna use Bitcoin, full stop, you need, you need to access that, you need to use that." }, { "speaker": "stephan_livera", "time": "36:11", "start": 2170.56, "text": "So we're introducing two extra sorts of node modes. So right now there's really only two, right? Archival, pruned. you could be a compact state node that is archival, and you could also be a compact state node that is pruned. You could be a bridge node that is archival, and you could be The original that is pruned. So, so four new extra modes of" }, { "speaker": "stephan", "time": "36:32", "start": 2192.09, "text": "Bitcoin. Gotcha. And, I mean, of course, we're early days right now. Could you tell us a little bit about what state this is in today? And, and just explain a little bit about where we are today." }, { "speaker": "stephan_livera", "time": "36:42", "start": 2202.01, "text": "Okay. So, some of the stuff that I did early on, was-- There were a lot of research stuff going on as well. And so we've figured out, new algorithms to have, like- To be faster and to, have less, to, to require less bandwidth for the proofs, so, so smaller proofs. And that part, like the, the, the Utreexo, like the Merkle tree stuff, is all, it's all good, we're good to go. And I haven't wrote up a spec for it, I haven't wrote up a bit for it, but we are able to write a bit for it, everything is complete. what isn't complete is the P2P layer part, and so how, how like the messages would work. So how would a block message look like with Utreexo proofs? How would a transaction message look like with Utreexo proofs? that part hasn't been fully fleshed out yet, and that is what we're still working on. but besides that, everything is really, complete and good to go." }, { "speaker": "stephan", "time": "37:44", "start": 2264.3, "text": "Okay, yeah. And so this is, I think I saw an email on the Bitcoin dev list. You said using service bit- Twenty-four. So this is the idea to start in the test, you know, test net and signet, and so the idea is eventually, like, once, once it's all good and let's say it goes to main net, all the nodes are just out there and they can easily talk to each other just through the peer-to-peer protocol of Bitcoin in a decentralized way. That's the, that's the goal, right? Yes," }, { "speaker": "stephan_livera", "time": "38:09", "start": 2289.42, "text": "that is the" }, { "speaker": "stephan", "time": "38:10", "start": 2289.87, "text": "goal. Okay, great. so in terms of, Timing, could you tell us what are you looking at in terms of like having, you mentioned a binary, yes, that's gonna be available for people?" }, { "speaker": "stephan_livera", "time": "38:21", "start": 2301.3, "text": "Actually, we could have just released something, months ago, but we're just like, okay, it's just a node, it's not doing anything for users, it's, it's not like that you could- Connect your wallet to it or, or whatever. And so one of the things that we were talking about was that, hey, we really need some sort of a wallet for this. And so what I've been working on for the past few months is this Electrum server that, that connects to a watch-only wallet with the binary. So when you start up the node, it'll ask you for like, a standard pub key, and if you give it that extended pub key, it'll, it'll take that in and then it'll create like this Electrum personal server. And, you could connect your any sort of wallet that uses the Electrum protocol. So I've been testing on Nunchuk and the Electrum wallet. There's some kinks still to be worked out, but Most things are working, and so we're not quite there to the finish line yet, which is sort of disappointing for me to say, but, we're getting very close. And it's, it won't be something like, \"Hey, like, this is out there and, no, it's just a node, it doesn't do anything useful.\" i-it'll be something where, \"Hey, like, if you run this, you'll, you'll obviously have to be a power user 'cause it's just the binary, and, you'll have to configure like," }, { "speaker": "stephan_livera", "time": "39:44", "start": 2383.95, "text": "Really play around with this. And so at the moment, I've had, Cygnet connected and I've, I've been using the Nunchok wallet and the Electrum wallet, and I've been able to send broadcast transactions, receive bitcoins, a-a-and, you know, fully b-be able to prove them. And so Well, to, to be fully able to validate them, sorry. And so it's working, I'm excited, excited to, to get these in the hands of users soon." }, { "speaker": "stephan", "time": "40:08", "start": 2408.16, "text": "Yeah. And one other question, when it turn-- When it comes to putting in an extended pub key or xPub, can you-- Can we also do like multi-signature? So let's say I have a-- Let's say I'm running a two of three multi-signature, do I need to put in all three public keys or like how would, how would that work?" }, { "speaker": "stephan_livera", "time": "40:23", "start": 2423.31, "text": "You would need to put in all" }, { "speaker": "stephan_livera", "time": "40:29", "start": 2429.48, "text": "Had the time to deal with that yet, so it's not supported. Only single sigs are supported, but," }, { "speaker": "stephan", "time": "40:36", "start": 2435.74, "text": "but eventually the, the goal would be that, that you could do that kind of thing. Yes, yes. Okay, gotcha. Yeah. Okay, cool. So I guess what we're seeing is this could be like an Electrum personal server model, and so as we said, we, as we said, it's an availability concern. So you know, it's not a trusting concern, it's a data availability of, are there enough bridges or, so I Understanding this correctly, if we wanna operate in a utreexo model, let's say I'm just an average user and I'd-- you know, I, I'm not really able to run a full Bitcoin node today, and I wanna-- I'm like, \"Oh, hey Calvin, this sounds cool. Let me do this utreexo thing. Let me be a compact state node.\" What I'm relying on is there being enough bridge nodes, right? That's basically what it is. Yes. Yes." }, { "speaker": "stephan_livera", "time": "41:18", "start": 2478.17, "text": "Are there enough people running nodes so that I can get proofs for them? Gotcha." }, { "speaker": "stephan", "time": "41:26", "start": 2485.63, "text": "That want to run a kind of an equivalent of an Electrum personal server, that's the concern. It's just, as long as there's enough bridges, I presume you're going to run one and there'll be a few other, you know, enthusiasts who are running the bridge nodes to kind of be the, like the seeds to get, get it started or get people, you know, help people start. And then the goal is that more people can be a client-side validating or like a client, a validating client is probably the best term to use, right? Right." }, { "speaker": "stephan_livera", "time": "41:59", "start": 2518.88, "text": "Right." }, { "speaker": "stephan", "time": "41:59", "start": 2519.06, "text": "Great. Okay, great." }, { "speaker": "stephan_livera", "time": "42:01", "start": 2520.66, "text": "So, I, I, I, I should add one thing. I've seen this like data availability, availability concern a lot. And one of the things you can do to solve this problem is you could just software get in. And so you, you don't-- so you just make sure every node is carrying the proof and like have the proof inside the Coinbase TX. And so you can solve it by just forcing everyone to keep it if, if it, if the demand really gets The community" }, { "speaker": "stephan", "time": "42:30", "start": 2549.8, "text": "wanted that, and let's say there was lots of users who use utreexo compact state nodes, then maybe there would be a discussion in the community of, \"Hey, do we want this as...\" Because as I understand, it would only be a little extra data and a little extra computation on the full nodes, right? It's, so," }, { "speaker": "stephan_livera", "time": "42:48", "start": 2568.35, "text": "so, full clarity. It's not a little extra data, it's like" }, { "speaker": "stephan", "time": "42:52", "start": 2571.81, "text": "one" }, { "speaker": "stephan_livera", "time": "42:53", "start": 2572.69, "text": "point eight. So if, like, a block is two megabytes, the proof will be somewhere around one point points. I mean, it, it depends, but it'll be like one point three megabytes or something." }, { "speaker": "stephan", "time": "43:04", "start": 2583.66, "text": "Okay, gotcha. Okay, so it is, it is a rise or an increase in the bandwidth, let's say." }, { "speaker": "stephan_livera", "time": "43:09", "start": 2589.34, "text": "And, and, and the storage, yeah. Yeah. Yeah." }, { "speaker": "stephan", "time": "43:12", "start": 2592.08, "text": "So that's what the bridge node has to take on, let's say, so that the compact state nodes can have, can be served the data." }, { "speaker": "stephan_livera", "time": "43:20", "start": 2599.53, "text": "So, so I wanna make this clear as well. And so you could be a compact state node and be an archival node and have the proof stored for Bridge nodes, the only thing they do is-- well, you could be like an archival bridge as well, but bridge nodes, their role is to convert, like to-- so in a world without, if we started at genesis with utreexo, we wouldn't need bridges. But since we didn't do that, we need these bridge nodes to generate proofs for incoming blocks because Blocks are created without utreexo proof, so we need some, some, some of these nodes to create those proofs. And once those proofs are created, like CSNs can store, like the compact state nodes can store it. And so historic for historical blocks, you, you can either be a bridge node, you could be a compact state node and have the proof for that block. It's only for generating new blocks and, and, and new transactions. So it's only for generating proofs for new blocks and new transactions. Transactions." }, { "speaker": "stephan", "time": "44:23", "start": 2662.89, "text": "And one other thing I've seen, so, so some of the blog posts and things I've been looking at, it seems to-- Well, maybe this is just done for the sake of example, maybe you could help explain that for me. It's like showing at block six hundred thousand and block seven hundred thousand. Is there a reason for that, or is it just more like, in, in utre-- Let's say we're in utreexo world, are they generating a new proof every block, or is it only like certain big blocks and then they calculate a difference or" }, { "speaker": "stephan_livera", "time": "44:51", "start": 2690.85, "text": "how, how Like the BitMEX blog post, but, so yeah, there was a" }, { "speaker": "stephan", "time": "44:55", "start": 2694.83, "text": "plot, I think it was called" }, { "speaker": "stephan_livera", "time": "44:56", "start": 2695.74, "text": "out of order block validation. Yeah, yeah, yeah. so that was a fun researchy thing that I've did, during my first and second year of working on the project. And so, so, so to answer your question first, for every block, a proof is generated. But, but we also have the option to generate a proof at like every intervals of ten. So like at block ten, we generate a proof and, but we've generated proof a-and you as a compact state node have to cache things in between. So that's like a caching optimization isn't fully fleshed out. So, so there are also ideas that we have to reduce the, the amount of bandwidth that nodes have to, like But they have the burden, and so I think some of that might be that, might be related to that. But okay," }, { "speaker": "stephan", "time": "45:50", "start": 2749.5, "text": "yeah, that, that's probably my confusion. Okay, gotcha. Yeah, no, thank you for clarifying. Okay, cool. Yeah." }, { "speaker": "stephan_livera", "time": "45:54", "start": 2754.1, "text": "Yeah. So I wanted to get to like the out of order stuff, and so," }, { "speaker": "stephan", "time": "45:58", "start": 2757.64, "text": "yeah." }, { "speaker": "stephan_livera", "time": "45:59", "start": 2758.76, "text": "one of the fun things that we figured out you can do is if you have like these tiny states, like the tiny UTXO states, what you can do is you could just start validating blocks from that point on. So So like the, the, the, the UTXO roots we call, like the sort of compact, representation. If I give you the roots at block five hundred thousand, you can start validating blocks, you can start validating block five hundred thousand and one. So I could give you the roots at block hundred thousand, and you can validate block hundred thousand and one. And so what this allows us to do is, it allows us to, you know, validate blocks out of order, and this opens up to validating blocks in parallel. So in normal IBD mode, you could-- you, you have to start from genesis, you have to start from, zero, one, two, three, four, five, six, seven, eight, nine, and, and so on and so forth. But If you, so this also goes back to like, okay, so like, assume utreexo. So if we assume utreexo every ten blocks, so like, assume utreexo block ten, block twenty, block thirty, block forty, then we can parallelly validate all these blocks at once, and, and that has Potential to in, that has potential to massively inc- massively speed up IBD. And the, the blog post that I wrote up, I did benchmarks and, I forked a, I forked BTCd, and my fork of BTCd with this idea was able to sync faster than Bitcoin Core at the time, and was about sixty-three percent faster. So it's not really an apples-to-apples comparison because BTCd normally is much, much slower than Bitcoin core at, IBD, and so, you know, have the same thing in Bitcoin core, and it'll be able to dramatically increase, dramatically speed up how long IBD takes." }, { "speaker": "stephan", "time": "47:54", "start": 2874.38, "text": "Okay, gotcha. So this is like an extra, this is extra credit, right? This is kind of, s- separate from the base utreexo idea, right? Just to be clear what we're talking about, right? Right. Yeah. Okay, so, do you see any other, I guess, implications for the, you know, the People using more people, let's say lots of people start using utreexo, do you think that changes any other dynamic about Bitcoin or not really? It just means more people can validate." }, { "speaker": "stephan_livera", "time": "48:21", "start": 2900.86, "text": "The problem that I see today is that not many people are getting the benefits of, of, you know, being self-sovereign. Like the, the whole point of Bitcoin is that, hey, it's, it's, you can validate, it's like you have this, like the supply limit, and you can validate this limit. But if you're not running a full node today, you're not You're, you're trusting a third party to do that for them. And so you really, really want to run a node if you want to take advantage, full advantage of, of all the properties that Bitcoin, Bitcoin gives. And so what I think utreexo will allow people to do is, hey, you know, if you, if I want mom to have, like, like the, the take, you know, be, be self-custodial and be self-sovereign, hey, mom, go download this app, and the, the app is a wallet. But it doesn't, doesn't reach out to like a Electrum server and you give all your data to them, except what you would do is you would just download blocks as normal. You would have all the advantages, all, all the, all, all, all the advantages that you would get with the full node in that you validate everything, you have the privacy and, and those things. And so I don't see utreexo as something that changes fundamentally how, how people, perceive Bitcoin, but it, it, it brings the existing qualities of Bitcoin to more people." }, { "speaker": "stephan", "time": "49:50", "start": 2989.63, "text": "Yeah, that's a great way to explain it. And I think it is also worthwhile elaborating a bit on the privacy benefit, because could you, could you explain a little bit about that? Like, I guess today, if somebody is using a public server or, I guess, look, a lot of people today, they leave their coins with an exchange with The custodian, like that's like the worst of all worlds. Then maybe the next, then maybe the next step is people just get a wallet, and that wallet is calling out to somebody else's server. so I guess in a utreexo world, do you see privacy benefits for those average users?" }, { "speaker": "stephan_livera", "time": "50:20", "start": 3019.75, "text": "Yes, and that's because, so yeah, the worst case, you're, you're on Coinbase or any other centralized exchange, and they have all your information, the KICG, you, they have every, they know everything about you, they know, they know your face" }, { "speaker": "stephan_livera", "time": "50:36", "start": 3036.32, "text": "the, I guess like a step up from that is, you know, self-custodying your coins, a-and that's good because now, okay, Coinbase just can't, or like the centralized exchange just can't run off with your coins, that's good, but, but you still have like the privacy implications in that for most wallets, they just connect to a public Electrum server, and what you would do is you would give that Electrum server all the a-addresses and, and like all the, here is all the addresses that I control. Please tell me if I have coins And hey, okay, so it-- the server tells me I have coins, okay, please send me the transaction. And you're revealing a lot about you and- We've-- this is, this is also sort of a speculation, but like we know, like something like coinan-- like, like chain analysis is running a lot of Electrum servers because it allows them to track, it, it gives them extra tool, that's, that's an extra tool for them to, you know, break people's privacy and, and keep track of, like, who, who owns which address, this IP controls this, and, and, you know, a-and, it, it, it's very-- it's not good, i-i-in the privacy perspective." }, { "speaker": "stephan", "time": "51:45", "start": 3105.41, "text": "Yeah, so I think that's, that's probably an angle that you could really get out there and promote. You could sort of say, \"Hey, guys, look, many of you currently today are just using-- giving up your full privacy when you use Bitcoin, whereas if we have Utreexo, you might be more private from chain analysis and other surveillance entities out there.\"" }, { "speaker": "stephan_livera", "time": "52:04", "start": 3123.58, "text": "And I guess another thing that I could mention is that, Electrum protocol depends on SPV proofs, and so you only have SPV security. it means that if enough miners are dishonest, then they could, have a longer proof of work chain or, and then like they could fool you with that, they could, they could, potentially fork you off from the main chain. So, so you would be-- So, so at SPV proof, you're really trusting the miners, with, utreexo node, you no longer have that assumption because you're a full node. So you, you also get that additional security benefit." }, { "speaker": "stephan", "time": "52:34", "start": 3154.27, "text": "Gotcha. I'm also curious if- I don't know if you've run any benchmarks on comparisons of the overall bandwidth, so let's say to be a utreexo node or, in this case, I guess, a utreexo bridge versus merely being a Bitcoin archival node with, like, not caring about utreexo at all. I'm curious if you have any numbers for us or any-" }, { "speaker": "stephan_livera", "time": "52:56", "start": 3176.12, "text": "I don't wanna, well, I, I have concrete numbers, but, I, I don't wanna say they're final because there's a lot of optimizations that are ideas At the moment, that, that we haven't really got to implementation, we haven't really got to implementing them yet. And so at the moment, the worst possible during IBD is two X. So normally you would download like four hundred to five hundred gigabytes, with utreexo, you would be downloading like eight hundred nine to nine hundred, it's a little less than that, but it's like about two X. So that's like the maximum. It's like, hey, how, how worse will it get? W- how, how much worse will it get during IBD? It's like two X, when you're all synced up and when you're receiving transactions, the worst case is you'd receive-- so if, if receiving a normal transaction is like a hundred percent, you would be doing, four hundred percent. So, so let's say if like a transaction is, I don't know, a kilobyte, then it's like you'll be getting four kilobytes First case. So I wanna, yeah, re-emphasize that, yeah, there are many, many optimizations that we haven't implemented yet." }, { "speaker": "stephan", "time": "54:09", "start": 3249.41, "text": "Yeah. And those are coming. So what would you say is likely? Let's say if that's, if, if, let's say IBD is two x as bad and syncing is four x as bad from a bandwidth point of view, what, what would you say is the likely, at least given what we know today?" }, { "speaker": "stephan_livera", "time": "54:22", "start": 3261.84, "text": "So it really depends on how much you want to cash. If you want to cache more things, so like, it's like if you have more RAM on your system, then you can dramatically reduce the, the amount of things you will download And that goes for IBD and that goes for when you're getting transactions. And so it's, it's really hard for me to say, yeah, yeah, yeah. Gotcha, gotcha," }, { "speaker": "stephan", "time": "54:46", "start": 3285.58, "text": "yeah. And typically we're talking about in the bridge context, right? If you are just a-- Oh, no, this, this is-- If you are just a-- You, this is for bridge" }, { "speaker": "stephan_livera", "time": "54:52", "start": 3292.42, "text": "and, and the complex things, okay, gotcha. So for both," }, { "speaker": "stephan", "time": "54:55", "start": 3295.42, "text": "for both, for both. And then--" }, { "speaker": "stephan_livera", "time": "54:57", "start": 3297.39, "text": "Oh, wait, sorry, sorry. For bridges, you wouldn't be downloading So you will have" }, { "speaker": "stephan", "time": "55:09", "start": 3309.33, "text": "that, yeah. Right, because the whole point-- I was confused because the whole point is that the compact state node doesn't have to, yeah, yeah. Yeah. Gotcha. So, so the idea is if you wanna be a bridge and help other utreexo users, you're paying a little bit more, let's say, but the compact state node, you know, mom, doesn't have to, because she's just using in her browser or something like this or some like cut down application. And who knows, maybe in the future we see some of these existing wallets and Come out with utreexo support. So as an example, let's say if Nunchok had utreexo support or if, you know, Sparrow or Spectre had it, maybe, maybe that's something there that you could tell mom, hey, use this, but put it in utreexo mode so you don't have to download the full chain if you think she's not capable, you know, et cetera." }, { "speaker": "stephan_livera", "time": "55:56", "start": 3355.64, "text": "I would love that future. I, I look forward to a future like that." }, { "speaker": "stephan", "time": "56:00", "start": 3359.79, "text": "Well, let's see. I mean, this, I guess it has to kind" }, { "speaker": "stephan", "time": "56:08", "start": 3367.73, "text": "Yeah. So I guess we've spoken a bit about utreexo, is there anything, I guess, broader, like in Bitcoin, Lightning or whatever else, that you see you're, interested in or you, you would like to see?" }, { "speaker": "stephan_livera", "time": "56:19", "start": 3378.84, "text": "I was, I, I, I've been pondering this for, for a bit and, it, it, I was like, okay If I get done with utreexo, I want to do Electrum protocol v2. There's just, there's so many things that are very inefficient with the Electrum protocol, and, and I just haven't noticed as before because, you know, like it works fine, right? But actually doing the implementations of, of like the Electrum personal server on, on the utreexo node, it's like, oh my god, why are we doing it this way? This is, this is so ridiculously inefficient. It doesn't need to be this inefficient. And So that's why I was sort of thinking, hey, like we're doing like Stratum v2, right? Why not Electrum v2?" }, { "speaker": "stephan", "time": "57:02", "start": 3421.59, "text": "So what kind of, what kind of improvements do you see? Like, is it-- would it be like at the indexing size or at the bandwidth level or what? Oh," }, { "speaker": "stephan_livera", "time": "57:10", "start": 3430.01, "text": "oh, all levels." }, { "speaker": "stephan", "time": "57:11", "start": 3430.96, "text": "It's" }, { "speaker": "stephan_livera", "time": "57:11", "start": 3431.08, "text": "like You, you don't need to send. So, so one of the things that I think is really frustrating, is that, when you run, when you ask for-- to the Electrum server, like how much Like how much bitcoins do I control? You don't give the address, but you get, you hash the, the PK script. So you hash the script, and then you give that hash to the server and say, \"Hey, if there's any updates to this hash, then send me a status update.\" And status is the concatenation of every single transaction that has happened for this address, and, and it sends that over. And so every time there is a new-- So if you, if your address you're using- And you're running an Electrum server, you're hashing all this thing every single time something new happens. And so for, for this address, if something, like if, if a transaction happens in the mempool, that is, that is a hash. If, if all these transactions get confirmed in the block, that's more hashes. And so, and... And this hash really only provides very little data. It provides whether something happened or something didn't happen. Sorry, if I'm going off on this. No, I actually" }, { "speaker": "stephan", "time": "58:28", "start": 3507.67, "text": "find it interesting. I mean, I've, I've been using Electrum for a long time. I've used various different Electrum, but I'm not a developer, right? So I haven't looked into the, you know, I've just blindly just kind of used it, right? But it's interesting to hear. So," }, { "speaker": "stephan_livera", "time": "58:39", "start": 3518.8, "text": "so for you, yeah, yeah. So for you, when you're running an Electrum server" }, { "speaker": "stephan_livera", "time": "58:47", "start": 3527.25, "text": "There's no reason for you to do those hashes, and, and there's also no reason for-- so when the server sends a status update, you'll, you'll ask for all the transactions that has ever happened, even if you have them, you'll ask for them. There's no reason for you to, you know, use up the bandwidth. and so this is the stuff that I see as very annoying and that could use, just to overhaul and, and do like an Electrum v2. So that's, that's probably what I would want to get to, and once I get finished with utreexo, but, No, that's cool. That's interesting. I mean, it's a perspective I haven't" }, { "speaker": "stephan", "time": "59:21", "start": 3561.14, "text": "really heard, to be honest. So, hey, g-good on you for, finding that kind of stuff. And, you know," }, { "speaker": "stephan", "time": "59:31", "start": 3570.56, "text": "I, yeah, I wonder, yeah, I, The reason we don't understand or they were put in, maybe, yeah, but I, I again, I, year, years" }, { "speaker": "stephan_livera", "time": "59:40", "start": 3579.51, "text": "ago and just no one bothered to fix them. Yeah." }, { "speaker": "stephan", "time": "59:42", "start": 3581.79, "text": "Or, or I guess the Chesterton's Fence thing is that it exists for a reason that we don't understand. And then if you take it away, then maybe, you know, I don't know. But I think you're probably right that- Oh, no, no, no, it's, it's definitely not that. It's definitely not that. Okay," }, { "speaker": "stephan_livera", "time": "01:00:00", "start": 3599.56, "text": "so it really, they Because, Electrum X is meant to support Bitcoin and Bitcoin Cash, so when, when the protocol was originally made, it, it's designed to support Bitcoin and Bitcoin Cash. So it might have had something to do with that, but that's not a reason we care about, so. That's not a reason we care" }, { "speaker": "stephan", "time": "01:00:22", "start": 3622.2, "text": "about, so. Yeah. Cool, cool. Well, okay, so look, let's wrap up, I guess. we've spoken about a lot of stuff. Let's just try to summarize and make sure everyone's following along. So, ut And you tell me if I'm getting it wrong or right. So utxo, we can think of it like a way to dramatically compact the UTXO set, right? Which is about four or five gigs today. Yes. It could dramatically increase the availability for people around the world to validate Bitcoin as opposed to just trusting. Yes. It could improve the privacy, but the downside is, let's say, at the bridge level, somebody's got to be serving this up, and for them, they're paying a cost in terms of extra bandwidth, extra, you know, hard drive, et cetera What we have today, it might be beneficial overall from a privacy and a validation perspective. So I guess that's kind of how I would summarize it. It exists today in testnet and signet, but we're hoping that it can go to mainnet with a binary, as you mentioned." }, { "speaker": "stephan_livera", "time": "01:01:18", "start": 3678.33, "text": "I, I'm testing on testnet and signet. there's no really nodes that are out there, but, that, that is coming." }, { "speaker": "stephan", "time": "01:01:24", "start": 3684.36, "text": "Fantastic. Okay, so for anyone who wants to find out more or get involved, what's the best way to find out more or follow you online?" }, { "speaker": "stephan_livera", "time": "01:01:34", "start": 3694.14, "text": "Calvin Alvin, that's like K Calvin Alvin with an extra N on, at the end. Kinda confusing. You could just search Calvin Kim Bitcoin and like some BitMEX thing will pop up and you could follow me through there. Fantastic. Well," }, { "speaker": "stephan", "time": "01:01:49", "start": 3709.97, "text": "yeah, thanks for joining me today and explaining utreexo for me and, for the listeners." }, { "speaker": "stephan_livera", "time": "01:01:54", "start": 3714.69, "text": "I hope I was Was articulate enough for, your listeners to- No," }, { "speaker": "stephan", "time": "01:01:59", "start": 3719.51, "text": "I think you, I think it was good. I think, I think, we'll, we'll have to, I might have to listen again, but, I think it was good. So, yeah, thank you. Well, I'm glad. So if you learned something there, make sure to share the show with family and friends and get the show notes over at stephanlivera dot com." } ] }