Utreexo Explained

Hi everyone and welcome back to Stephan Livera podcast. Today we're talking about Utreexo with Calvin Kim. Calvin, welcome back to the show.

Well, thanks. I'm glad to be here again.

So I checked, checked the tapes. It's been over two years since that initial, episode we did about Utreexo. Obviously What spurred this now is you and, I believe you and, Tadz and, Davidson have put out these three BIPs relating to Utreexo, so I thought it would be a good time to get you back on the show, give us an update. so I guess just give us like a very, very quick brief overview and then we can sort of dive into further detail. what's, what's the latest, on Utreexo?

Okay. Yeah, so the latest on Utreexo is that, yeah, we, we publish the bits now. so the three bits are very, specific to what they cover. So like, like in like SegWit or like Taproot, the bits are separated into like what they're for. Like there, there might be the P2P layer and then there might be like the Schnorr signatures for Taproot. And so, the three bits are one for the accumulator for the Utreexo, so- So there, this is the, Merkle forest. This, these are the data structures and the algorithms themselves. And then the second is how do we now take that data structure and then validate, Bitcoin blocks and transactions with it. And then the last bit is the P2P one, which is, okay, how do we, communicate these, proofs for, to, to validate in between us? Sorry, sorry, just what we should

do is probably, just give a quick-- So yeah, I mean, appreciate that, but let's start with

It in my simple terms for, my fellow ADI QAs in the audience, and then you tell me what I'm missing, okay? So the basic idea is, when we start, okay, so when we wanna use Bitcoin, we interact, well, we can interact with Bitcoin using our own full node. The concept of Utreexo is kind of like a special full node that allows you to- To, let's say, quickly, understand what is the UTXO set of Bitcoin, right? I guess it's like, that's one way to sort of, allow people to, Have a, a set or and sort of understand are my coins contained in this set?

Yes. so I guess if, if I was explaining it to my mom, I'd just say, "Hey, like, like, you have a note, and you can make it small, but what I'm doing, you can make it even smaller." So that, that's like the easiest way that I would explain things, if, if, if some people that are more, familiar with Bitcoin, I would like, like, Talk about Merkle trees. And so like UTXO is just, it's a different type of a Merkle tree. It's, it's, it uses the same Merkle tree concepts, and so, but, but this Merkle tree is specialized for the UTXO set. And so instead of, right now it's like a database, and it stores all the data, but instead of doing that, like, we just use Merkle trees to store a summary of the data. That's That sounds easy. Yeah, okay. Yeah, and

I, and I recall, I was checking back our earlier episode as well, you were giving me this analogy of like a guest list at, you know, to get into a venue, and you were saying the idea is how can you check that somebody is on that guest list, but in a fast way, right? And that's sort of one i-idea or way of understanding this concept. And so the idea is, this is like a special Merkle tree that allows not just additions, but also deletions, to understand This is what the UTXO set is, like that is, quote unquote, the unspent coins, that is Bitcoin in a sense. So I guess normally the concept with Bitcoin is you're doing what's called IBD, initial block download. You're downloading the headers, and then you're downloading all the blocks, and then you are understanding, okay, do I have coins? Have I received coins? Do I need to send coins? This is, you know, once-- And then, my, my blockchain, my Bitcoin node is staying up to date with the blockchain, right and then this Utreexo concept, Utreexo concept is so that you can, it's like a proposed alternative for the UTXO set that allows you to kind of very quickly download or very quickly participate in Bitcoin, is the premise, right?

Yes. just like, so the very quickly part I should note is, is, is, is with this like trust assumptions, and so it's the same trust assumption as like assume valid, but it does have a tr-trust assumption. if you wanted to, like, do your ID, so assume valid for, for people that aren't aware is, when you're, when you're first starting up your Bitcoin node, your Bitcoin node actually doesn't check all the- The signatures. and so, and that is like, assume valid, like, "Oh, these blocks, we, you check the proof of work, you check the, the, the, like, like, is, is this like transaction spending Bitcoin that actually exists? You check the amounts, but you don't check the signatures, and the assumption is that, hey, like, these blocks are so old enough that, that we can like sort of skip them. And so that's like the default. And, So if you don't want to have that assumption, then you, you do all the signature validation from the beginning. Gotcha. And so the way people would do that, as

