In this conversation, Davidson, a Bitcoin developer, discusses his project Floresta, which aims to provide a lightweight Bitcoin node solution that balances privacy, security, and usability. He explains the technical aspects of Floresta, including its architecture, the use of compact block filters, and its relationship with Utreexo. Davidson emphasizes the importance of making Bitcoin more accessible to non-technical users while maintaining security and privacy. The discussion also touches on the challenges of running Bitcoin nodes, the potential integration of Floresta with existing applications, and the future of Bitcoin technology.

Takeaways:

🔸Floresta aims to provide lightweight Bitcoin nodes with better trade-offs.

🔸The project is designed for non-technical users who want to run their own nodes.

🔸Privacy and security are key concerns in Bitcoin transactions.

🔸Floresta uses compact block filters to enhance user experience.

🔸The architecture of Floresta allows for easy integration with existing wallets.

🔸Proof of work fraud proof offers a new way to validate blocks.

🔸Floresta is a library that can be embedded in other applications.

🔸User experience is crucial for wider adoption of Bitcoin technology.

🔸Feedback from users is essential for improving Floresta.

🔸The project has received positive reception, indicating a demand for lightweight solutions.

Timestamps:

(00:00) – Intro

(01:04) – Who is Davidson Souza? 

(01:39) – What is Floresta?

(03:40) – Floresta tradeoff for the end user 

(08:08) – How does a Utreexo-powered Electrum server work?; Neutrino (BIP 157,158) 

(12:00) – Feasibility for mobile devices

(14:47) – Which script types does Floresta support? 

(15:50) – Who is the target audience of Floresta? 

(20:18) – Could Floresta be built into existing Bitcoin phone apps?  

(22:22) – How does Floresta work? 

(27:53) – What’s the goal of ‘Proof of Work Fraud Proof’?

(29:26) – Sponsor

(34:24) – Who are ‘honest miners’?

(36:05) – Proof of Work Fraud Proof vs. SPV vs. IBD model 

(42:50) – The relationship between Floresta and Utreexo; Rich nodes & compact state nodes

(51:12) – What will be the cost & accessibility challenges to run a Floresta node? 

(56:23) – Is Floresta compatible with Bitcoin’s Layer 2 protocols? 

(59:15) – Using Floresta in real life

(1:01:32) – Closing thoughts 

Links: 

• https://x.com/Erik17192799 
• https://github.com/vinteumorg/floresta 
• https://blog.dlsouza.lol/2023/09/28/pow-fraud-proof.html 
• https://blog.dlsouza.lol/2023/09/28/new-floresta-wire.html 

Sponsor:

• CoinKite.com (code LIVERA)

Stephan Livera links:

• Follow me on X: @stephanlivera
• Subscribe to the podcast
• Subscribe to Substack

Transcript:

Stephan Livera (00:00)
Hi everyone and 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 Utre XO, which, you know.

Listen, you might have seen that from my earlier episodes with Calvin Kim. But Davidson, welcome to the show.

Davidson (00:34)
Yeah, thanks for having me.

Stephan Livera (00:36)
So, Davidson, just give us a very quick background on yourself. I know you’re coming from Brazil and you’ve been doing some interesting stuff on Bitcoin development.

Davidson (00:45)
Yeah, I’ve been working with Bitcoin open source for three years now with a grant by BinTune. 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 side hustle, but became an actual thing. So I’ve been working on this full time basically like two years now.

Stephan Livera (01:12)
Okay, so let’s start with that. So what is Floresta and what’s the goal here?

Davidson (01:18)
Yeah, so the main goal here is to explore different trade offsets for Bitcoin clients and to provide alternatives. So with Flores, 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. You either have to expand all the resources in like actual full node with all the hardware requirements that you know you have or you completely trust someone.

The goal of Floresce 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 run or average harder.

Stephan Livera (01:59)
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 me bro involved. And then on the other end people might be running

let’s say you might be running an umbral or something similar a node box 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 Nunchuck 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 expertise even so 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?

Davidson (03:17)
⁓ So it’s extremely lightweight. So just to give you a context, ⁓ I run it on mainnet right now. It uses 300 megabytes of disk and 200-ish megabytes of RAM. So it can run on any device basically. And regarding the actual security model, you can actually choose. I don’t think the final user will choose this. We can talk about this later. But ⁓ you can actually choose

