Utreexo Explained with Calvin Kim | SLP685

Posted in: bitcoin Posted on Posted in: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

In this episode, Stephan Livera and Calvin talk about Utreexo. They discuss the latest updates, including the publication of three BIPs related to Utreexo, which aim to improve the efficiency of Bitcoin nodes. The conversation covers the mechanics of Utreexo, including its accumulator structure and the concept of a Merkle forest. They also explore different types of nodes, such as compact state nodes and bridge nodes, and how these innovations can enhance user experience and participation in Bitcoin. Additionally, they touch on the growing Bitcoin community in Korea and the potential for future developments in the Utreexo space.

Takeaways

🔸Utreexo aims to improve Bitcoin node efficiency.

🔸The accumulator structure allows for compact representation of UTXOs.

🔸Merkle forest enables better management of UTXO sets.

🔸Compact state nodes simplify Bitcoin participation for users.

🔸Bridge nodes serve as intermediaries between Utreexo and traditional nodes.

🔸P2P communication is essential for Utreexo nodes.

🔸Floresta is a practical implementation of Utreexo concepts.

🔸UtreexoD serves as a reference implementation for developers.

🔸Community engagement is crucial for Utreexo’s adoption.

🔸The Bitcoin community in Korea is rapidly growing. 

Timestamps:

(00:00) – Intro

(00:50) – What is Utreexo?; Latest developments with Utreexo

(04:44) – Trust assumptions in Utreexo

(06:35) – Bridge nodes vs. Compact state nodes

(10:58) – What is the Utreexo accumulator?

(12:58) – What is a Merkle Forest?

(14:18) – Consensus operations in Utreexo; Utreexo validation

(18:02) – How does P2P communication work with Utreexo?

(19:15) – Sponsors

(23:22) – What is the Bridge node and why is it needed?

(25:27) – How do the Utreexo nodes find each other?; The future of Bridge nodes

(30:31) – What is Floresta?

(32:05) – What is UtreexoD?; Comparing it with Floresta

(34:45) – Community engagement with Utreexod & BTCD

(37:35) – What’s new with Bitcoin in Seoul, Korea? 

Links: 

Sponsors:

Stephan Livera links:

Transcript:

Stephan Livera (00:00)
Hi everyone and welcome back to Stephan Livera podcast. Today we’re talking about UTreeXO with Calvin Kim. Calvin, welcome back to the show.

Calvin (00:08)
So thanks, I’m glad to be here again.

Stephan Livera (00:11)
So I checked the tapes, it’s been over two years since that initial episode we did about U3XO. Obviously, what’s spurred this now is you and I believe you and ⁓ Tadge and Davidson have put out these three bips relating to U3XO. 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 the latest ⁓ on UTreeXO?

Calvin (00:44)
Okay, yeah, so the latest on UTREXO is that, yeah, we published the BIPs now. ⁓ So the three BIPs are very specific to what they cover. like in like Cyquid or like Taproot, ⁓ the BIPs are separated into like what they’re for. Like there might be the P2P layer and then there might be like the Schnorr signatures for Taproot. And so ⁓ the three BIPs are one for the accumulator for the UTREXO. ⁓

So this is the Merkle forest. 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, how do we communicate these proofs to validate in between the nodes? Yeah.

Stephan Livera (01:33)
these things to each other. Yeah. Sorry, sorry, just what we should

do is probably just give a quick, so yeah, I mean, appreciate that, but let’s start with a overview or you know what, let me try and summarize it in my simple terms for my fellow AD IQers in the audience and then you tell me what I’m missing, okay? So the basic idea is when we, okay, so when we wanna use Bitcoin, we interact, well, we can interact with Bitcoin using our own full node.

Calvin (01:44)
Alright.

Stephan Livera (01:59)
The concept of UTXO is kind of like a special full node that allows you 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 set ⁓ and sort of understand, are my coins contained in this set?

Calvin (02:28)
Yes, ⁓ so I guess if I was explaining it to my mom, I just say, like you have a node and you can make it small, but with what I’m doing, you can make it even smaller. So that’s like the easiest way that I would explain things. ⁓ If some people that are more familiar with Bitcoin, I would like talk about Merkle trees. And so like UTreeXO is just…

Stephan Livera (02:40)
Yeah.

Calvin (02:53)
It’s a different type of a Merkle tree. It uses the same Merkle tree concepts. But this Merkle tree is specialized for the UTXO sets. so instead of, right now it’s like a database ⁓ and it stores all the data. But instead of doing that, we just use Merkle trees to store a summary of the data. That’s as easy as I can get.

