Floresta: Making Bitcoin Node Verification Accessible

As far as I know, most of this stuff has never been tried, so we're like poking the limits here. Every time you talk, talk with people, like, you install this, then you configure this, then you install that, and users are like, "I'm not gonna do this." With Floresta, you can have an extremely lightweight node that still gives you like excellent privacy and security. The goal of Floresta is to get something like in the middle that can give people better trade-offs, but still being lightweight and something that the average user can, can run or like average hardware.

Welcome back to Stephan Livera podcast. Today, my guest is Davidson. Davidson is a Bitcoin developer and working on the, well, known for the Floresta project, which is an interesting one, I think, it can have some interesting implications for you, whether you're a Bitcoin developer or builder, or if you're just an end user. so we're gonna explore some of this, as well as how it relates with UTXO, which, you know, listeners, you might have seen that from, my earlier episodes with Calvin Kim. But, Davidson, welcome to the show.

Yeah, thanks for having me.

So, Davidson, just give us like a very quick background on yourself. I know you're coming from Brazil and you've, been doing some interesting stuff on Bitcoin development.

Yeah, I've been working with Bitcoin Open Source for three years now with a grant for Bitcoin. I have a degree in computer science and, I've been doing Bitcoin stuff in the background for, I don't know, eight years. And my main project now is Floresta. It's a project that I started as a like a side hustle, but became a, a like actual thing. So I've been working on this full time basically like two years now.

Okay, so let's start with that. So what is Floresta and what's the goal here?

Yeah, so the main goal here is to explore Different trade-offs sets for Bitcoin clients and to provide alternatives. So with Floresta you can have an extremely lightweight node that still gives you like excellent privacy and security. And it's something that, I feel like we don't have this in Bitcoin right now. We, we, you either have to expend all the resources in like actual full node with, you know, all the hardware requirements that you know you have, or you complete it through someone. the goal for us is to get something like in the middle that can give people better trade-offs but still being lightweight and something that the average user can, can run on like average hardware.

Okay, yeah. So I guess let me just try to contextualize this for listeners who aren't As technical or aren't as into the weeds here. So when we use Bitcoin, you have to connect your wallet to something so that you can understand what is the state of the chain, what are my transactions, what is my balance. And typically, the way people are doing this, like what most people are probably doing, is just trusting a server with, telling them what are their balances, what are their transactions. Now, there may be some SPV, elements built into that, but generally speaking, there's a lot of, quote unquote, trust Bro involved, and then on the other end, people might be running, let's say, you might be running an Umbrel or something similar, a Nodebox, and in practice, what people might be doing is they might be running Bitcoin Core and an Electrum server, and then having a wallet software, maybe it's Sparrow, maybe it's Nunchok or something like that, and pointing to that Electrum server. But the challenge then is it requires someone to run, you know, a much more involved setup, it requires, you know, cost, time, e-expertise Even, so I-- that's kind of my broad, high-level understanding. Can you give us an idea what could it look like in a Floresta world? What would that trade-off look like for the end user?

It's extremely lightweight, so just to give you a context, I run it on mainnet right now, it uses three hundred megabytes of disk and like two hundred each megabytes of RAM, so it can run on any device basically. And, Regarding like the se- actual security model, w- you can actually choose. I don't think the final user will, will choose this, we can talk about this later, but, you can actually choose which security model, y- it, it's fine for you. There is the proof of work, proof of which we'll also talk about in a little bit. there is the Asmuth-Trexler that you can use, and you can do IBD regularly. So you, you can actually tune it to, like, I, I, I'm fine trusting the binary with Asmuth-Trexler. So it's the, it's the Trexler version of Asmuth-Trexler. so there are different trade-offs you can make, but they are all, like a big improvement over what we have nowadays. But, you can run if you want, you can run it just with the same trade-offs as running a Bitcoin Core, like you, you validate everything from genesis to to tip. It takes a little while obviously, but, you can do that with minimal hardware. You don't need to have like, good SSD and all the stuff you need to, to have to run like, a regular node because you're not gonna be using that. So you can basically do that in, like, more more attainable hardware.

Yeah, I see. And just to, again, to contextualize for listeners who aren't as familiar, if you run your own full Bitcoin node and you, like, are running, you know, what's called an archival node, the chain today is something in the range of eight hundred gigabytes and Obviously, it takes some time to actually run what's called IBD, initial block download, and so as you mentioned, this would dramatically lower that requirement, and so then hypothetically, you know, the, the proverbial grandma per se, or just someone with a, a phone can have, a client that is validating, in a much- You know, better way than, I guess what that, what a lot of those people are doing today, which is just basically, quote unquote, "trust me, bro," or at least it's closer to the trust, trusting the server basically.

Yeah. And, another improvement is that when you are using a collector, which is the protocol we use to talk with those servers, you're giving the, your wallet's scripts, like your addresses, to those servers.

Right. It's like a full privacy doxing. Yeah. And just to be clear, what From guys, the reason OG, it's an OG wallet, before my time, but they were from like twenty eleven or twenty twelve, and Thomas has explained like at that time, his concern was a lot of people are just gonna trust exchanges. And so what is the way to have people be able to at least hold their own keys, but, you know, trust Electrum servers to an extent, and of course, as you mentioned with privacy. So it was a step forward at the time, but now there's a lot of people who are using that and without knowing, unknowingly many Calling out and it's basically they might be connecting to random Electrum servers unless they're connecting specifically to their own Electrum server, like if you run the Umbral or Minister of Nodes node box or something like this, then you are effectively just kind of doxing out your coins to Unknown servers, right? And it's been known in the past that Chain Surveillance and other people will run those Electrum servers for free, because that's part of their business model to help sort of, can I, can I

quote right? It's like the most obvious money pot you can have is running a electric infrastructure, 'cause people are willingly giving you their addresses.

Yeah, and so basically this is another reason where people, you know, in the Bitcoin, let's say, world, people talk about running your own node because it helps you from a privacy perspective, as well as just kind of operationally, you need to do it if you wanna be able to be sovereign.