which security model is fine for you. There is the proof of work fraud proof, which we’ll also talk about in a little bit. There is the Assum.Utrexel that you can use and you can do IBD regularly. So you can actually tune it to like, I’m fine trusting the binary with Assum.Utrexel. It’s the Utrexel version of Assum.Utrexel. 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 it if you want. You can run it just with the same trade offsets as running a Bitcoin core. Like you validate everything from Genesis to 2Tip. It takes a little while, obviously, but you can do that with minimal hardware. You don’t need to have like a good SSD and all this stuff we need to have to run like a regular node because you’re not going to be using that. So you can basically do that in

like more, ⁓ more attainable others.

Stephan Livera (04:50)
Yeah, I see. And just 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 800 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 phone can have ⁓ a Client that is validating in a much, you know better way then 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.

Davidson (05:39)
Yeah, and another improvement is that when you are using like Electrum, it’s the protocol used to talk with those servers. ⁓ You are giving your wallet scripts like your addresses to those servers. Yes.

Stephan Livera (05:51)
Right, it’s like a full privacy doxing. just to be clear,

now, to be fair to the Electrum guys, the reason, it’s an OG wallet before my time, but they were from 2011 or 2012. And Thomas has explained, 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 trust Electrum servers to an extent, and of course, as you mentioned, with privacy. it…

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 times they are just using it and it’s 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 Umbrell or Ministry of Nodes Nodebox 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 electronic servers for free because that’s part of their business model to help sort of kind of connect.

Davidson (06:55)
There’s like an obvious

honeypot, right? It’s like the most obvious honeypot you can have is run a lecture infrastructure. Because people are really giving you their addresses. So yeah.

Stephan Livera (07:07)
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 want to be able to be sovereign.

Davidson (07:21)
Yeah, so with Floresta, you keep track of your balance locally. And we have something called what you only want, what you only want, wallet that keeps track of your transactions. You give it a X-Pub or a descriptor. It will keep track of 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 dox yourself to anyone else.

Stephan Livera (07:48)
Yeah. Okay. And so can you just spell out a little bit about what it is? So as you’ve mentioned, it’s a UTRIXO powered Electrum server. And so can you just talk us through what 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 Florester and that way you’re, it’s like you’re running your own Electrum server, right?

Davidson (08:15)
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 has the least amount of friction as possible. And having to install multiple binaries and configure everything. Every time I talk with people who are not technical and say like, install Bitcoin Core and then like an election server. They’re like, can’t I 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 all the validation stuff, downloads things from peer to peer, connecting with other Bitcoin Core nodes, ⁓ validates everything, keeps check of transactions and ⁓ addresses. There is the watch-only wallet ⁓ where you give your XPUB or your descriptor and it keeps track of your transactions.

and there is a election server. This is not a full index like Electra.js because those who can request like any script, any address that receives transaction 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 others that ever received Bitcoin in the whole history of Bitcoin. And that index is kind of big, it’s like a hundred gigs depending on the implementation. So it only keeps track of your own transactions.

That’s like all the, can answer. And that’s okay for like most people.

Stephan Livera (09:45)
And just to be clear, that mean

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

Davidson (10:06)
You can put it later. You just need to use something called Compact Block Filters. ⁓ We support this by default. It’s a way for you to do a scan. So try to find historical transactions in the chain. But if I need to download the whole chain because Floresta is proven by default, so you don’t keep the old blocks. But you can use Compact Block Filters to find all the transactions. ⁓ And you can use that. 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 election server. I actually proposed this to the election guys and they are changing the protocol, but this seems take time to go through. I think they’re calling it version 1.7 if I’m not mistaken. ⁓ If you replace, do you want to go to like nitty gritty here or just say that it’s possible?

Stephan Livera (11:04)
Okay, let’s yeah,

so let’s just start with that. And I guess just again, for people who aren’t familiar, this this compact block filters, I presume here, you’re talking about like, what’s known as neutrino or bit 157158. Yeah.

Davidson (11:17)
Yes, 157, 158.

Stephan Livera (11:20)
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?

Davidson (11:49)
Mobile is always hard. There is that we can talk about mobile, but it’s always hard. We try some experiments and it’s really hard. But on computer it’s fine. I think Bitcoin Core is moving to perform the wallet risk on using filters. It just builds the filters locally, but it can use it. And I think for desktop it’s completely fine. You can run like

LND, the light implementation can run it with Neutrino. Neutrino is a specific implementation of compact block filters by Lightning Labs. You can use Neutrino SPV and compact block filters. With BDK, you can use BDK with compact block filters using something called Kyoto, 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…

Stephan Livera (12:26)
Right. Yep.

Davidson (12:46)
Like the tooling is getting better, so more people are probably gonna use it. And the advantage of using with Floresa, like Floresa and Compact Block Filters is that you’re not SPV, you are actually validating. So you are a full node with Compact Block Filters. But with Compact Block Filters, you can find those old transactions on chain without needing to go through all blocks.