an example in Bitcoin Core, is there's like bitcoin dot com, and I think it's assume valid equals zero or something like, you basically turn that flag off, and then your Bitcoin node is gonna check Everything from genesis block, the first block, all the way. But by default, nowadays most nodes just use this new valid because it's seen as like for somebody to go back And like somehow have those blocks wrong, but the current blocks would just be sort of quite a, quite a very high bar, right?

Yes. And so, like, so with like Utreexo nodes, I guess the default could be that, hey, like it's the same trust assumption as assume valid, and so you start, like near- And so you only have to download those blocks. Gotcha. And so, so one of

the, I guess just to explain the different types of nodes, right? So like I think you were, you know, last time you were talking about this concept of a bridge node and a compact- it's a compact, state node. What, what's, what was the exact term? Yeah, compact state node. Compact state node, right? So the idea might be the bridge node is kind of like a seed or kind of like an Electrum server-ish person, that's like a professional or somebody who, like, let's say a hobbyist or a power user who wants to run the bridge node to sort of help, help the network per se, and the compact state node, that's like our proverbial mums or grandmas who wanna have an easy way to use Bitcoin without being like a super technical nerd, right? Yes. The compact state node is the one who's just Sort of using these Utreexo proofs to understand, oh, do I have coins or not, and being able to, you know, participate in Bitcoin by doing some level of validation, but obviously not as much as if you had downloaded the blockchain yourself or obviously what the bridge nodes are doing.

Yes. So, yeah, if you currently run a node right now, you probably wouldn't be that much interested in like, Utreexo compact state node, but the idea is, we're not trying to replace like Like what people are running now, and that's not the goal that we're trying to push right now. so what we are trying to do is, hey, like those people that aren't running nodes because they don't have the means to, or they don't, don't want to go through the hassle of doing that, like, hey, like if you download a wallet, like it should already have a node on it. It, there shouldn't be an extra step of, hey, like you, you download, I don't know, like Nunchok, and then you, No, then you have to buy like an umbrella. Like for, for us, I think that's fine. Like, like, yeah, we want to take control, and so that's fine. But for, for most people, it, it, we can't assume that for, for most people, especially as Bitcoin keeps getting adoption, so I think, like, yeah, so we're trying to, to push like these compact state nodes as, hey, like Like, how do I get my mom to run a node? It's like, hey, I don't, I don't even have to tell her that she's running a node. It's like, hey, download this app and you're, and you're fully validating blocks.

Gotcha. Yeah. So the idea would be not for, let's say you or me or the listeners of this podcast, but let's say our friends and family who we're trying to get into Bitcoin and we've been trying to get them to like, you know, use a hardware wallet and ideally connect it with their own That would be a strict improvement to today, where a lot of these users are, let's be honest, a lot of these users are custodial, right? Or these users are using, some kind of client that relies on the server model. Right. Where in this case, it's kind of like this would be a better client-server model, I guess we could argue. So the idea would be, hopefully, if this, you know, gets adoption, then there would be, let's say, wallet apps, either on our phone or desktop apps that can use and be a A compact state validating node that connects out to a Utreexo bridge, who's kind of feeding them the proofs so that they can quickly participate in Bitcoin with a, let's say, a stronger guarantee or stronger assurances that they're not being, let's say, lied to or whatever.

Yes. Yes. yeah, one thing I do wanna note there is that, we, we all, we all, we did wanna mention this in the bits as well, is that you don't have to connect to Bridge node specifically, you could connect to a normal archival node and they would be able to, like, normal Utreexo node, and they would be able to provide you with all the data that a bridge node would be able to. gotcha. Okay. So I did wanna mention that because there, there was some confusion there.

