HI Bastiaan van den Berg, thanks for your reply.

>the utreexo bridge peers are the only real bitcoin nodes

I think this is not correct. Floresta is a Compact State Node (CSN), it keeps 
only the bare minimum to validate blocks and transactions, but it still 
performs everything a bridge or a regular node does. The difference being in 
the storage and I/O requirements. In fact, CSNs are the reason utreexo is 
relevant. In a bridge node, you need more​​ resources than a regular node. As 
stated in the post, I'm using Core's set of shared libs to implement the 
consensus parts, and we validate the chain from genesis as usual.

>you cant use -only- libfloresta to be a node

You can, bridge nodes are just peers that can prove things. You could, in 
theory, eliminate them. But this is a long-term thing. In fact, I have built 
Floresta, a drop-in replacement to a node + EPS. You just spin it up and after 
IBD, an electrum server is provided to connect your wallets.

>you cant mine with it

Technically, you can, you just have to build a block dispatcher. But I think 
this is out-of-scope for what I'm looking at. My main target is end-users, that 
don't want or can't use a node because of the elevated hardware requirements, 
even for pruned ones.

>you cant do normal tx with it

Yes, you can't build the tx, but the goal is not doing this. The goal is 
integrating the node and (if needed) the watch-only wallet in a wallet that 
implements this procedures. So imagine a BDK-based wallet with libfloresta as 
the chain backend, LDK makes the UTXO management and tx build/sign, libfloresta 
broadcasts with the p2p network, no ttp involved.
I'm using Floresta as my Electrum server for Electrum and Sparrow, for testing 
some things on signet, and works just fine!

>you are targetting webbrowsers (???? , i'm really confused about the why of 
>this)

I think I could have made the explanation more clear. The goal is creating a 
fully validating node with a small footprint, such that, using things like 
assume-utxo or zero-sync, even browsers and smartphones can run an actual 
node.​​ Browsers are just one possible target, even big computers would benefit 
from a low-footprint node.

Hope this helps to clarify what this project is. If you have more questions, 
please let me know.
________________________________
De: bitcoin-dev <bitcoin-dev-boun...@lists.linuxfoundation.org> em nome de 
Bastiaan van den Berg via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Enviado: terça-feira, 1 de agosto de 2023 05:32
Para: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Assunto: Re: [bitcoin-dev] Announcing Libforesta

Am i correct in the following interpretations?

- the utreexo bridge peers are the only real bitcoin nodes
- you cant use -only- libfloresta to be a node , you cant mine with it, you 
cant do normal tx with it
- you are targetting webbrowsers (???? , i'm really confused about the why of 
this)

On Mon, Jul 31, 2023 at 9:11 PM Davidson Souza via bitcoin-dev 
<bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@lists.linuxfoundation.org>>
 wrote:

Hi, list. My name is Davidson, and I’m thrilled to share `libfloresta` with the 
Bitcoin devs mailing list!

This is a derivate of a project I’ve been developing for a few months, called 
`Floresta` (Portuguese for forest). An Utreexo powered, Fully-Validating 
Bitcoin Full node with integrated watch-only wallet and Electrum Server, meant 
to be a compact, simple, and ready to use full node for end users.

After some feedbacks and thoughts, I’ve decided to turn it into a series of 
reusable libs that can be used in other applications in a straightforward way. 
The main goal here is low-power devices, like SBC and smartphones, but can be 
used in any environment. To achieve that, I’m writing the main logic in Rust 
and will generate bindings to the original code and compiling to WASM, allowing 
it to run virtually anywhere.


The project is in an early stage, but I’m using it on signet for a while now 
with no problems. Mainnet support is almost ready, but we need to solve some 
performance issues with bridge nodes and set some up, so you can have utreexo 
peers.


The project is available on [my 
GitHub](https://github.com/Davidson-Souza/Floresta) and I wrote an initial 
[blogpost](https://blog.dlsouza.lol/2023/07/07/libfloresta.html) explaining how 
to use it (in Rust). I’ll write more as the project matures, and I get it 
running on other platforms. Any feedback is welcome!


## Consensus


I know that alternative implementations is a spicy subject in Bitcoin land, but 
this project **does not** reimplement the Bitcoin Consensus machine from 
scratch. I’m using `libbitcoinconsenus` and plan to use the full 
`libbitcoinkernel` in the future. While this doesn’t guarantee consistency, it 
minimizes misimplementations leading to splits.


I’m also making an extra effort into cross-test against Bitcoin Core to find 
any inconsistencies before it causes any trouble.


## Acknowledges


A special thanks to [Vinteum](https://vinteum.org/) for supporting my work with 
utreexo and Floresta.

Best regards,
Davidson Souza.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@lists.linuxfoundation.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Reply via email to