Yeah, so with Floresta, you keep track of your balance locally, and we have something called Watch Only Wallet, Watch Only Wallet that keeps track of your transactions, you give it a xPub or a descriptor, it will keep track of your, like your transactions, and when you connect your wallet to it, your wallet can request those transactions and fetch the balance from your own running Floresta, so you don't need to dock yourself to anyone else.

And so can you just spell out a little bit about what it, what it is? So as you've mentioned, it's a UTXO powered Electrum server. and so can you just talk us through what that That means, like, what does that mean for the end user? Like, you run this and you can just point your Electrum wallet or some other Electrum, like, a wallet that speaks the Electrum protocol per se, to your Floresta, and that way you're, it's like you're running your own Electrum server, right? Yeah.

That description actually needs to be improved a little because that's the same description I had since I started the project. But, yeah, that's the idea. The idea is to have something that is, has the least amount of friction as Having to install multiple binaries and configure everything. Every time I talk with people who are not technical and say, "Oh, install Bitcoin Core and then, like, an election server," they're like, "No." Can't install like one thing and use it, so the idea is you have everything you need in one package. there is the Actual node that does like all the validation stuff, downloads things from peer to peer, connecting with other Bitcoin Core nodes, validates everything, keeps like track of, transactions and, addresses. There is the watch-only wallet that, where you give your xPub, your, your descriptor, and it keeps your, keeps track of your transactions. And there is, election server. This is not a full indexer like Electrs, because those you can request like any, like any script, any address that received transactions in the whole history of Bitcoin. I frankly think this is useless for like my mom. She's not gonna like look at every single address that ever received Bitcoin in the whole history of Bitcoin, and that index is kinda big, like a hundred gigs, depending on the implementation, so it only keeps track of your own transactions. That's like all it can answer. And that's okay for like most people. And just to be clear,

does that mean you need to, just, because this might be come up as a question, do-- does the user need to input their, as you said, their xPub or output descriptor? before starting, Floresta d so that it knows to watch for these particular, you know, addresses or can you just like put it in later and it will then have to do like a rescan? You can

put it later, you just need to use something called compact block filters. we, we support this by default. It's a, so, it's a way for you to like do rescan, so try to find, historical transactions in the chain, but without needing to download the whole chain, because Floresta is pruned by default. So you don't keep the old blocks, but you can use compatible filters to find all the transactions, and, you can use that, you can add your addresses at any time, and there is a possibility of not even requiring that It requires change to the wallets that, use the Electrum server. I, I actually proposed this to, to the Electrum guys and they are changing the protocol, but this thing's taking time to, to go through. I think they're calling it version one point seven, if I'm not mistaken. if you replace, do you want to go to like the nitty-gritties here or just say that it's possible?

Okay, let's, yeah, so let's just start with that. And I guess just again, for people who aren't familiar, Because I presume here you're talking about like what's known as Neutrino or bit one fifty seven, one fifty eight, yeah?

Yes, one fifty seven, one fifty eight.

Yes, gotcha. Okay. And so my understanding with that is that was a, that came up I mean, it's been around for a little while, but basically it came up because what was there previously, this bloom filter thing, was not that private, and people were like, "Okay, why don't we have this?" And it was, as I understand, it was used in some wallets, like even in some of the early version of Breeze had this, but as I understand, it's not really that popular nowadays, at least in like mobile wallets. can you talk a little bit about that?

Mobile is always hard, like there's- And we can talk about mobile, but it's always hard. Like we, we, we try some experiments and it's really hard. But, on computers, it's fine. I think Bitcoin Core is moving to perform the, the his wallet request using filters. it just builds the filters locally, but it can use it. And, I think for desktop it's, it's completely fine. you can, you know, like, LND, the implement- like implementation can run it with Neutrino. Neutrino is a specific implementation of compact block filters by Lightning Labs.

Right. And

you can use Neutrino's SPV and compact block filters. And with BDK, you can use BDK with compact block filters using something called Kioto, which is, also an SPV client that uses compact block filters to find stuff. So anyone who uses BDK can use compact block filters. So I think Like the tooling is getting better, so more people are probably gonna use it. and the advantage of using with Floresta, like Floresta and Compact Block Futures, is that you, you're not SPV, you are actually validating, so you're a full node with Compact Block Futures. But, With compact block filters, you can find those old transactions on chain without needing to go through all blocks.

I say, yeah, and so my understanding is it's sort of like a fancy way of filtering and understanding which blocks you, the user, are interested in, and then you fetch the entire block. so that way you're kind of doxing less about w- exactly which transactions you're interested in, and therefore in that way it's a little more privacy preserving. Yes. Is that correct? Yes,

i-i-it is built for every block, and it contains the, like, let's say the addresses that's being of your tokens being created and for your tokens being spent. So you, you, i-in the future you can ask it like Here's my, all my addresses, it's actually scripts but let's use addresses. Here's all my addresses. Does any of those addresses appears in this block? And the future will tell you definitely no or maybe yes. If it seems maybe yes, you download the block and you look for whatever you like your address is, whether it's in there or not. And, w- it, it also has a false positive rate. It's like a probability of the structure, so it says sometimes that it is, and but there, there isn't. And, this is actually good.

It's kind of like bluffing that I need that block, even though I don't really need it just for the privacy-preserving part. Okay. Yeah.

It's not like the reason why the filter does that is not for privacy, it's like It's how it works, but it's good for privacy, because you can then download some blocks that are like decoy blocks, you don't need them, so people can correlate, like, look at the blocks you're downloading, these are the blocks you are interested, like maybe I'm not interested in the block

at all. And one other question actually, just because you mentioned scripts rather than addresses, does that mean it only works in certain like script types, like, or does it handle everything like P2SH and P2Wsh as well as P2TRoot, or is it only like one specific thing that it supports or only the newer stuff?