Okay, gotcha. So you could be either a Utreexo Archival node or a specific bridge node. Either of those can, let's say, serve the, is the right term, the Utreexo proofs, is that the term?

yes, it's, it's the proof message, yes Yes.

Okay, gotcha. Okay, so, the, I guess the general idea here is, so Utreexo, I guess, is using this concept of an accumulator, which- Is, as I'm reading from your, I'm, I'm reading a quote here. An accumulator is a cryptographic data structure that allows for the compact representation of a set, enabling efficient membership proofs without requiring storage of the entire set. In the context of Utreexo, the accumulator tracks the current set of unspent transaction outputs, UTXOs. So, maybe you just want to elaborate a little bit on this accumulator idea and, just explain for the listeners.

So like, like the simplest sort of accumulator is a Merkle tree. Like, like the Bitcoin Merkle tree is an accumulator, it is a cryptographic accumulator. You don't have to store the entire set. Like, like for, for the Bitcoin header, it, hashes all the transaction IDs into, like the, the transaction commitments that goes in the header. And so- That's right. This is in a block

per se. So the idea is you can check, is this transaction part of that block? Yes, yes. That's what we're checking. In the bit- in So it's a more advanced case, yeah? Yes.

So Utreexo, so we can use a Merkle tree to keep control, like keep track of the UTXO set, it's just that it'd be very inefficient because a normal Merkle tree, whenever you want to recalculate the tree, you need to have the entire UTXO set.

Yeah.

with UTXO, the, the, that requirement isn't there, that re- we don't have the requirements. And so, so there's that, so when I say like UTXO is a special like features of Utreexo that allow it to be better suited to, to, holding, like, keeping track of the UTXOs.

I see. And as also in your Bib, just from reading the accumulator part, you mentioned this concept of a Merkle forest. So I presume that's what we're talking about. It's kind of like a special version of a Merkle tree. So I guess the standard Bitcoin thing that we're used to, or people might be used to, is the Merkle tree. Yes. And then this case is a

On that and elaborate on what is a Merkle forest.

So, like, like, like, what makes up a forest? Like a lot of trees, right? And so what makes up a Merkle forest? A lot of Merkle trees. So inst-- like, in, in, in the case of like the normal Bitcoin, like what goes in the Bitcoin header, it's just one tree. With Utreexo, it's actually a bunch of trees, and, we keep track of all these trees and we call that the Merkle forest. And so this is what allows us to, do, like add new UTXOs without, recalculating the, like or requiring the entire set to, to add something.

I

see. So

yeah, so we can think of it like it's like the differences, right? We're just keeping track of the differences.

I guess we could go into details, but,

Not, not even that. so like very basic is, like, very basically is that, like, I don't know how to explain it. Okay, gotcha.

Let's, let's, let's come back to this then. So, I see you've got operations here, addition, verification, and deletion in the accumulator. So, oh, sorry, in the accumulator, BIP or document. Yes. So, maybe just talk-- if you could just sort of talk through a little bit what, what, what are those operations and then we can understand from there.

So yeah, so addition, deletion, and verification are the, three, consensus critical operations for U-- for the UTXO accumulator. So additions is, so like, why do we need these? It's like additions because we, on-- for Bitcoin blocks, we create new UTXOs. Deletions because, we actually need to, like, get rid of these UTXOs. verification is because, hey, when we receive this new block, we need to make sure these, the referenced UTXO So those actually exist. So those are the three operations, and that's the reason why they're there. so we have like, so, so we didn't talk about like proving, so we talked about verification, but not proving, and we specifically left it out of there are methods in the BIP you can use to generate proofs, but we specifically left it out in that BIP because it's not critical to, consensus. like you can generate a wrong proof, but like the, the worst case is that people just reject your proof. it's not consensus critical.