Stephan Livera (03:18)
Yeah, okay. Yeah, and I recall

I was checking back at 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’re 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 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.

Calvin (03:25)
Yep, yep, yeah, right.

Right, yeah. Right, yeah.

Stephan Livera (03:43)
To understand okay. 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 I my my blockchain my Bitcoin node is staying up to date with

Calvin (03:43)
Yes.

Yes.

Stephan Livera (04:12)
blockchain right to stay with what’s called the chain tip ⁓ and then this UTREXO concept UTREXO 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

Calvin (04:25)
Yes.

Yes, ⁓ just like, so the very quickly part I should note 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 trust assumption. If you wanted to like do your IV, so assume valid for, for people that are not aware is when you’re, when you’re first starting up your Bitcoin node, your Bitcoin node actually doesn’t check all of the signatures.

⁓ And so, and that is like assume valid, like all these blocks, you check the proof of work. You check the like, 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, like these blocks are so old enough 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. And with UTrix on those, Yeah. Yeah. Yeah.

Stephan Livera (05:34)
Gotcha. And so the way people would do that as an example in Bitcoin Core is there’s like bitcoin.conf and I think it’s assume valid equals zero or something like you basically turn that

flag off and then your Bitcoin node is going to check everything from Genesis block, the first block all the way. But by default nowadays, most nodes just use assume 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?

Calvin (05:45)
Yes, everything, Yeah.

Yes.

Yes, and so like, so with like, you trick zone 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 tip. And so you only have to download those blocks. ⁓

Stephan Livera (06:17)
Gotcha. so one of the, guess just to explain the different types of nodes,

right? like, think you would, you know, last time you were talking about this concept of a bridge node and a compact, what’s it, a compact state node. What was the exact term? ⁓ 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.

Calvin (06:31)
Yeah, compact state notes, yes, yeah.

Stephan Livera (06:41)
⁓ 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 want to have an easy way to use Bitcoin without being like a super technical nerd, right? The compact state node is the one who’s just

Calvin (06:47)
Yes.

Yes.

Yes.

Stephan Livera (07:02)
sort of using these UTreeXO proofs to understand, do I have coins or not? And being able to 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.

Calvin (07:13)
Yes.

Yes. So yeah, if you currently run a node right now, you probably wouldn’t be that much interested in like a Uterix or CompactState node. But the idea is we’re not trying to replace like what people are running now. That’s not the goal that we’re trying to push right now. ⁓ So what we are trying to do is, like those people that are not running nodes because they don’t have the means to, or they 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. There shouldn’t be an extra step of, like, you download, I don’t know, like, Nunchuck, and then you connect your node to it. How do you, what is a node, and you have to buy, like, an umbrella. Like, for us, I think that’s fine. Like, yeah, we want to take control. And so that’s fine. But for most people, it’s…

Stephan Livera (07:49)
Right.

Calvin (08:16)
We can’t assume that for most people, especially as Bitcoin keeps getting adoption. I think, yeah, so we’re trying to push these compact state nodes as, hey, how do I get my mom to run a node? It’s like, hey, I don’t even have to tell her that she’s running a node. It’s like, hey, download this app and you’re fully validating blocks.

Stephan Livera (08:36)
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 are 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 node. And of course, it’s kind of hard to get them to do that. If we could have some kind of client app that also does some validation, 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.

Calvin (08:43)
Right, yeah.

Right.

Right.

Yes. Yes. Yes.

Yeah.

Stephan Livera (09:04)
Right,

all these users are using ⁓ some kind of client that relies on the server model. 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 gets adoption, then there would be, let’s say, wallet apps.

Calvin (09:11)
Right, yeah.

Stephan Livera (09:24)
either on our phone or desktop apps that can use and be a compact state validating node that connects out to a UTrix or 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.

Calvin (09:44)
Yes,

Yeah, one thing I do want to note there is that ⁓ we did want to mention this in the BIPS as well, is that you don’t have to connect to a bridge node specifically. You could connect to a normal archival node and they would be able to, like normal archival uterx-o node, and they would be able to provide you with all the data that a bridge node would be able to. ⁓ So, did want to mention that because

Stephan Livera (10:10)
Gotcha. Okay.

Calvin (10:14)
There was some confusion there.