Stephan Livera (13:12)
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 exactly which transactions you’re interested in and therefore in that way it’s a little more privacy preserving. Is that correct?

Davidson (13:36)
Yes,

yes, ⁓ it is good for every block and it contains the, like let’s say the addresses that’s being of, your text was being created and for your text was being spent. So you, 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 address appears in this lock and the filter will tell you definitely no or maybe yes.

If it seems maybe as you download the block and you look for whatever you like your other see whether it’s in there or not. ⁓ And it also has a false positive rate. It’s like a probability that researchers say sometimes that it is and but there isn’t and that this is actually good.

Stephan Livera (14:23)
Right, 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.

Davidson (14:26)
Yes.

it’s not like the reason why the filter does that’s not for privacy. It’s like, it’s how it works. But it’s good for privacy, because you can download some blocks that are like decoy blocks, you don’t need them. So people can correlate like, look at the blocks to download and these are the blocks you are interested like, maybe I’m not interested in the block at all.

Stephan Livera (14:43)
Right.

I see, yeah.

And one other question actually, just because you mentioned scripts rather than addresses, does that mean it only works in certain like scripts types like or does it handle everything like P2SH and P2WSH as well as pay to taproot or is it only like one specific thing that it supports or only the newer stuff?

Davidson (15:05)
No, it supports any spendable script, I believe. I think it doesn’t index the upper return and things like that, but anything that is spendable, can. And like, if you were addresses, then you couldn’t, right? Because there are some scripts that don’t have addresses associated with them, like non-standard scripts. So they, if you were scripts, you couldn’t do some weird types of outputs, but I believe every single script.

Stephan Livera (15:22)
Okay.

Okay.

Davidson (15:34)
whether or not it’s standard, I think it goes into the filter.

Stephan Livera (15:37)
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 like, what should developers know? So let’s just start with the users part. Who do you see as typical users of this? Of Floresta.

Davidson (15:56)
Yeah, I usually think about like the non-technical people that are not gonna like run weird infrastructure on top of it, that I just, 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 special Bitcoin. basically general public, like people who want to have better security and privacy, but doesn’t want to like have Bitcoin Core or whatever.

Stephan Livera (16:23)
I see.

Davidson (16:25)
It’s like more research 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, like processing old blocks and work with them.

Stephan Livera (16:40)
Yeah.

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

Davidson (16:49)
Yeah, it’s a demo. It works the same way as Bitcoin D. You run your demo. We have plans to make an actual app for it, like some UI and things like that. There is work to… Because Floresce is also a library. This is another thing I put a lot of emphasis in because I don’t really think the end user is going to use Floresce directly. I think this is not the way to go. Maybe exactly because of the actrix thing.

too many things to run. So Floresce 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 same way like BDK. I have applications that use BDK that are written in Python or that are written in Java or other languages. You can do the same with Floresce. It runs 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 do things running. 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 use Floresta as they call it the chain source, which is how you communicate with the blockchain.

Stephan Livera (18:17)
Mm-hmm.

Davidson (18:17)
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 the same app and you could fetch your addresses and everything locally. the only communication you did was normal PHP communication.

It would be doxing you and what’s by doing everything locally.

Stephan Livera (18:49)
Fascinating. OK, so the way I’m understanding it then is you envision end users not really using Flores to D. 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.

Davidson (19:21)
I feel like this is like we’re still, this is probably very experimental. We have to sell the listeners to 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, but yeah, I feel like this is the best UX, right? Every time we talk with people, like you install this, then you configure this, then you install that and then.

Stephan Livera (19:36)
Yeah, right. But I guess what we’re saying is this is the goal. The goal is that developers could build this.

Davidson (19:50)
I users are like, I’m not going to do this. But if you just install this and everything will be running. They are like, okay, it’s just one thing. It’s unfortunate, but that’s usually how most people’s brains work. So I feel like this is the best UX you can deliver.

Stephan Livera (20:02)
Yeah.

Interesting and look if you if if it does get proven out then maybe Flores to gets built into existing You know Bitcoin apps, so I guess 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 blue wallet or a

these kinds of typical on-chain wallets that people already do today.

Davidson (20:37)
Yeah, it’s like 100%. 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 Electron. So you already have the Electron infrastructure. Like we have the Electron server. You just need to install Flores. Like you configure Flores, 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 Electron 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 applications just replacing their electrical infrastructure with this. And it’s very easy for them. If it was too difficult, I wouldn’t reasonably expect them to do that. But it’s so easy to do that. I don’t see why not.