Yeah. Okay. And I guess we should just clarify, just for listeners who aren't sure here, this isn't like a soft fork to Bitcoin. This is like an, what we're talking about here is just Like an optional, yes, side piece of software that you can run or not run and still use Bitcoin.

yeah, I do strongly want to mention that if you don't care about Utreexo, you could completely ignore this and you'd be fine. There's There's gonna be nothing affecting you. We're not trying to force onto people anything like new. like I personally wouldn't want that, and so it's not what we want to push. And so the, the-- and we worked very hard, like, there, there was extra work gone into making this, a be like an opt-in feature. So wanna make that very clear.

Okay. Yeah. and then so we've got the-- There's a Utreexo validation BIP, and so here- From the abstract, this paper defines the rules for validating blocks and transactions using the Utreexo accumulator. okay, and so, yeah, I guess what you're saying is, so basically the idea is that the Utreexo nodes can stay in consensus with one another. So if you wanna just elaborate a bit on that and what it means. Right.

And so, right. So for-- So we have the accumulator, but we don't know, like, how to use this accumulator. Like, hey, like, what goes into this accumulator? Or like, what doesn't go into this accumulator?

Like we, what we add to the accumulator are the UTXOs themselves, but like what consists of that UTXO data and, like how do we serialize that UTXO data? Because if we, if we serialize things in the wrong order, then, like you wouldn't be able to, communicate with other UTXO nodes. So those are the things that are defined in the, validation bits, like anything that has to do with, Bitcoin specific things. So like, So like with the accumulator stuff, there's actually nothing Bitcoin specific there. Like you could completely treat it as its own thing and you could, like, other researchers could actually like take that and use it somewhere else. but with this, it's, it's like very Bitcoin specific. We take what we, what we, Built up in the accumulator bit and, apply it to Bitcoin so that we can verify blocks and transactions.

Gotcha. Okay. okay, so that's the part of staying in consensus with other Utreexo nodes, and then, also you have a P2P, bit also. So this is the Utreexo P2P bit, and I, and as you were saying and discussing earlier, this is how the Utreexo nodes can talk to each other. So can you just elaborate a little bit on what that looks like and what the- Differences are there with a Utreexo peer-to-peer node versus just standard Bitcoin?

Right. So we introduce like new messages. So for like blocks, you need a, you need a proof with those blocks, and so how do we communicate those proofs? for the transactions as well, how do we communicate, like proofs for the transactions? So we introduced new message types to, to Bitcoin, and so These nodes, like, well, the current nodes can just opt to just completely ignore these messages if they want. they don't need to respond to these messages or, nor do they need to even know about these messages. But the Utreexo nodes or nodes that really want to, like communicate with Utreexo nodes, you can, so it specifies like, this is how we communicate. So these are the data types, this is how we serialize those data, and this is how, like, what- The message flow is like between the, between two nodes. So, anything that has to do with communication with, other nodes wanting to exchange proof data is, is defined in this step here.