Stephan Livera (10:16)
Okay, gotcha. So you could be either a UTreeXO archival node or a specific bridge node. Either of those can, let’s say, the, is it right term? The UTreeXO proofs, is that the term?

Calvin (10:23)
Yes.

⁓ Yes, it’s the proof message. Yes,

Stephan Livera (10:33)
Okay, gotcha. Okay, ⁓ 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 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.

Calvin (10:41)
Yes.

Stephan Livera (11:02)
In the context of UTXO, 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.

Calvin (11:02)
Yes.

Yes.

Mm.

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

Stephan Livera (11:36)
Gotcha, this is in a block per se. So the idea is you can check

is this transaction part of that block? That’s what we’re checking in the standard Bitcoin case and now you check so as a more advanced case, yeah.

Calvin (11:41)
Yes, yes. yeah. Yes. Yes.

So U-Tree XO, 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. ⁓ With U-Tree XO, that requirement is not there. We don’t have that requirements. And so.

Stephan Livera (12:00)
Yeah.

Yeah.

Calvin (12:08)
⁓ So there’s that. So when I say UTXO is a special Merkle tree, ⁓ I’m talking about these sort of features of UTXO that allow it to be better suited to holding, keeping track of the UTXO sets.

Stephan Livera (12:26)
I see. And as also in your bit just from reading the accumulator part, you mentioned this concept of a Merkel forest. So I presume that’s what we’re talking about. It’s kind of like a special version of a Merkel tree. So I guess the standard Bitcoin thing that we’re used to or people might be used to is the Merkel tree. And then this case is a Merkel forest. So can you just explain a little bit around that and elaborate on what is a Merkel forest?

Calvin (12:32)
Yes. Yes, Yeah.

Yes, yes.

Yes. So yeah.

So like, makes up a forest? Like a lot of trees, right? And so what makes up a Merkle forest? A lot of Merkle trees. So in the case of like the normal Bitcoin, like what goes in the Bitcoin header is 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.

Stephan Livera (13:11)
I see.

Calvin (13:12)
And this

is what allows us to add new UTXOs without recalculating the, or requiring the entire set to add something, like add something new to it.

Stephan Livera (13:24)
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.

Calvin (13:30)
⁓ I guess we could go into details, but…

Not even that. very basically is that, I don’t know how to explain it. So you have a lot of, yeah.

Stephan Livera (13:46)
Okay, gotcha. Let’s look well, let’s come back to this then. So I

see you’ve got operations here addition, verification and deletion in the accumulator. So I was sorry in the accumulator, bit or document. 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.

Calvin (13:52)
Mm-hmm.

Yes. Yes. Yes.

right.

So yeah, so addition, deletion and verification are the three consensus critical operations for the UTXO accumulator. addition is, so why do we need these? It’s like additions because for Bitcoin blocks, we create new UTXOs. Deletions because we actually need to get rid of these UTXOs.

Verification is because, hey, when we receive this new block, ⁓ we need to make sure the referenced UTXOs actually exist. So those are the three operations and that’s the reason why they’re there. ⁓ So we didn’t talk about proving, so we talked about verification but not proving. 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 bit because it’s not critical to consensus. ⁓ Like you can generate a wrong proof, but it’s like the worst case is that people just reject your proof. It’s not consensus critical. And so, yeah.

Stephan Livera (15:11)
Yeah. Okay. And I guess we should just clarify

just for the listeners who aren’t sure here. This is not like a soft fork to Bitcoin. This is like an, what we’re talking about here is just like an optional side piece of software that you can run or not run and still use Bitcoin.

Calvin (15:18)
Yes. Yes. Yes.

Yeah, I do strongly want to mention that if you don’t care about UTREXL, you could completely ignore this and you’d be fine. There’s going to be nothing affecting you. We’re not trying to force onto people anything new. ⁓ I personally wouldn’t want that, and so it’s not what we want to push.

And we worked very hard. There was extra work gone into making this ⁓ be like an opt-in feature. So I want to make that very clear.

Stephan Livera (15:56)
Yeah.

Okay. Yeah. and then, so we’ve got the, there’s a validation, UTreeXO validation BIP. And so here from the abstract, this BIP defines the rules for validating blocks and transactions using the UTreeXO accumulator. ⁓ okay. And so I guess what you’re saying is basically the idea is that the UTreeXO nodes can stay in consensus with one another. So do want to just elaborate a bit on that and what it means?

Calvin (16:18)
Yes. Right.

