getfloresta/Floresta

Florestad::get_config_file() reads and re-parses the config file from disk on every call, with no caching or snapshot. During a single node boot, setup_wallet() triggers three independent reads of the same file. It is called once by each of the three setup helpers, all invoked in sequence inside setup_wallet(): get_descriptors() → disk read #1 get_xpubs() → disk read #2 get_addresses() → disk read #3 setup_wallet() runs once near the top of start(), so config.toml is opened, read and parsed three times per boot. The file is tiny, so this is not a performance concern but it's a correctness/clarity smell. Also because the three reads are independent, they are not guaranteed to observe the same file contents. In the window between reads, get_descriptors, get_xpubs and get_addresses can see different data. The window is small but real and it can produce a wallet configured from a mix of old and new file states. Also what caught my attention to this issue was the duplicated (in this

Describe the enhancement Besides the node, we have extra components that expose interfaces for data fetching, them being the rpc server, the electrum server and the zmq interface. All of them occupies an address space, a new exposed interface and cannot be deactivated without recompiling a new binary. If we could disable them via boot flags, vulnerabilities could be mitigated by users without requiring a new binary. Its also useful for use-cases that dont require them and recompiling a new binary without them isn't ideal. The disable mechanism already exists we just need to work on the flags

Summary The addnode JSON-RPC command (add / remove / onetry) always returns null (success) regardless of whether the underlying peer operation actually succeeded. The node internally knows whether the operation worked (a bool result), but the RPC handler discards it. Location crates/floresta-node/src/json_rpc/network.rs, add_node (lines 57–74) — the bug Contrast with the correct pattern in the same file: disconnect_node (lines 109–117) Root cause plumbing: crates/floresta-wire/src/p2p_wire/node/user_req.rs (lines 99–140), crates/floresta-wire/src/p2p_wire/node_handle.rs (lines 254–286) Details add_peer, remove_peer, and onetry_peer all return Result<bool, RecvError>, where the bool indicates whether the node manager actually performed the requested operation (e.g. false if the peer was already added, already removed, or the connection attempt failed). The RPC handler throws this away: // crates/floresta-node/src/json_rpc/network.rs:57-74 pub(crate) async fn add_node( &s

Suggestions first seen in: #1006 (comment) Deny when cast risks to lose data cast_possible_truncation = "deny" Deny when casts risks to change signal cast_possible_wrap = "deny" cast_sign_loss = "deny" crates: floresta-electrum #1021 floresta-chain floresta-rpc floresta-mempool floresta floresta-wire floresta-common floresta-watch-only floresta-compact-filters

Describe the enhancement Add comprehensive documentation for all RPC endpoints used in CLI. Currently, these endpoints lack proper documentation, and we need to create individual documentation files for each RPC method following the established template. Use case Proper documentation for RPC endpoints will: Help developers understand how to use each endpoint correctly Provide clear examples and expected responses for integration testing Ensure consistency across all RPC method documentation Serve as reference material for users integrating with Floresta All documentation should follow the template available at: here The documentation should be added to floresta-cli and cover the following RPC endpoints: GetBlockchainInfo - #806 GetBlockHash - #806 GetTxOutProof #1113 GetTransaction #985 SendRawTransaction - #838 GetBlockHeader GetRoots GetPeerInfo GetTxOut Stop FindTxOut - #1247 GetMemoryInfo GetRpcInfo Uptime ListDescriptors Ping Additional context This can be d