The lead sponsor of this show is Bold, the banking platform designed for Bitcoiners. With the Bold virtual Visa debit card, you earn Bitcoin back on every purchase. The more Bitcoin you buy with Bold, the more Sats back you get on the card. Buy twenty-five hundred dollars of Bitcoin and earn three percent Sats back. Keep stacking with Bold to earn up to ten percent. Sats back. Bold offers the industry's lowest fees on Bitcoin buys and sells with zero added spreads. When starting out, you can use Bold Wallet, which is managed by the team, but Bold is also supporting self custody with Bold Vault, a two-of-three collaborative custody multisig for zero monthly fees. With Bold, you get your own FDIC-insured checking account to store and send fiat, pay bills, direct deposit your paycheck, and replace your legacy fiat bank. Sign up today and get zero fees on your first ten thousand dollars of Bitcoin buys and Twenty-five dollars of free Bitcoin when you buy a hundred dollars of Bitcoin or more. Go to getbold dot io. This episode is brought to you by CoinKite, the makers of my favorite Bitcoin hardware wallet, the Coldcard Q. Now, some people think self-custody is too hard, but it's really about taking responsibility for your Bitcoin wealth and understanding that self-custody gives you a true feeling of liberty. The Coldcard Q has a full keyboard and big screen. It's got two secure elements and a true air gap, allowing you to go fully air-gapped using QR codes from seed The device using three triple A batteries, so you don't even have to plug it into the wall for power. You can easily use it with Sparrow Wallet for PC or Nunchok on mobile, and you can dial it into the right level of security and complexity that you choose. If you want a simple setup, just use twelve words and single signature. If you want passphrase, it's easy. If you want to add multi-sig or co-signing features, you've got those too. So go to coinkite dot com, use code livera to get ten percent off on your cold card or

Gotcha. Okay. Yeah, and of course, links will be in the show notes, but I think, an interesting one is, there's a diagram, maybe we can flash it up here, but basically it's showing the serving node and the IBD node or initial block downloading node, and then you've got just kind of a listing of the messages there. So it's get headers, headers, get data, block, and then get utreexo proof, and then block and utreexo proof. So I guess the obviously the new things there are get utreexo proof and

Is that kind of a fair summary? These are some of the new things that are being brought in, but it, it's only relevant for Utreexo nodes, not for, you know, just vanilla Bitcoin Core or Bitcoin nodes?

Yeah. Wanna again mention, if you want to completely ignore Utreexo, you're very-- like, there's nothing you have to do, there's no action you have to take to ignore these new messages.

Of course, of course. This is like totally an opt-in thing, and the idea would be that, you know, the proverbial grandma can, you know, just download an app, and that app can quickly, be a validating client. So You know, last time we spoke, it was sort of the, the idea is that this proof could only be-- or is it the proof or the, the set? It's only a few kilobytes. Can you just elaborate? Is that still the case or what's, what's the latest there?

Yeah, the set is still a few kilobytes, it's, it's usually less than a kilobyte, but so the current UTXO set, it's, I think it's about like ten gigabytes now, and there's no cap on this UTXO set, and so it, it keeps growing. And, so we have, so, so with UTXO nodes, this UTXO set just remains about a kilobyte, and

Yeah, so this makes, obviously makes it very easy for the proverbial grandma to just have it in her app or whatever. and then the-- Yes, it requires more storage on the bridge node or on the full Utreexo archival node because they're storing, because they have to also create proofs. but this is kind of, again, this is like a role for the, let's say, power user, hobbyist, professional kind of person. Not, you know, the grandma. The grandma is gonna be on, you know, the compact state validating node, and the bridge node is gonna be like a professional or someone who really knows what they're doing. So can you just explain a bit about the bridge node, what's required there, you know, storage and, computation cost for that bridge node?

Yeah. So the bridge node, we call it a bridge node because, it bridges like the current Bitcoin nodes and Utreexo nodes. so what the- The bridge is only responsible for creating, proofs for newly broadcasted blocks and newly broadcasted transactions. And, so one thing that I wanna mention is that you can be a pruned node and still be a bridge node, because a bridge node's, responsibility is, like two things, like create new, like proofs for new blocks and new transactions. So what archival nodes then do is they store the block and the proof together. And so, so like different node types could be, you could be an archival Utreexo node and not create proofs for new blocks and transactions, or you can be a pruned bridge node and, you, like, you don't, you don't serve the historical blocks, but you create, proofs for new blocks and transactions. Like, you can be both, you can be a bridge node and an archival node, but that's not a requirement.

That's not the only case, but I guess it's probably fair to say, would you- You say most of the, let's say hobbyists or kind of people who are trying to, quote unquote, you know, help this network grow, they would just do both, right? In practice,