And so, right. 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? Like what doesn’t go into this accumulator? And we, we come, 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 serialize things in the wrong order, then ⁓ you wouldn’t be able to communicate with other UTREXO nodes. So those are the things that are defined in the validation. Anything that has to do with Bitcoin specific things. ⁓ So with the accumulator stuff, there’s actually nothing Bitcoin specific there. 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 like very Bitcoin specific. We take what we built up in the accumulator bit and apply it to Bitcoin so that we could verify blocks and transactions. Yes. Yes.

Stephan Livera (17:29)
Okay, ⁓ okay, so that’s the part of staying in consensus with other UTreeXO nodes and then

⁓ also you have a P2P ⁓ BIP also. So this is the UTreeXO P2P BIP 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 P2P node versus just standard Bitcoin?

Calvin (17:40)
Yes.

Yes.

Right, so we introduce like new messages. for like blocks, 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 Bitcoin. 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 UTreeXOne nodes are nodes that really want to ⁓ communicate with your trixone nodes. ⁓ 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 what the message flow is like between two nodes.

So anything that has to do with communication with other nodes wanting to exchange proof data is defined in SPIP here.

Stephan Livera (18:54)
Gotcha.

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 you tricks are proof and then block and UTREXO proof. So I guess the, obviously the new things there are get UTREXO proof and the serving node is the one who’s also serving the UTREXO proof. So

Calvin (19:10)
Right.

Yes.

Yes.

Stephan Livera (19:32)
that kind of a fair summary. These are some of the new things that are being brought in, but it’s only relevant for UTREXO nodes, not for, you know, just vanilla Bitcoin core or Bitcoin nodes.

Calvin (19:40)
Yes. Not, not, not, not,

Wanna again mention if you want to completely ignore UTrix, so you’re very, there’s nothing you have to do. There’s no action you have to take to ignore these new messages. Yeah. Yeah.

Stephan Livera (19:55)
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, was sort of the idea is that this proof could only be or is it the proof or the the set is only a few kilobytes? Can you just elaborate? Is that still the case? Or what’s what’s the latest?

Calvin (20:18)
Yes.

Yeah, the set is still a few kilobytes. ⁓ It’s usually less than a kilobyte. ⁓ But so the current UTXO set, I think it’s about like 10 gigabytes now. And there’s no cap on this UTXO sets. And so it keeps growing. ⁓ so we have, so with UTXO nodes, this UTXO set just remains about a kilobyte. so this is because, yeah.

Stephan Livera (20:47)
Yeah, so this makes obviously makes it very easy for the proverbial

grandma to just have it in her app or whatever. ⁓ And then, 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 going to be on, you know, the

Calvin (20:50)
Yeah, yes.

just the proofs as well.

Yeah.

Yes.

Stephan Livera (21:15)
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, know, storage and ⁓ computation costs for that bridge node.

Calvin (21:25)
Mm.

Yeah, so the bridge node, we call it a bridge node because ⁓ it’s bridges like the current Bitcoin nodes and UTreeXO nodes. ⁓ So what 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, 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. so like different node types could be, you could be an archival user Excel node and not create proofs for new blocks and transactions, or you can be a pruned bridge node. ⁓

you don’t serve the historical blocks, but you create ⁓ proofs for new blocks and transactions. You can be both, you can be a bruised node and an archival node, but that’s not a requirement. Yes. ⁓

Stephan Livera (22:38)
That’s not the only case. But I guess it’s probably fair to say, would you say most of the, let’s say hobbyists

or kind of people who are trying to quote unquote, help this network grow, they would just do both, right? In practice.

Calvin (22:50)
If

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

Stephan Livera (22:56)
Gotcha, yeah. And so I think you might have told me this last time, but it’s basically like storing almost like 2x the current blockchain size to be that bridge node. But again, 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.

Calvin (23:05)
Yes.

The historical proof size is slightly less than the entire historical block size, so about 2x.

Stephan Livera (23:24)
Gotcha. And so also how do these UTreeXO nodes find each other, right? Whether that’s UTreeXO nodes, bridge nodes or compact state nodes.

Calvin (23:30)
Hmm.

Yeah, so you don’t differentiate between the bridge nodes and archival nodes, but you do differentiate between 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, I’m an archival node, then there’s a message flag that you send to your peers saying, hey,