No, it, it supports any, any spendable script, I believe. I, I think it doesn't index OP_RETURN and things like that, but anything that is spendable, it, it can. A, and like if you were addresses, then you couldn't, Some scripts that don't have addresses associated with them, like non-standard scripts. Okay. so they, if you were scripts, you couldn't do some weird types of, outputs, but I believe every single script, whether or not it's standard, I think it goes into the filter.

Okay, okay, gotcha. Okay, so let's talk a little bit then. So, yeah, we're sort of talking a little bit high level, but can you just give us an idea of who do you see as the users of this, and then we'll get into So let's just start with the users part. Who, who do you see as typical users of this, of Floresta? Yeah,

I usually think about like the non-technical people that aren't gonna like run weird infrastructure on top of it, that are just, I, I need something to connect my wallet with and, do my Bitcoin stuff. So less technical people, people who don't work with Bitcoin at all, like just have some stash of Bitcoin. So basically general public, like people who want to have better, security and privacy But doesn't want to, like, have Bitcoin Core or whatever. I

see.

It's like more resource footprint, that's usually the type of public that I'm targeting. This is why I can make trade-offs like, "This is proven by default," because I don't see people who, like, normal people going through like old blocks and like processing old blocks and working through

them. And for now, this is a desktop application only, but the idea is it could be used in some kind of mobile app.

Yeah, it's, it's a demo. it works the Bitcoin D, you run on, you run like your demo. we have plans to make a actual app for it, like some, with some UI and things like that. there is work to, because Floresta is also a library, this is another thing I, I put a lot of emphasis in because I don't really think the end user is gonna use Floresta directly. I think this is not the way to go, maybe, maybe exactly because of the, like the attract thing, like too many things to run. So Floresta is a library, you can embed it on anything. It's like written in Rust, so you can call it from any other, language, and you can use it, very easily, the, the same way like BDK, you know, have applications that use BDK that are written in Python or that are written in, like, Java or other languages. You can do the same with Floresta. It runs on this, under the same application. So let's say you open a wallet, on the background, that wallet starts Floresta and it's running there, the wallet's like asking Floresta for stuff. And, you don't need to like open up a bunch of different applications and leave things running that you don't even know what it is. So there is this, library component that can be reused. We even have someone working on integrating it with BDK, so users of BDK can And use Floresta as, they call it, the chain source, which is how you communicate with the blockchain, you can use Floresta. and, the mobile things is more like experimentation. Last year, me and a group of friends we won a hackathon here in Brazil, with a wallet, was a BDK based wallet that also ran Floresta in the background, so everything was running on the, the same app. And, you could like fetch your addresses and everything locally, so you-- the only communication you did was normal peer-to-peer communications. It wouldn't be doxing you, it was validating everything locally.

Fascinating. Okay, so the way I'm understanding it then is you envision end users not really using Floresta, like if you're talking about proverbial grandma or mother,

It's more like developers might package this into an app, and it will use either the library in the background to make it accessible to have better security in Bitcoin and maybe better privacy compared to just doxing your addresses to the Electrum server.

I feel like this, like, we're still, this probably is very experimental. We have to So the listener should take everything here with a grain of salt, because as far as I know, most of this stuff has never been tried. So we're like poking the limits here.

Yeah.

But, right. But,

well, I guess what we're saying is this is the goal. The goal is that- Yeah. I feel like this is the best- This is

the best UX, right? Every time you talk with people like, "You install this, then you configure this, then you install that, and then, like, users are like, 'I'm not gonna do this.' But if you say just, "Install this, " and everything will be running, they are like, "Okay, it's just one thing. It's like, oh, it's unfortunate, but that's usually how most people's brains work." So I feel like this is the, the, the best UX you can deliver.

Interesting. And look, if you-- if, if it does get proven out, then maybe Floresta gets built into existing You know, Bitcoin apps. So I guess let, let's explore that for a second. Like, could hypothetically, like, let's say this all works out, could it be built into existing Bitcoin phone apps that people already know and use? Like I don't know, like a nunchuck or a, a blue wallet or a, these kinds of, you know, typical on-chain wallets that people already do today.

Yeah, it's like a hundred percent. And the way I'm working with it is making it easy to do that transition. So it's like I don't know, five, six lines of code that you need to change. Because it's election, so you already have the election infrastructure, like you have the election server, you just need to install Floresta, like you configure Floresta, you start it, and that's it. Everything else I'm doing for you on the background. you just need to connect with your local election server, and everything else is transparent. So the idea is, if this works out, everything we are trying to do, we can actually pull it off, Having existing, existing applications just replacing their electron infrastructure with, with this, and, it's very easy for them. Like, i-if it was too difficult, I wouldn't reasonably expect them to do that, but it's so easy to do that, I, I don't see why not.

I see. And so, just to give people an idea then, it means if, if people were to go down this pathway of using, quote-unquote, assume you tree XO, it means like a user could just, you know- Install one of these on-chain wallets, like, like we said, a Blue Wallet or a Nunchok or maybe the Blockstream app. Basically any on-chain wallet today that calls out, that can call out to an Electrum server, which is many of them, basically all the good ones. They could just like install this app and basically just like straight away be ready to transact.

Yeah, and, be validating everything from the Asmuth check so onwards. So like your transactions, you're actually validating those blocks.

Interesting. Yeah. So let's, yeah, okay, so let's explore a little bit, maybe one step deeper, how does this actually work? Because as I understand, it's like you're combining a few different ideas here. Like you've got this, UTXO concept that you're leveraging, you're leveraging this proof-of-work fraud-proof method. And like Electrum servers and kind of rolling it all together, that's how I'm understanding it anyway. Can you just maybe sort of take it one step deeper? How, like, what's going on in the background here?