Stephan Livera (21:33)
And so just to give people an idea then, it means if people were to go down this pathway of using, quote-unquote, assume UTreeXO, it means like a user could just, you know, install one of these on-chain wallets, like we said, a Blue Wallet or a Nunchuck or maybe the Blockstream app. Basically any on-chain wallet today 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.

Davidson (22:10)
Yeah, and be validating everything from the Asom.exe onwards. So like your transactions, you’re actually validating those blocks.

Stephan Livera (22:20)
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 UTRIXO 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, like what’s going on in the background here?

Davidson (22:51)
Yeah, we have a bunch of different things playing together. In Flores we have different modules that implement everything so you can poke around and only use some parts like the BDK thing, you want to use Electron and want to use the Watcherone wallet because BDK is a little wallet so they’re gonna use the node functionality. So everything is separate and we have Bitcoin Core.

compatible JSON RPC. We don’t have all the RPCs yet, but we’re trying to make them. So it’s gonna be easier for, for example, let’s say loading a 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 dropping 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 can communicate with Floresco. 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. ⁓ we’re 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 like for IBD, which is the hardest path 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 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 chip. There is a submutre XO, which is the Utrexel version of a submutre XO, where you assume that a given block is valid. So let’s say block 900,000 something is valid, like everything before is valid. And in the binary, there is the roots, like the accumulated 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 start up the block and you validate everything after. And then in Floresta, you implement the same way that Bitcoin Core does that 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 assume block 900,000. We start at block 900,000 to tip, like I think it’s 910 something like blocks now.

And another thread starts as Genesis and go all the way up to block 900,000. So you still validating, but your nodes is ready to use faster because after that,

Stephan Livera (25:54)
Right. So it’s like a

like a back sinking or how does it like what’s the word? Is it like a parallel backfill? Yeah, that makes a lot of sense. So it’s like the other 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.

Davidson (25:57)
I think they call it backfill. Yes.

Yes, and then when you arrive at block 900,000, you compare with what you had in the binary with what you obtained. And if they are not right, something’s clearly wrong. Like they are not equal, something’s clearly wrong. In Floresta, you can disable this backfilling. There is an option for disabling it. I think at Bitcoin Core, you can’t. You always have to backfill. But we have this assumed UTXO. And then you can optionally do backfill or not. If you choose not to do backfill, it’s just going to catch up with

the blockchain and you know this head. And there is this more like unexploded part with its proof of fault proof. And this is an old idea, think 2017 by Ruben Samson. But as far as I know, no one actually implemented it in like actual software, like production ready software. It allows you to skip IBD completely to a fairly recent block and you are safe, like you are following the correct chain.

as long as you’re not civil, like you’re not being eclipsed attack, which is sort of the same assumption for every node. Like if you’re eclipsed, they can make you accept least work chain.

Stephan Livera (27:23)
Gotcha.

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 like one way. Another way is assume you’re Trixo 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 their desktop or for the phone. That’s probably how they would do this. then, right. then, and so now let’s get to this proof of work fraud proof thing. can you just like, maybe let’s just start with, know, what’s the goal of that and what is that?

Davidson (28:00)
Yeah, that’s my thought.

It’s a way to add the D 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. But and if they are not 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 like, hey, this chain is actually invalid because of this, but it’s very hard to make fraud proofs because they are very dosable. So it never worked out the way Satoshi mentioned the white paper. ⁓ Proof of fraud proof is not really a fraud proof, like it’s kind of sort of, but it’s going the same direction. And 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 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.

Stephan Livera (29:39)
Okay, yeah. And so the idea is you can quickly get up and running. as I, you know, just from trying to read it a little 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 few blocks might be like 100 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 chain? ⁓

Davidson (30:10)
Yes, you basically assume that some percent of the hash hates is honest. It can be as small like 10%. So you would need more than 90 % of the network hash hate to attack this. ⁓ But as long as some hash hate 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 the same height.

So what you do is you look for those and then you try to tune this for not get ⁓ any block you can find because otherwise it could be dusted as well. ⁓ But if a reasonable amount of work, you look at it and you download the main chain block and rewind your state, basically validate that block as any other node would and you figure that the block is invalid. So you now know that block is invalid, you just invalidate that whole chain and go through the other chain.

So because those miners are very fairly guaranteed to find a block in the last, like say, 200 blocks, there should be at least one block for this minority. You can be very sure that if there is none, there is no fork, then either there is 100 % collusion for the hash rate or that those blocks are valid.

Stephan Livera (31:32)
see and 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 a hundred blocks this doing this right