this is the like the 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 UTREXO nodes, you would also like advertise that, like I’m a node UTREXO to say that, hey, like I understand the UTREXO 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. you can, so like, like you, if you want to do this, are able to just store the historical UTXO proofs. And so what the ID, the node with the

be doing is that you would get the blocks from ⁓ a current archival node and then you get the proof from a UTXO archive node. So it’s very modular but as you mentioned, most people would just do everything. So they would store all the historical blocks, all the historical proofs and then be a bridge node as well where ⁓ you proofs for new blocks and transactions. But they’re very modular.

Stephan Livera (25:09)
Okay, yeah.

Yep.

And for now, are there bridge nodes operating? presume you’re operating one and is it 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 going to be, who’s going to do this bridge node role?

Calvin (25:30)
Yeah, you can choose.

Yes.

Yes.

Right.

So yeah, at the moment it’s just me and Davidson. ⁓ 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 coordinating like how to get more Bridge Notes up for that. But in the future, I sort of envision like, maybe it’s not a good comparison, but I sort of see the comparison as like the Phoenix wallet, like the Lightning wallet where

Hey, you don’t like not every Lightning node needs to be like the service node. Like you don’t have to like transmit payments, but you could just be connected to one of them and ⁓ you can transact funds that way, but you’re not like, 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 wallet app, then I just connect directly to their Bridge node and then they will be like,

giving me proofs for blocks and transactions. the assumption here is that you’re trusting them for the data being provided, but you’re not ⁓ entirely trusting them. You’re still validating that data that they give you. So they could admit the data, but they can’t lie to you. Yeah. Yes. Yeah.

Stephan Livera (26:52)
Yeah, gotcha.

That’s correct.

they can’t lie to you and trick you into believing you’ve received a transaction that you did not receive. And that’s the important point here. And I guess I’m also

now 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. so there were and are people who just run public Electrum servers and they’re just kind of publicly available. So I guess this is kind of a parallel 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.

Calvin (27:43)
Right, yeah.

Stephan Livera (28:00)
UTREXO bridge nodes and ⁓ UTREXO archival nodes who just kind of serve up the proofs because they just want to help the network kind of thing and help these people be able to use Bitcoin easily.

Calvin (28:12)
Yeah, and I also want to mention that Thomas V was actually super interested in UTREXO because ⁓ he wants to make the electron wallets ⁓ more trustless as possible and UTREXO would allow. Yeah.

Stephan Livera (28:24)
Gotcha, so maybe this would be something he would be interested to support in Electrum Wallet.

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 is he 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.

Calvin (28:37)
Yes, David, since, yeah.

Mm.

Yeah, so Floresta is a full node implementation that ⁓ doesn’t keep a UTXO set, like doesn’t keep the entire UTXO set, but ⁓ uses UTXO to ⁓ keep up, to be in sync with other nodes. And so this is an 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 put it in their existing wallets or services. And so this is a project that ⁓ makes it possible and allows some ⁓ bootstrap ability for existing wallets and other maybe companies that are interested.

Stephan Livera (29:36)
Yeah. And I think it’s also really interesting because instead of users being, ⁓ sort of, guess it allows, yeah, like we were saying, comes back to that same idea that it’s like 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, let’s say a more trusting client server model. This is like a validating client model, let’s say. ⁓ and so.

Calvin (29:59)
Right.

Yes. Yes.

Stephan Livera (30:05)
Utrex OD as you ⁓ as I’ve seen in the documents and stuff Utrex OD is I guess the implementation the code of this so can you explain a bit about Utrex OD what it is yeah

Calvin (30:16)
Ah, okay.

So UTreeXOD is everything that’s in the BIPsec. It’s everything UTrix are related. So that includes, So yeah, so it’s like, hey, like it has a 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 basically like a…

Stephan Livera (30:25)
Right, it’s like the practical implementation of what you spoke about in the bips, let’s say.

Calvin (30:44)
I would say it’s a reference implementation of everything related to UTreeXO. ⁓ Floresta is a more very specific version of that, where it’s just a compact state node, and it has a lot of features that UTreeXOD doesn’t have, like these bindings to other languages. It also supports ⁓ this ⁓ softchains SPV thing that uses UTreeXO as well. So there’s a lot of features, but all those features are geared towards, hey,

Let’s make this the node for like grandmas.

Stephan Livera (31:19)
Gotcha, yeah, okay. And so we can think of it like this. A lot of the UTreeXO archival nodes and UTreeXO bridge nodes, they may run UTreeXOD, whereas 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 you’re proposing, they are kind of like, if someone wanted to implement their own version of UTreeXOD or some…