We, we have a bunch of different things playing together. Flores, we have like different modules that implement everything so you can like poke around and, only use some parts, like the BDK thing, want to use Electrum and want to use the Watchon wallet because BDK is our wallet, so they're only gonna use the Both functionality. So everything is separate and, we have a, Bitcoin core compatible JSON-RPC. We don't have other RPCs yet, but we're trying to make them, so it's gonna be easier for For example, let's say on loading your box once you have a lightweight version, and so like Umbra, for example, they can have this and they don't need the applications changing their RPC to support Floresta because Floresta is compatible with Core, so it's like a drop-in replacement. we have the election server, we have, compact block filters, and, a few other stuff. So it's everything that this is like the interfaces you, you can communicate with, with Floresta. We, we, we're not trying to do anything new because we know new standards are just like More noise, we're not gonna make the whole industry change for a new standard, even if the old standards are not that good, so we are just like, okay, you already have this, let's implement this and you can communicate with us more easily. And, in terms of technology for the node, we have We have like for IBD, which is the hardest part every time, like every time you're talking about nodes, the IBD is always the most complicated part. there's three ways you can do this on Floresta, and that we- We have different ideas on where each of them, goes better. you can do IBD regularly, like any other node would, just start from genesis and download blocks and validate every, everything until you reach it. there is a Sumitrixo, which is the UTXO version for Sumitrixo, where you assume that a given, block is valid. So let's say block nine hundred thousand something is, is valid, like everything before it is valid. And in the binary, there is the root, like the accumulator state for that block. So you don't need to go back, those other blocks should know, what's the current state of the network, so you can start from that point and download and validate everything that comes after. So You, you start at the block and you validate everything after. And then in Floresta, you implement the same way that Bitcoin Core does that you, you can go, like you can start split your validation two parts, and then you have one part that start on that block where you assume, so let's say we, we assume block nine hundred thousand. we start about nine hundred thousand to tip, like, I think it's nine hundred, nine hundred and ten something like blocks now. And another thread starts at genesis and go all the way up to block nine hundred thousand. So you're still validating, but your nodes is ready to use, faster.

Right. So it's like a, like a back-sinking or how does it, like, what's the right word? It's like a parallel backfill. Backfill, yeah, that makes a lot of sense. So it's like the idea is you could quickly, quickly start- But actually in the background it's also doing this backfill to make sure you are on the correct chain and validating that.

Yes, and then when you arrive at block nine hundred thousand, you compare with what you had in the binary, with what you obtained, and then if they aren't right, something's clearly wrong. Like they're not equal, something's clearly wrong. In Floresta you can't disable this backfilling, there is an option for disabling it. I think in Bitcoin Core you can't, you always have to backfill, but, we have this as a feature in Utxo. And then you can optionally do backfill or not. If you choose not to do backfill, it's just gonna catch up with the blockchain in the, you know, the set. And there is this More like unexplored part with its proof-of-work fault-proof. And this is an old idea, I think, 2017, by Ruben Samsel, but as far as I know, no one actually implemented it in like, actual software. Production ready software. It, it allows you to skip IDB completely to a fairly recent block, as, and, and you are safe, like you are following the correct chain, as long as, you're not single, like you're not being exploited. Which is fair to the same assumption for every node, like if you're a clip, so they can make you accept, the least work chain. Yeah, sorry,

just before we go into this, let's just summarize a few points there. So you said that you can do like a, just like, you know, standard IBD, just download the chain, but that's, that's like one way. Another way is assume you're true XO. With backfilling or not. And so I just presume then, if you are on a phone, you're probably not gonna backfill, but if you are on a desktop, maybe you would. That's like loosely how it might work. And then maybe that's how developers of apps for the desktop or for the phone, that's probably how they would do this. And then-

Yeah, that's, that's my thought.

Right. And then, and so now let's get to this proof of work fraud proof, thing. So can you just like maybe let's just start with, you What's the goal of that and what is that?

It's a way to validate like super fast, because you don't have to validate blocks, you basically skip validation. But in a way that improves simple SPV. So simple SPV, you have this assumption that 51% of the miners, like of the hash rate, has to be honest, 50% plus one, and, if they aren't honest, they can attack you, they can make you accept invalid transaction, and, there is no way for you to, like, know. they are doing something wrong. Satoshi introduced this term, he mentioned something called fraud proofs, which is nodes can tell you, tell you like, "Hey, this, this chain is actually valid because of this," but, it's very hard to make fraud proofs because they are verifiable. So it never worked out the way Satoshi mentioned in the white paper. proof of fraud proof, is a, it's not really a fraud proof, like Kinda sorta, but it's, it's going the same direction. And the, the idea is this, like, can I skip IBD in a way that I have better security than SPV? And that I can actually find, invalid blocks. I can actually determine that this block is invalid for some reason. So like this main chain block is invalid for some reason, then I can switch to the, like, least work chain, but that's the correct one, and then I can follow the same network that a full node would. If that makes sense.

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 generation to transaction signing. You can power the device using three triple-A batteries, so you don 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 multisig 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 other devices and level up your self custody today. And so the idea is you can quickly get up and running, and A bit about it, as I understand, it's like you're trying to look back at some of the recent blocks to understand was there a fork or at least a fork attempt in that, in those last, you know, few blocks, might be like a hundred blocks or whatever it is, and as I understand, that's tunable, and then the idea is you're looking at that to understand, kind of in a loose sense, how confident am I that I'm on the correct, correct chain?

Yes. you basically assume that some percent of the hash is, is honest, it can be 90% of the network hash rate for Taproot is, but it, as long as some hash rate is honest, like some miners are honest, they're gonna create a fork because there is an invalid block They invalidate this block and then they start working on alternative block, so they create a fork, and then there's two blocks in a single height. So what you do is you look for those, and then you, you try to tune this to not get any, like any block you can find, because otherwise it could be lost as well. but like with a reasonable amount of work, you look at it and, you download the main chain blocks. And rewind your state, like basically validate that block as anyone other node would, and you'll figure that that block is invalid. So you now know that block is invalid, you just invalidate that whole chain and go to the other chain. So because those miners are very, very guaranteed to find a block in the last, like, say, two hundred blocks, there, there should be at least one block for this minority. You, you can be very sure that if there is none, there is no fork, then, either there is a hundred percent collision for the hash rate or that those blocks are valid.