if, if you, if you have a node, then you would probably just do both because it's like, hey, like, why not?

Gotcha. Yeah. And so, I, I think you, you might have told me this last time, but it's basically like storing almost like two x the current blockchain size, to be that bridge node. But again, this is-- We're talking about the professionals and hobbyists and power users here, so for them it's not a big deal, but we're talking about Basically that in that range.

Yeah. The, the historical proof size is slightly less than the entire historical block size, so ab-about two x.

Gotcha. Okay. And so also, how do these Utreexo nodes find each other, right? Whether that's Utreexo nodes, bridge nodes, or compact state nodes?

so you don't differentiate between, like the bridge nodes and archival nodes, but you do differentiate between like these compact state nodes and bridges and archival nodes. so currently in the Bitcoin network, if you want to signal to other nodes that, hey, like, I'm an archival node, then there's a message flag that you send, to your peers saying, hey, like, this is the supported, like, the feature Features that I support, and you say like, node network for archival nodes, and then you do like node network limited if you're a prune node, and you can only serve, blocks, from the last two days. And, for UTXO nodes, you would also like, like, advertise that, hey, like, I'm a node UTXO, to say that, hey, like, I, I understand the UTXO protocol, and then I also am able to, broadcast, like, receive and broadcast, Like blocks and transactions with the UTXO proofs, and then you have the, node UTXO archive, which is you are able to serve historical proofs. Not blocks, but only historical proofs. So you can, so like, like you, if you want to do this, you, you are able to just store the historical UTXO proofs. And so what the IDD node would be, would be doing is that you would get the blocks from a, like a current archival node, and then you get the proof from a UTXO, archive node.

Gotcha. Okay.

Yeah. It's, it's very, it's very modular, but, yeah, as you mentioned, like most people, they would just do everything, so they would store all the historical blocks, all the historical proofs, and then be a bridge, be a bridge node as well, where you create, new, like new, like create proofs for new blocks and transactions, but, like, they're very modular. You can

And for now, are there bridge nodes operating? I presume you're operating one and Davidson and maybe a couple other hobbyists, and the idea is that you guys are kind of helping bootstrap this, but maybe in the future Do you envision that actually services or wallet providers might actually operate some more bridge nodes themselves, or who's gonna be, who's gonna do this bridge node role?

so yeah, at the moment it's just me and Davidson, and, as- So as we get things rolling, we hope to have more adoption and, so the implementation side is still being worked on, and so we're, we're coordinating like, how to get more bridge nodes up for that. But in the future, I sort of envision like Maybe, maybe it's not a good comparison, but I, I sort of see the comparison as like the Phoenix wallet, like the Lightning wallets, where, hey, like you don't have-- like not every Lightning node needs to be like the, like the, the service node, like you, you don't have to like transmit payments, but you could just like be connected to one of them and, you can transact, funds that way, but you're not Like it's, it's just the app that you run on your phone. so I can sort of see in the future, hey, like if I download a, a wallet app, then I just connect directly to their bridge node, and then they'll be, like giving me, proofs for blocks and transactions. Yeah. And the assumption, so, so the assumption here is that you're, you're trusting them for the data being provided, but you're not, You're not like entirely trusting them, you're still validating the data that they give you. Like so they can omit the data, but they can't lie to you.

They can't lie to you and trick you into believing you received a transaction that you didn't receive. And that's, that's the important point here. and I guess I'm also anau-- I'm sort of thinking it's kind of analogous to In the old days or even today, there are certain public Electrum servers, right? So as an example, there might be Electrum client users, right? And if you think back to even the OG kind of Electrum wallet in 2011 and the way, Thomas spoke about it, the idea was there were a lot of custodial users, and he wanted people to be able to just run this Electrum client without having to like run the full thing. And so there were and are people who just run public Electrum servers, and they're just kind of publicly available. So I Well, that maybe in the future there might be people who use these easy, compact state node wallets or apps, and then there are just public Utreexo bridge nodes and, Utreexo archival nodes who just kind of serve up the proofs because they just wanna help the network kind of thing and help, help these people be able to use Bitcoin easily.