Competitive to you tree xod. They would need these bits to sort of understand the the method by which you check So is being done. Is that the right understanding? Yeah, gotcha. Yeah

Calvin (31:53)
Yes, yes. So with

all the information provided in these BIPs, you would be able to create a ⁓ client that is able to communicate and keep up with the UTrix OD nodes and the Floresta nodes.

Stephan Livera (32:10)
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 want to build something here because maybe they think, Hey, I want to build a compact state node wallet or app or something like this. And, I want to use Flores to as part of my thing. So, what are you looking for from here? Like, are you looking for review builders to kind of.

Calvin (32:18)
No. Yes.

Stephan Livera (32:40)
Build on this or developers to help contribute. What are you looking for?

Calvin (32:44)
⁓ For the moments, we’re just like, hey, this is what we came up with. We talked about UTREXO for years now, but we worked very hard on the specs. The specs are actually, we sort of went the extra mile where it actually supports a lot of ⁓ caching, and that was sort of tricky to figure out. so…

Stephan Livera (32:51)
Right.

Calvin (33:11)
We want reviews from builders that are interested in Uterix though and take a look at this and say, hey, this is cool or hey, why don’t we do this? ⁓ So I guess we’re looking for ideas with the BIPs.

Stephan Livera (33:27)
Gotcha. Yeah. Now also, just to touch on this, this whole idea of different Bitcoin implementations, as I’m understanding from you, UTreexOD is based on BTCD, which is another implementation of Bitcoin. So as listeners may be aware, there’s 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, BTCD and building on that?

Calvin (33:39)
Yes.

Yeah, so BTCD is an implementation of Bitcoin in a language called Go. ⁓ right now, it’s a node as well, but it’s also a library as well. So a lot of developers that implement wallets or like, especially something like the lightning nodes or like LHD, it relies heavily on ⁓ using

the BTCD libraries to stay in consensus because they don’t want to be implementing all these ⁓ basic Bitcoin messages. So that’s what BTCD is. ⁓ And it’s mostly at the moment, a lot of people from Lightning Labs work on it. ⁓ So we have BTCD. then originally, the UTreeXO implementation was in Go, the same language. And it’s

hard to work in between languages. So it was the natural choice to ⁓ fork BTCD and then to put UTREXO in. so, yeah, that’s the relationship with UTREXOD and BTCD. I should also mention that the UTREXOD code base and BTCD code base is very, very similar. There’s only a few differences. And so I contribute nowadays heavily to BTCD as well.

Stephan Livera (34:55)
Yeah.

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 their 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 Korea? What’s happening these days?

Calvin (35:22)
Okay, so that’s the question.

nowadays, ⁓ lots and lots of activity. ⁓ we have, so yeah, there’s, ⁓ beginning of this year, we’ve created an organization called the Bitcoin Social Layer in Korea. And it sort of allows people that are like doing individual work, like they’re all sort of separated, but then ⁓ it’s…

It’s hard to get things moving forward in Korea. There’s a culture of doing things together and this organization helps us do that. so there’s a lot of activity on like meetups. ⁓ Meetups are hosted by BSL 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. then after, and then besides that, so we also have like, there’s a mining ⁓ sect, like a mining guild in BSL as well where they’re teaching people how to mine with like bit axes. And if they want to do like commercial mining, this is where people are like doing things together to like sharing knowledge and then.

figuring out ⁓ how do we profitably mine in Korea. ⁓ Other things are there’s a payment skilled where they’re trying to ⁓ get like basically orange pill local shops in Korea. So now there’s over a hundred shops in Korea accepting ⁓ Bitcoin and Lightning payments directly. there’s actually a separate website like btcmap.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 when we originally talked about UTREXO two years ago. So I’m very happy with that. ⁓ yeah, we’re also, so with the help of BSL, we’re also hosting a conference later this year that’s very like entirely community-based. So like lots of things going on now.

Stephan Livera (37:52)
Yeah.

Fantastic.

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 nodes and See how things go there. Of course, I mean that would be if they’re taking on chain payment obviously lightning and arc and Liquid and whatever else is different. But yeah, so we’ll put all the links in the show notes for listeners to ⁓ Stay up to date there. And yeah, thanks for sharing ⁓ sharing with us today

Calvin (38:09)
Yeah. ⁓

Yeah, thanks for having me.

Leave a Reply