Does the headers chain play into this at all? Like you would see what is the, at least what is the network telling me the latest? Like headers chain is, and then you're looking back at the last, I don't know, hundred blocks, this, doing this, yeah, it's

everything,

right?

Everything is done with the header chain, yeah. If you look at the headers, you'll- Sum up the work using headers, and, you see the, like the different chains. you always start assuming that the main chain is the valid one, and then you look for forks from the main chain blocks. And if you find a fork from the main chain block, you download the main chain version, like the main chain is the most work chain you, you could find. you, you take the Version for the main chain, validate it, and if it's invalid, you invalidate that chain and goes to the other chain. And you continue doing this iteratively until you only have one chain.

Yeah, interesting. And so then the idea that Ruben is putting out here, or that he put out, is this idea that you can raise the threshold for somebody to attack you from being fifty percent plus one to maybe it needs to be like ninety percent of the miners are trying to trick you, which, I mean, even that is already a pretty, like Like crazy sort of, imagine if ninety percent of the network was already malicious, then, you know, it's kind of already like, there's, you kind of already, you've got other bigger problems at that point, right?

Yeah, it's kind of bad if ninety percent of the hash rate is polluted. We can make it like close to a hundred, but we can't The problem is the bigger we make it and the smaller we make the lookup, the harder it gets to actually analyze because of variants, because blocks aren't found exactly like if you have 50% of the hash rate, you're gonna find 50% of the blocks. That like averages out over time, but if you start checking smaller, like smaller percentages or smaller intervals, then this just don't play out here because you have to have it all over like bigger intervals. But, you can make it over ninety percent, like you can just make a hedge close number, like at some point, you know, just solo miners will, will be able to find a, a fork and, Basically, yeah, get the, the majority.

And just to be clear here, what are we defining here as honest miners? Can you just explain that for listeners?

it's the same definition as the white papers, which is a node that's following the chain that's valid by consensus rules. It doesn't mean that the person is a good person, yeah, not a morality test, let's say. Yeah, no morality test. In context of Bitcoin full nodes means someone that's following the consensus rules.

Yeah, and that's, I guess, kind of broadly speaking, yeah, following consensus rules, and I guess people say this term heaviest chain, right? Like most accumulated proof of work chain is the one that people are following. Although I guess there was, even that, there was a slight, I guess, wording shift from the white paper to what's actually in practice there, but I guess that's, as I understand, when I talk to developers, that's kind of heaviest chain rule is what they

say. The longest is yeah, because longest could

actually be not the heaviest chain, and that's where this kind of heaviest chain concept came, as I understand it. As you can

make like, you can make lower difficulty chains, and this will be longer because it requires less work per block, so with the same amount of work, you can make a longer chain. but that's let less work. Gotcha. Anyway, let's,

let's just say that's kind of a technical point that, you know, basically all, all the Bitcoin developer, like hardcore Bitcoin developers already know that part, so, you know, we'll leave that. So just coming back to comparing the models, all right? So as you've, as you've explained, this is the, what we're talking about here is in the proof-of-work fraud-proof method. Let's compare that, right? So now excluding the Full node download, you know, download the full chain for yourself and validate everything. Obviously, that's the least trusting or the most trust-minimized model. If we compare proof-of-work fraud-proof method versus SPV versus tr-fully, you know, just trust the server. Can you just explain a little bit on the differences there? I know we were touching on this, but if you could just kind of el-elaborate a little on the difference between those three.

Yeah, it's, it's all about like, Being more sovereign about what you're doing, because with proof-of-work, proof-of-work, you also start, you can also know what's the state of the network for the block that you, you did this whole process, so you can actually start validating after that. So, blocks that come after that, you can validate them, you just don't validate the blocks in the past, and there is an argument to be made like, blocks in the future, like blocks that are new or blocks that are coming. Are more important to validate the older blocks because if, like, a block six years ago was invalid, like, what you gonna do about that? You're not gonna, like, I don't know, invalidate that block and undo six years of work. But a block that's coming out, like, the next block, it's very important for everyone to look at it because it may be invalid, and, we have time to do something if it's invalid. and, the, the security, like the, you, you always, when you talk about security, you're always talking about how hard it is for someone to attack you. You can't be a hundred percent safe, even your full node, your own blocks isn't a hundred percent safe, you can be eclipsed, for instance. But it's always about how hard it is for someone to attack you. The worst method in this case for like how hard it is for someone to attack you would be to trust the server, because, well, it's just the server. The server lies to you

and you're done, right? Like, 'cause they can tell you, 'You're done.' They can tell you you received coins, but actually you didn't, and your, as your vol-- your just like your client app at that point has no way to tell the truth or not,

right? Yeah, and, and, Just like by omission, for example, they can't just not tell you about a spending transaction for your lightning channel that spends the channel in your old state. So they, by just that, just saying like, "Uh, I don't know any transaction related to this UTXO," they, they, they are messing up with you, like, because you have to know that the channel point was spent.

Right. It's especially important in the L2 context, yeah.

Yeah. So ju-just by like not giving information, it's not that they, they, they craft information, it's just by not giving information. It's lying by, we call it lying by omission. Lying by

omission

Not telling you something, they can mess up with you.

Yeah.

So it's, it's gotcha. And so that's the,

that's like the full trust the server model. Now for an SPV context, that one is, coming back to, Like what, what are the ways you can be lied to or tricked? We're coming back to again the fifty-one percent mining, part of it, and you're not checking every rule.