Yeah, and I also wanna mention that Thomas V was actually super interested in Utreexo because, like he, he wants to make the Electrum wallets, like more- Like trustless as, as possible and so maybe this would be something

he would be interested to support in Electrum Wallet. Yes. Interesting. Okay. And, while we're here, of course, I know there is a project, Floresta, which I believe uses this, and I believe this is Davidson's project or he's involved with it. Maybe you can just give us a quick overview, just because I think this might be actually useful for people to understand a practical application here of Utreexo. So give us a quick overview of Floresta.

Yeah. So Florest That, doesn't have, doesn't keep a UTXO set, like doesn't keep the entire UTXO set, but, uses UTXO to, keep, keep up, keep like to, to s- be in sync with other UTXO, other nodes. And so, like, so this is a implementation of the compact state node that we talked about, and Floresta has bindings to other languages so that developers can, just take it and then, like, put it in their existing wallets or, or services. And so, like, this is a project that, makes it possible and like allows, some, some, bootstrap ability for existing wallets and, and other maybe companies that are interested.

Yeah, and I think it's also really interesting because instead of users being, It sort of, I guess it, it allows, yeah, like we were saying, comes back to that same idea that it's like a, a real world example of that compact state node, and it gives people a stronger assurance that they really do hold coins instead of having to trust being in a sort of a, a, let's say, a more trusting client-server model, this is like a validating client model, let's say. Yes. Yes. and so Utreexo D, as you've, as, as I've seen in the documents and stuff, Utreexo D is, I guess, the implementation, the code of this. So can you explain a bit about Utreexo D, what it is? Yeah.

So Utreexo D is everything that's, that's in the Bibs, it's everything Utreexo related. So that's like the practical

implementation of what you spoke about in the Bibs, let's say.

So, yeah, so it's like, hey, like it has accumulator, it has the bridge node, it has the archival node that doesn't have the bridge capability, it also has the compact state node capability. So it's It's basically like a, I would say it's a reference implementation of like everything related to Utreexo. Floresta is a more very, like, very specific version of that where it's, it's just a compact state node, and it has a lot of features that Utreexo doesn't have, like, like these bindings to other languages. It also supports, like this, like soft chains SPV thing that uses Utreexo as well. And so there's a lot of features, but all those features are geared Towards, hey, like, let's, let's, let's make this thing, let's make this the node for, like, like grandmas.

Gotcha. Yeah. Okay. And so we can think of it like this, the, a lot of the Utreexo archival nodes and Utreexo bridge nodes, they may run Utreexo D, whereas the, you know, the proverbial grandmas may be running Floresta or something like that, a compact state node. That's kind of what it is. And then as I'm understanding, these three BIPs that

To implement their own version of UTXO D or some competitor to UTXO D, they would need these bits to sort of understand the, the method by which UTXO is being done. Is that the right understanding? Yeah. Gotcha. So

with With all the information provided in these Bibs, your, you would be able to create a, client that's, is able to communicate and, keep up with, with the Utreexo D nodes and the Floresta nodes.

Gotcha. And the idea is how would you stay in consensus together with them? And so this would be, you know, maybe technical minutia for the everyday user that don't need to know about this, but this would be for the developers and builders who maybe they've heard an idea here and they wanna build something here because Wallet or app or something like this, and/or I wanna use Floresta as part of my thing. So, what are you looking for from here? Like, are you looking for review builders to kind of build on this or developers to help contribute? What are you looking for?