Davidson (31:47)
Yes, everything is done

with the header chain. You look at the headers, you sum up the work using headers, and ⁓ you see 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 could find. You take the version…

for the main chain, validate it, and if it’s invalid, you invalidate that chain and go to the other chain. And you continue doing this, it’ll actually eventually only have one chain.

Stephan Livera (32:28)
Yeah, interesting. And so then the idea that Ruben is putting out here that he put out is this idea that you can raise the threshold for somebody to attack you from being 50 % plus one to maybe it needs to be like 90 % of the miners are trying to trick you, which I mean, even that is already a pretty like crazy sort of imagine if 90 % of the network was already malicious, then, you know, it’s kind of already like this, you kind of already you’ve got other bigger problems at that point, right?

Davidson (32:52)
Yeah, it’s kind of bad.

Yeah, it’s kind of bad if 90 % of the hash is, we can make it like close to 100, 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 are not found exactly like you, if you have 50 % of the hash, you’re gonna find 50 % of the blocks that like upwards out over time. But if you start checking smaller, like smaller,

Stephan Livera (33:15)
You’re

Davidson (33:25)
percentages or smaller intervals, then the statistics don’t play out here because you have traveled out of other bigger intervals. But you can make it over 90%. You can just make a ridiculous number. At some point, just solo miners will be able to find a fork and basically get the majority shape, show that the majority is wrong.

Stephan Livera (33:42)
Yeah.

Yeah. And just to be clear here, what are

we defining here as honest minors? Can you just explain that for listeners?

Davidson (33:55)
It’s the same definition of 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, like a charitable person. Yeah, no morality. Honest, in the context of Pec-Coin-Fur nodes means someone that’s following the consensus rules.

Stephan Livera (34:04)
Yeah, not a morality test, let’s say. ⁓

Yeah, that’s, guess, kind of broadly speaking, yes, 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.

Davidson (34:37)
And the white papers

say longest, but longest is insecure.

Stephan Livera (34:39)
Yeah, because longest

could actually be not the heaviest chain. And that’s where this kind of heaviest chain concept came, as I understand anyway.

Davidson (34:43)
Yes, because 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 less work. So, yeah.

Stephan Livera (34:50)
Right.

Gotcha, anyway, let’s just say that’s kind of a

technical point that basically all the Bitcoin developer, like hardcore Bitcoin developers already know that part, so we’ll leave that. So just coming back to comparing the models, all right? So as you’ve explained, is the, 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, 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 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 elaborate a little on the difference between those three.

Davidson (35:50)
it’s all about being more sovereign about what you’re doing because with proof of all fraud proof you also start, you can also know what’s the state of the network for the block that 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 should 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 it’s like a block six years ago was invalid. Like, what are 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 security, like the…

You always, when you talk about security, you always talking about how hard it is for someone to attack you. You can’t be a hundred percent safe. Even a full load on 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 the trust the server because well, it’s just the server. The server lies to you. You can’t make, yeah, you’re done.

Stephan Livera (37:12)
And you’re done, right? Because they can tell you

you received coins, but actually you didn’t. your client’s app at that point has no way to tell the truth or not. ⁓

Davidson (37:17)
Yes.

Yeah, sometimes people don’t realize that they can just lie by omission, for example. They can just not tell you about a spending transaction for your lightning channel that spends the channel in your old state. So by just saying like, don’t know any transaction related to this UTech. So they are messing up with you, because you have to know that the channel point was spent.

but because they didn’t tell you. Yeah, just by like not giving information, it’s not that they craft information, it’s just by not giving you information. It’s lying by, we call it blind by omission. Yeah, just by not telling you something, they can mess up with you. So it’s like in terms of.

Stephan Livera (37:54)
Right, it’s especially important in the L2 context, yeah.

Lying by a mission,

Yeah. Gotcha. And so that’s the trust.

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 51 % mining ⁓ part of it, and you’re not checking every rule.

Davidson (38:35)
Yeah, and ⁓ with SPV, which is just assume that the chain with more work is the valid chain, it’s like it is valid, it follows the consensus rules because there is this idea that we assume that the most proof of work, like the most amount of workers, are honest, following the honest definition from before. So if the most amount of work is in this chain, this chain must be valid because they are all following the consensus rules.

And the way to attack you to fully accept an invalid transaction, for example, would be to have a 51 % of the hash rate and ⁓ 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 you’re not gonna respond to it. then one person using it,