Yeah, and, with SPV, which is just assume that the chain with more work is the valid chain, it's like it's valid, it follows the consensus rules because, there's this idea that the-- we assume that the The chain, the most proof of work, like the most amount of workers, they are honest, following the honest definition from before. So if the most amount of workers is in this chain, this chain must be valid because they are all following the consensus rules. And the way to attack you to fool you and to accept an invalid transaction, for example, would be to have 51% of the hash rate and, don't like getting some consensus rule messed up, like not checking some consensus rule, and then, no one's gonna check, like you're not gonna check it, so they can pass with that block, and then you're not gonna respond to it. And then, one people using, one like one person using it, nowadays it's very hard to get to one percent of Bitcoin. It's so big now that it's hard for just one, like the amount of hardware and electricity you need to get 50% seems out of reach for one person, one entity. Only if people do some weird coalition that they maybe can get, this big. Nowadays, I think not, it's not really that, I don't know, I, I don't look a lot of it, but it looks like it's hard nowadays to get fifty-one percent. But the problem is if everyone is using, SPV. Then you get a problem, because then they are very incentivized to do something nasty, because no one's checking. Like, if no one's checking, like, what they, they don't have anything to lose. Like, no one's checking anyway, so they just join together, like, create, you take, so, twenty-one million bitcoins for them, and no one's checking, so no one's gonna do anything about it. So the main problem here is one of, like, a philosophical problem. This is something that was debated. in Exile during the Blocksize Wars, because if everyone or like the majority of the network, of the economic, like the economic majority is using SPV They, they are even, miners are even incentivized to do this because no one is gonna oppose them. Like, right now, we assume that because people are checking, like the majority of the econo- like the economic power is checking, if they do something wrong, they're gonna lose their money. So they're incentivized not even try, because they're just gonna lose their money, like everyone's gonna reject the block, but if no one is validating. Then that means they, they don't get punished and, they can pass with changing, like, invalidate, invalidate block.

Okay. Yeah, cool. So, yeah, I guess we'll, we'll summarize that aspect of it by just mentioning, as you said, the proof of work fraud proof method just provides some, you know, some better, let's say, better trade-offs. for, a user who isn't gonna do the full, like, IBD and download everything. and it could, I guess, yeah, the idea can maybe be to help people get started quickly and ideally still backfill, so that they are then, Yeah, yeah, and it's important to,

yeah, it's important to remember that this is, you, you, you shouldn't compare this through an actual node. You should compare this through like SPV or the client, because sometimes people say, "Oh, this is worse than running a node." Yeah, like running a node is the best thing you can do, like it's the, the gold standard for doing Bitcoin stuff is running a node. But, right nowaday, most people are doing the, like the SPV or trust the server setup, so we're improving that

Yeah, gotcha.

Talk about proof of, proof of, proofs. Yeah, gotcha. Okay, so, let's talk a little bit about the relationship between Floresta and UTXO. So, f- as I understand, you have libfloresta-d, right? It's a library, Floresta, and then Calvin and the UTXO guys have UTXO-d. So as I understand, it's-- can you just explain a bit about that relationship there?

Yeah, this, this like, this works always, like, like a spec. It's more for like an idea with, the beeps and, and also, and then you need the implementations and, The actual UTXO stuff, like the accumulator stuff, is implemented right now, as far as I know, in two libs, one that Calvin work-worked with, it's called, UTXO, three D goal, and, I wrote the one in Rust, called Rust UTXO. As far as I know, those are, there is a partial implementation for StarkWare, but, full, like, full functionality, these are the only two implementations of UTXO I know of, and, so this is the actual UTXO stuff. And then there is the implementation of Bitcoin nodes that use UTXO to make the node functionality, so you have UTXO plus, like, peer-to-peer, block storage and all that. and the way we usually discuss this is EchxoD is more like, if you want to do something more like a replacement, a lightweight replacement to, BTC-D or Bitcoin Core, it keeps more stuff, it has more functionalities, because it's like a fork of BTC-D, so you can do basically anything that BTC-D can. So you may not prune, you can keep old blocks if you want, so it, it has more features, it, it behaves more like Bitcoin Core. it has more, more stuff that you can do. And Floresta is made to be embeddable, so for example, one thing we need to do that I don't think, Etrex doesn't need to work as hard as we do is binary size, because usually when you're talking about something that is like a library The size of the actual artifact is very important, especially if it's like mobile. If you have a library that's too big, people are gonna complain about it. And also it's like, we don't keep most of the information that Bitcoin Core does. We don't keep like revision data, we don't keep blocks. We don't keep a, like a ton of stuff, we just remove and remove a lot of functionality because we just want to be, like a super lightweight client. Our goal is to make something very lightweight and embeddable, like easily embeddable into other applications so people can build those, things we've, we've talked about. Understood. So it's like,

we could say Floresta is for a more specific purpose and it's designed to be embedded into Could be lower power devices, whereas U3XO and U3XO-D are sort of a broader idea that you are, like Floresta is relying on. But it's a, I guess it's a different piece of software, is the key point to understand.

Yeah. UTXO is, is the idea, UTXO D is just a implementation, right?

Yeah.

It's a fork of BTC D, it's a Go code, it's like a code base. the relationship here would be like Bitcoin and Bitcoin Core. So one is like a protocol, like a, an idealized thing, and Bitcoin Core is implementation of that. UTXO has two implementations, which is like two clients that use

UTXO. Right. The Rust Explain this. My understanding from UTXO is there's a concept of bridge nodes, and they serve up these proofs, and if you are, I think the concept, Calvin explained to me, is a compact state node. And so that's like, yes, the mobile client who's just downloading the proofs. So is Floresta- Helping people do, be a compact state node and then downloading proofs from the UTXO bridge nodes. Have I got it right there?

so this part is a bit annoying because there is actually two terms. Because you can, we talk, there is historical blocks and there is the UTXO set. Those are two different things. And UTXO, we actually separate this into like two terms and you have like different combinations. You have the accumula-the accumulator is like a big file that you need to keep to generate those proofs. So let's say you want to prove that n UTXO is indeed UTXO set, then you need to keep this structure, we call it a forest. You need to keep this all the way, like you need to keep this with you, you, you can't just throw it away. If you don't want to prove anything, then you can just keep a tiny portion of what makes this forest, we call the roots. it's less than one kilobyte, it's If you have the, the, if you have the ability to generate proofs, you're a bridge. This, this is what we mean to be a bridge. You have the forest, you have the whole thing, it's like twenty-something gigs of file, it uses a lot of I/O, so, you need to have a better computer to run this, but you're a bridge. And we, we need bridges because, wallets don't keep proofs for their transactions, so we need someone to generate these proofs on behalf of the wallets and attach to, to transaction blocks. if you don't keep this, you are a CSN, a compact state node. Floresta is a CSN, it can't operate as a bridge. It's one of the things like, where we make a trade off from UTXO that can operate as a bridge, and Floresta we don't want this because we don't think the users of