for the moment, we're just like, "Hey, like, this is what we came up with. Like, we talked about Utreexo for years now, but we worked like very hard on the, the specs and, the, the specs are actually like, we, we sort of went Like went the extra mile where it actually supports a lot of, like caching, and that, that was sort of tricky to figure out. And so, like, we want, we want like reviews from, from builders that are interested in Utreexo and sort of take a look at this and say, hey, like, this is sort of cool, or hey, like, why, why don't we do this? so I guess we're looking for ideas, with, with the tips.

Gotcha. Yeah. Now also, just to touch on this, this whole idea of different Bitcoin implementations, as I'm understanding from you, Utreexo D is based on BTC D, which is another implementation of Bitcoin. So as listeners may be aware, there's different-- there's Bitcoin Core, obviously the dominant implementation on the network today. There are other implementations. So can you just discuss a little bit about- You know, BTC-D and building on that.

Yeah, so BTC-D is an implementation of the Bitcoin, of, of Bitcoin in a language called Go. And, right now, it's, it's a, it's a node as well, but it's also a library as well. So a lot of developers that, implements wallets or, like, especially something like, the, the Lightning Nodes or like LND, it relies Heavily on, using, the BTC-D libraries to, like basically to, to stay in consensus, like, 'cause they don't wanna be implementing all these, basic Bitcoin, basic Bitcoin messages. So that's what BTC-D is, and it's mostly at the moment a lot of people from Lightning Labs work on it. Yeah. so, so we have BTC-D, and then originally the Utreexo implementation was in Go, the same language, and it's hard to work in between Between languages, so, it was the natural choice to, fork BTCd and then to put Utreexo in. And so, yeah, that's-- so that's the relationship with like Utreexo D and BTCd. I should also mention that like the Utreexo D codebase and BTC D codebase is very, very similar. There's, there's only a few differences, and so I, like, I, I contribute nowadays like heavily to BTC D as well.

Gotcha, yeah. okay, so I think those are the key questions that I had. so obviously we'll put all the links there in the show notes for people to check out the BIPs and give their feedback. I guess while I've got you, also, any updates for people in terms of Bitcoin community in Seoul and Bitcoin community in, in Korea? what's happening these days?

nowadays, lots and lots of activity. so we have, so yeah, there's, beginning of this year, we've created a, a, an organization called the Bitcoin Social Layer in Korea, and, It sort of allows people that are like doing individual work, like they're, we're all sort of separated, but then, it's, it's hard to get things moving forward in Korea. It's very, there's a culture of doing things together, and, this organization helps us do that. And so we're, we're-- there's a lot of activity on like meetups, meetups are hosted by DSL as well, translations, a lot of translations. For, books, videos, games as well. Like, there's a game that helps you develop, like, get introduced to concepts called like Saving Satoshi. that has now been translated to Korean as well. So, and then after, and then besides that, we also have like, there's, there's a mining, sect, like, like a mining guild in, BSL as well, where they're teaching people how to mine with like BitAccess, and if they wanna do like commercial mining, this is where, people- Or like doing things together to like sharing knowledge and then figuring out like how, how, how do we, profitably mine in Korea? other things are, there's a, there's a payment skill where they're trying to, get like or basically orange pill local shops in Korea. So now there's over a hundred shops in Korea accepting, Bitcoin and Lightning payments directly. So there's, there's actually a separate website like BTC Map Dot kr, where there's a map of like the shops where they accept Bitcoin in Korea. So there's a lot of activity going around, with BSL and lots of, well, way more than, than when we originally talked about Utreexo two years ago. So I'm very happy with that. And, yeah, we're also, so with the help of BSL, we're, we're, we're also hosting a conference later this year, that's very like entirely community based. So Like, lots of things going on

now. Yeah, well, it's great to hear all the, updates and how things are evolving there. maybe you can, push some of those, Korean, merchants to be a compact, state node and, see how things go there. Yeah. Of course, I mean, that would be if they're taking on-chain payment, obviously, Lightning and Ark and Liquid and whatever else is different. but, yeah, so we'll put all the links in the show notes for listeners to, Yeah, thanks for having me.