Nowadays it’s very hard to get 51 % on Bitcoin. It’s so big now that it’s hard for just one… The amount of hardware and electricity you need to get to 51 % seems out of reach for one person, one entity. Only if Polos do some weird coalition that they maybe can get this big. But nowadays I think it’s not really that… I don’t know. I’m not looking at a lot of it, but it looks like…

It’s hard nowadays to get 50 % 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. No one’s checking anyway. So they just join together, like create UTXO with 21 million bitcoins for them and no one’s checking. So no one’s going to do anything about it. So the main problem here is one of like a philosophical problem. This is

something that was debatting and exalting during the block size wars because if everyone or like the majority of the network of the economic, like the economic majority is using SPV, they are leaving, miners are leaving incentivize to do this because no one is gonna oppose them. Right now we assume that because people are checking, like the majority of 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. And if no one is validating, then that means they don’t get punished and they can pass with changing like invalid block. ⁓

Stephan Livera (41:13)
Gotcha, okay, yeah.

Okay, yeah, cool. yeah, I guess 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 is not gonna do the full like IBD and download everything. And it couldn’t, guess, yeah.

the idea can maybe be to help people get started quickly and ideally still backfill so that they are then fully validating.

Davidson (41:47)
Yeah, and it’s important to

remember that this is a, you should not compare this to an actual node. You should compare this to like SPV or decline because sometimes people say, this is worse than running a node. like running a node is the best thing you can do. it’s the gold standard for doing Bitcoin stuff is running a node. But ⁓ nowadays most people are doing the SPV or trust the server set up. So we’re improving that.

This is usually what we need to compare with when I talk about proof-of-proof-fraud proofs.

Stephan Livera (42:19)
Yeah, gotcha. Okay, so let’s talk a little bit about the relationship between Floresta and UTreeXO. So as I understand, you have libflorestaD, right? It’s a library, Floresta. And then Calvin and the UTreeXO guys have UTreeXOD. So as I understand, can you just explain a bit about that relationship there?

Davidson (42:40)
Yeah, are like, UTXO is like a spec. It’s more of like an idea with the beeps 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 leads. ⁓ One that Calvin work with, it’s called UTXO, it’s written in gold. And I wrote the one in Rust, it’s called RustTXO.

As far as I know, there is a partial implementation for Stack Web, but full functionality, these are the only two implementations of UTrixO I know of. so this is the actual UTrixO stuff. And then there is the implementation of Bitcoin nodes that use UTrixO to make the node functionality. So you have UTrixO plus like B2B, block storage and all that. And the way we usually discuss this is,

HrexOD is more like if you want to do something more like a light weight replacement to ⁓ BTCD or Bitcoin Core, it keeps more stuff, it has more functionalities because it’s like a fork of BTCD. So you can do basically anything that BTCD can. So you may not prune, you can keep old blocks if you want. So it has more features, 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 UTXAD needs 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 going to complain about this. And also it’s like, we don’t keep most of the information that

Bitcoin Core does, we don’t keep revision data, don’t keep blocks, we don’t keep a ton of stuff, we just remove and remove a lot of functionalize because we just want to be a super lightweight client. Our goal is to make something very lightweight and embeddable, easily embeddable into other applications so people can view those things we’ve talked about few minutes ago.

Stephan Livera (45:04)
Understood. it’s,

we could say Floressta is for a more specific purpose and it’s designed to be embedded into, could be lower powered devices, whereas UTRIXO and UTRIXOD are sort of a broader idea that you are, like Floressta is relying on, but it’s a, I guess it’s a different piece of software. It’s the key point to understand.

Davidson (45:26)
Yeah, UTXO

is the idea. UTXOD is just an implementation, right? It’s a fork of BTCD. 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 and like an idealized thing. And Bitcoin Core is implementation of that. UTXO has two implementations, which is like two clients that use UTXO. Yeah, the Go client, yes.

Stephan Livera (45:31)
Yeah.

Right, the Rust one and the Go client. Now, I guess one other point

I’m curious just if you could explain this. My understanding from UTUXO 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 the mobile client who’s just downloading the proofs. So is Floressta helping people be a compact state node?

Davidson (46:05)
Yes.

Stephan Livera (46:15)
and then downloading proofs from the UTreeXO bridge nodes. Have I got it right there?

Davidson (46:21)
So this part is a bit annoying because there is actually two terms because you can we talk about there is historical blocks and there is the UTXO set. Those are two different things and UTXO we actually separate these into like two terms and you have like different combinations. If you have the accumulator, the accumulator is like a big file that you need to keep to generate those tools. So let’s say you want to prove that any UTXO is in the UTXO set.

Stephan Livera (46:32)
Okay. Yeah.