Floresta

will be running the then there is the archival characteristics of a node, whether or not it keeps, when we talk about UTXO, whether or not it keeps old proofs. So you have like every block, you have proofs for the block, which proves the UTXOs being spent, that they were in fact in the UTXOs set. The, so if you have all the all blocks and all proofs Specific all proofs you are an archive node, so you can be like a UTXO or like a CSV archive, you can be a prune node, prune it. Bridge, you can be like a, Tronnet SN, you can be an Archive SN. So there's four possibilities. Okay,

yeah, yeah, so it's a bit more detailed or not? Okay.

Yeah. So you can, you can actually run, I think there's some that doesn't, but ideally you can run all of them. So let's say I have a Bitcoin machine with a good SSD, but I don't have all the storage to store all the proofs, so you can be a prune bridge. I don't have a good SSD, so I don't want to generate the pre- to generate the proofs, but I want to serve the proofs through other nodes. then your, archive CSM. So there's like variations, it gets a bit messy, but Gotcha.

Okay, right, right. So, yeah. and then The bridge concept, as I understand, the, the idea, the, the person who's running that bridge node, that person is like a professional or, let's say, you know, like a, like a more technical person, and the idea is that the- Kind of the end user is just doing like Floresta with a CSN, compact state node sort of thing. That's loosely how it's gonna work.

We have this idea that bridge nodes are gonna be rare and most people run archives, so you can't generate proofs, but you can serve proofs for

blocks. And I guess just to be clear here, the cool thing here is that you, while the, the, the compact state nodes might be calling out to the bridge nodes, there's, there, it's a proof, right? So they're not Trusting, it's, they're able to actually know they

are checking everything, right? If the bridge nodes lie, a-and technically they connect with an archive node, right? They, they don't know they are connecting with a bridge. You just need someone that has the proofs. I don't know whether or not they can generate this proof. In theory, this is very flimsy, but in theory you can have just one bridge for the whole network, because once this bridge generates the proofs, it propagates through the SNS network and, the archive SNS will keep those proofs around So you just need to connect to those archives asms and they can serve you the proof. Okay. Just need one person to prove it.

Yeah, interesting. So, yeah, that's kind of a deeper concept. Okay. Well, I think we'll, we'll cut that particular thread. Let's go now to the node costs aspect, because this is a common, you know, talking point, people are saying, "Well, is the cost of running a node going up? " people having to run SSDs. Now, as I understand, today, a one terabyte SSD SSD is probably okay, but in practice, you would probably want like a two terabyte SSD for like run-- if you're like, if you're doing a full node, because you wanna be able to, if-- as in, sorry, to be clear, I should use the term archival node, right? If you wanna store all the blocks and you wanna be able to have some, some decent runway going out. but maybe you can explain for us a little bit of your thoughts, like what are the implications of some of this stuff, like UTXO and having Floresta, d What does that mean? Like as the chain grows, does that mean, you know, we might see, more interest in this kind of technology?

Yeah, especially the UX aspect. It's going up, now it's going down, but it went up a lot and it made really hard for some people to run nodes, I know. We have a big community here in Brazil of Bitcoiners, and, as far as I know, the biggest Portuguese-speaking server of Bitcoin is one that I and some friends run. And there's a lot of people who say, "I tried to run a node, it took like two months, so I just gave up." One thing that I, I usually, I, I need to talk down, that I see a lot of people, especially in the US, say, "Oh, it's just three hundred dollars." Have you remember that not everyone lives in the United States? And the three hundred dollars is the, I, I think three hundred and fifty dollars is the average household income like per person in Brazil. So every month. That's what you have to, the whole budget. So hardware is very expensive in the third world, and, in a lot of places even if you can't afford it, people want. So Calvin told me that in Korea, you won't have a computer if you like, you really need a computer, because otherwise you'll just have like a tablet or smartphone. So sometimes people just want. And I know a guy that he wanted to make a node but he couldn't because he had a small apartment and like the fan of the computer was pissing off his wife, so he couldn't run the node. I see a lot of people who say, "Ah, I want to run a node, but like run, buy, buy a separate computer and, making sure it's running twenty-four seven because if it goes down, your wallet can't work, especially if you, do like lightning stuff, connecting to that node, so that there's like- I really feel like there is a space for something lightweight. people come up to me and say that they really want something lightweight, something that you can run on your computer without giving away like a lot of the The IO or the, or the disk and, so I, I really think there is space for this, if you can run a node with, like, a full archive node, please do, because there is another problem called the data availability, like, you need people to serve this data to others, otherwise new people can join the network. But, the target audience for Floresta are people who are residential network, they can't accept incoming connections anyway, so they, they aren't gonna Help with this. Yeah, to summarize, there are several challenges in people acquiring hardware and running nodes the way we, we say, that would be the ideal. The main evidence for it is like, Bitcoin went up in price a lot, we think there is a lot more users, but last time I checked, the number of full nodes was roughly the same as 2017, 2018. So something tells me that people aren't running nodes the way we wanted them to.

Yeah, my Theory would be that there's a lot of people who, I mean, they've made money out of, or at least they've, their purchasing power has gone up, but, maybe it's not that much, not even that much about the hardware cost, it's more just about like ease of doing it, for people. It's a hassle. Yeah, because I don't, I don't even think the dollar cost of having, like, okay I understand obviously the case in Brazil is particularly one thing, maybe if you've got like all these import duties and costs and things, but at least even if we're just talking about the Western world, most of the Western world I, I would say probably most Bitcoiners in the Western world could afford to run a Bitcoin node, and they're still not, or a lot of them aren't, because for other-- I think it's for other reasons than just the straight cost of doing so. but I'm curious what you-- what do you make of that? Do you think it's an ease of use thing?