Davidson (46:51)
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 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, like super tiny. ⁓ If you have the ability to generate proofs, you are a bridge. This is what means to be a bridge. You have the forest, you have the whole thing, like 20 something gigs.

of a file, it uses a lot of IOS, you need to have a better computer to run this, but you’re a bridge. ⁓ We need bridge 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 transaction blocks. ⁓ If you don’t keep this, you are a CSN, a compact safe node. Floresa is a CSN, it can’t operate as a bridge, it’s one of the things like.

where you make a trade off from UTXOD can operate as a bridge and Floresta would not want this because they don’t think the users of Floresta will be running a bridge. It’s not the purpose. Yeah, if you want to run a bridge, run UTXOD. ⁓ Then there is the archival, correct the use 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.

Stephan Livera (47:55)
Right, because it’s not the purpose of the project, yeah. Gotcha.

Davidson (48:17)
in fact, in the UTREX website. And so if you have all the out walks and all proofs, specific all proofs, you are an archived though. So you can be like a UTREX or like a CSN archive, it can be a pruned bridge, you can be like a pruned CSN, you can be an archived CSN. So there’s four possibilities depending on whether or not, yeah.

Stephan Livera (48:41)
Okay, yeah, yeah, so it’s a bit more complicated, okay

Davidson (48:45)
So you can ⁓ actually run, I think there is some that doesn’t, but ideally you can run all of them. So let’s say I have a vfm machine with a good SSD, but I don’t have all the storage to store all the proofs. So you can be pruned, bridged. I don’t have a good SSD, so I don’t want to generate the proofs, but I want to serve the proofs through other nodes. Then you are ⁓ archive CSN. So there’s like variations, it gets a bit messy, but.

Stephan Livera (48:50)
Okay.

Gotcha,

okay, right, right. So yeah, and then the bridge concept, as I understand, the idea that the person who’s running that bridge node, that person is like a professional or let’s say, you know, 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.

Davidson (49:39)
Yeah,

we have this idea that bridge nodes are going to be rare and most people run archives. So you cannot generate proofs, but you can serve proofs for blocks. So blocks that are rare.

Stephan Livera (49:51)
Yeah, and I guess just to be

clear here, the cool thing here is that you while the the compact state nodes might be calling out to the bridge nodes, there’s that it’s a proof, right? So they’re not trusting. It’s they’re able to actually, you know, know, right?

Davidson (50:07)
They are checking everything. If the bridge

node is lying and technically they connect with an archive node, right? They don’t know they are connecting with a bridge. Because you just need someone that, yeah, 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 CSN network and the archive CSNs will keep those proofs around.

Stephan Livera (50:17)
see, right. Yeah.

Davidson (50:38)
So you just need to connect to those archive’s SNs and they can salvage the proof. You just need one person to prove it.

Stephan Livera (50:43)
Okay.

Yeah, interesting. So yeah, that’s kind of a deeper concept. Okay, well, I think we’ll cut that particular thread. Let’s go now to the node costs aspect, because this is a common 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 is probably okay, but in practice you would probably want like a two terabyte SSD for like, if you’re doing a full node, because you wanna be able to, 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 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, imagine a future where these get used more.

What does that mean? Like as the chain grows, does that mean, you know, we might see more interest in this kind of technology?

Davidson (51:43)
Yeah, especially the UTXO set going up. Now it’s going down, but it went up a lot and it made it really hard for some people to run nodes. know I 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, took like two months, so I just gave up. One thing that I usually…

I need to talk down, I see a lot of people, especially in the US say, oh, it’s just $300. Have to remember that not everyone lives in the United States. And $300 is the, I think $350 is the average household income per person in Brazil. So every month, that’s what you have to do, 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 the computer because otherwise you just have like a tablet or smartphone. So sometimes people just want, I know a guy that he wanted to make a note, 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 note. So

I see a lot of people who say, I want to run a node, like run it by a separate computer and making sure it’s running 24 seven because if it goes down, you all can 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 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 Flores are people who are residential network. They can’t accept incoming connections anyway. So they.

I’m gonna help with this. to summarize, there are several challenges in people acquiring your hardware and growing nodes the way we say that would be the ideal. And the main evidence for 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 are not running notes the way we want them to.

Stephan Livera (54:39)
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. Yeah, because I don’t I don’t even think the dollar cost of having like, okay

Davidson (54:53)
Yeah, it’s a hassle.

Stephan Livera (55:00)
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 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 are not because I think it’s for other reasons than just the straight costs of doing so. But I’m curious what do you make of that? Do you think it’s an ease of use thing?

Davidson (55:31)
Yeah, probably there is a component of use. A lot of people are like, too much things to run, configure a lot of stuff. Even with loading a box, you still need to do some things. You need to install ⁓ OS on something. So they’re like, not going to do it. So this is why I really try to make the package thing. Let’s make everything one app, or at least the least amount of apps possible, and require the least amount of configuration possible, so more people will do that.

Stephan Livera (56:00)
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 else for that or is it more like, yeah, you still can do lightning with Floresta?

Davidson (56:22)
Most of the stuff that most of the layer choose, the only problem is when they need to request like arbitrary UTXOs. Like lightning any channel, every channel has a associated UTXO, they call the channel out point. And when you try to get these arbitrary UTXOs that are not cached by the wallet because they just ran on UTXOs, it gets messy. We can’t right now find those UTXOs because we don’t have the UTXO set.

Right? The crank working, just look through the UTXO set and find that UTXO. We don’t have that. So ⁓ that part’s hard. I had some talks, one in Berlin last year, bit C++. Maybe we can do this in an easier way if… So most Lightning mobile clients are using LSP, 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 otherwise, because you can have just parts of the forest. So otherwise it’s fine. You don’t need all the resource that you would need for a normal bridge node. And if they can generate the proofs for those UTXOs, then it could play nicely. Like it would work very nicely. You could validate those. You would need to trust third-party servers. For everything else, like

getting blocks, ⁓ getting your own transactions, everything else that works out of the box. The only challenge is finding how you UTXOs.

Stephan Livera (58:00)
I see. So I guess for now you would not recommend somebody run a lightning node off a floresta. But I guess even if it just helps people do their on-chain stuff, that’s already a pretty big win.

Davidson (58:06)
No.

There is another way to

do this that will need some minor change in the lighting clients, which is how Neutrino does that using CompactLog filters. It also works, but especially if you want to go the mobile route, it’s kind of annoying. I’ve been told by some people who does that in mobile lighting that the experience can get very ugly there, especially if you are on a slow network, like a

⁓ worse network, the experience gets really bad. So there is this way it works, but like UX wise, it’s not ideal. The other way would be more ideal UX wise.

Stephan Livera (58:46)
Yeah.

Gotcha, yeah.

Okay, so 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 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 let’s imagine they’re using some kind of flouresta 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? in this context, like if you’re talking about like a server that has to re-sync up to the chain tip, that’s one thing, but how does it work in Floresta in an assume UTreeXO context? Is it just kind of re-downloading the latest, like can you just explain a bit about that?

Davidson (59:54)
Yeah, for SymmetriXO, if you go offline and come back, you need to re-dolo everything. For Proof-of-Fraud proof, you can just redo Proof-of-Fraud proofs. So if you, let’s say you have three months worth of blocks that you have to catch up, it’s a lot of blocks, probably you don’t wanna do this on your phone, so you can redo the Proof-of-Fraud proof routine and just skip to the latest blocks. So, my SymmetriXO, no, it’s…

It’s a problem with asymmetry XO 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. For us, the last release is very old. So right now I have to catch up like a few thousand blocks. So it takes a little time now.

Stephan Livera (1:00:42)
even to run the proof of work fraud proof thing.

Davidson (1:00:46)
No, running the SMU trick will always get you to a very recent block.

Stephan Livera (1:00:52)
Gotcha, okay. And so I’m curious, do you think that would be a competitive UX, like given 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?

Davidson (1:01:10)
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 will be some degradation There is no way you can make it compete with a server

Stephan Livera (1:01:21)
Okay.

Yeah, gotcha. Okay, 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 server or various servers. So can you just, I guess, things up and yeah, any closing thoughts there?

Davidson (1:01:51)
I, as I say, 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 in 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 or trusting kind of thing, it’s going to be bad. We’ve seen in altcoins.

things like a whole country being shut down from the infrastructure of a major service provider. This is not the kind of thing we want in Bitcoin. So I think there is space for some experimentation there. And yeah, I think there is people that is going to benefit from this. if you’re like, anyone has any thoughts, especially on the UX side, because there’s a lot of challenges there, we are always open to like feedbacks and thoughts from.

different people, even if you think like, that’s impossible, that’s not worth. It’s always good to hear new opinions. So there’s the GitHub and we have a Discord as well. So I’m always looking for feedback. So far the reception of the product has been very good, very positive. And 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.

Stephan Livera (1:03:11)
Hahaha.

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 see it’s github.com slash vintium org slash floresta to find the github and I will link to obviously your ex 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. ⁓ And yeah, Davidson, thank you for joining me today.

Davidson (1:03:44)
Thanks for having me.