Yeah, probably there is a component of use, of use like a lot of people like, "Ah, too much thing to run, configure a lot of stuff." even with Node.js, you still need to do some things, you need to install like, OS and something, so they're like Not gonna do it. So this is why I, I, I really try to make the, the package thing like, let's make everything in one app or at least the least amount of apps possible and require the least amount of configuration possible so more people will, will do that.

Yeah. And I think for that, that's actually a really, it's a really cool idea. one other area around, second layer protocols, obviously like Lightning, can Floresta play nicely with those or is it sort of like that's a separate thing and it's not really, you should use something For that or is it more like, yeah, you still can do lightning with Floresta?

Most of the stuff that, like most of the lectures, the only problem is when they need to request, like arbitrary txs. Like lightning, any chain, every chain has a Associated UTXO, they call the channel output point, and, when you try to get these arbitrary UTXOs that aren't cached by the wallet, because they, they just ran on UTXOs, it gets messy. we, we can't right now find those UTXOs because we don't have the UTXO set, right? Bitcoin Core can just look through the UTXO set and find that UTXO. We don't have that, so, That parts hard. I made some, I had some talks, one in Berlin last, this year, with C++. maybe we can do this in an easier way. If, so most Lightning mobile clients are using LSPs, right? Most of the end users' wallet use some form of LSP. so if the LSPs can generate and provide this proof, it's very easy for them like hardware-wise, because you can have just parts of the, the forest of hardware-wise is fine, you don't need all the, the resources that you need for a normal bridge node. And if them can generate, if they can generate the proofs for those UTxOs, then we could, it could play nicely, like it, it would work very nicely. you could validate those, you wouldn't need to trust third party servers. For everything else like getting blocks, getting your, your own transactions, everything else it works out of the box. The only challenge is finding arbitrary UTXOs.

I see. So I guess for now you wouldn't recommend somebody run a Lightning node off, Floresta, but, but, I guess even if it just helps people do their on-chain stuff, that's already, you know, a pretty big win. There's a, there's another

way to do this that would need some minor change in the Lightning client. Which is how Neil Trina does, does that, using compact block filters. it also works, but, especially if you want to go the mobile route, it's kinda annoying. I've been told by some people who does that in mobile like wallet that, the experience can get very ugly there. especially if you are on a slow network, like a, worse network, you, you, the experience gets really bad.

Gotcha. So

There is this way it works, but it, it, like UX-wise, it's not ideal. The other way would be more ideal UX-wise.

Okay. coming back to just kind of how this could get used in practice, if we're talking about the hypothetical, you know, the proverbial grandma who just wants a, an app, or just say, like, someone who just wants a simple app on their phone, and they're not ready to sort of go to the level of running their own server at home and things like this. And then, let's imagine they're using some kind of Floresta technology built into, you know, their on-chain Bitcoin app on their phone. When they go offline and come back online, can you just talk to us about this because in this context, like, if you're talking about like a server that has to resync up to the chain tip, that's one thing, but how does it work in Floresta in an assume you try XO context? Is it just kind of re-downloading the latest, like, can you just explain a bit about?

Yeah, for the maturex, so if you go offline and come back, you need to redownload everything. But proof-of-work fraud proof, you can just redo proof-of-work fraud proofs. so if you, let's say you have three months worth of blocks that catch up, like you have to catch up, it's a lot of blocks, probably you don't want, don't wanna do this on your phone, so you can redo the proof-of-work fraud proof routine and just skip to there. Like latest blocks and, so the my DSM Trexo node, it's a problem for DSM Trexo is that if your binary gets old, you actually have to catch up a lot of blocks. So it's actually another challenge that you have there. Like, for us, the last release is very old, so right now I have to catch up like a few thousand blocks, so it, it takes a little time now,

even to run the proof of work for fraud-proof thing.

No, running the DSM Trexo proof of fraud-proof, we already- Always get you to a very recent block.

Gotcha, okay. And so I'm curious, do you think that would be a competitive UX, like given mobile, mobile apps and what the user expectation is nowadays, like do you think it would be comparable to just kind of open the app and it's already like it's loaded my balance, this kind of thing?

there will be degradation. I don't see how you can compete with server. Hopefully it's not too much to be perceptible, but I feel like there would be some degradation. There's no way you can make it com-compete with a server.

Yeah, gotcha. Okay, so, I guess summing up then, this project, this idea could help a lot more users be validating clients, as opposed to right now where there's a lot more trust being placed in The ser- of various servers. So can you just, I guess, sum things up and, yeah, any closing thoughts there?

I, as I say, I, I really think there is space for something in between, like some experimentation. Something may work out, something may not. this is why I don't- Make wild claims about it, but I think if you can manage to make something between, there is a lot of use case there, there's a lot of people that can benefit from this. if you have most of the economy using Bitcoin like a third party server, trusting kind of thing, it's gonna be bad. We've seen in altcoins things like a whole country being shut down from the infrastructure of a major service provider, it's not the kind of thing we want in Bitcoin. So, I think there is space space for some experimentation there. And, yeah, I, I think there is people that is gonna benefit from this. so if you're, like, anyone has any thoughts, especially on the UX side, because there is a lot of challenge there, we are always open to like feedbacks and thoughts from different people, even if you think like, "Ah, that's impossible, that's not worth," it's, it's always good to, to hear new opinions. So, there is the GitHub and there is, we have a Discord as well, so Looking for feedback. so far the reception of the product is being very good, very positive, and that this is why I'm sometimes a bit scared because it's too positive. I have to be missing something. So yeah, feedbacks are always welcome.

Yeah, well, I certainly think it's an interesting project, and yeah, it might be interesting if more people were to look at it. I will put the links in the show notes, but just reading it out, as I said, it's github dot com slash vintium org slash floresta to find the, GitHub, and I will link to obviously your X and your blog and some of the other links also in the show notes. yeah, and listeners, if you found this interesting, make sure to share it.

I'm here.