Mandacaru: A new Electrum server?

[TheButterZone]

https://github.com/jvsena42/mandacaru/

A lightweight Bitcoin validator node for Android, powered by Utreexo and Floresta.

Run a full Bitcoin node directly on your phone with minimal storage requirements thanks to Utreexo's compact accumulator design.

Saw it posted at https://x.com/bhbitdevs/status/2040815816950579233

Just submitted to https://walletscrutiny.com/asset/?sha256=4dd91c068c351e0de70a1cd0f414568e076db22ad8f2f0ab7afd28a3417b31b1

[nc50lc]

Do they have an official documentation other than links to "Utreexo" and "Floresta"?

Based from my initial review; it's more of a full node without a wallet (but can be loaded with desc)
with an integrated Electrum server to connect to the user's Electrum client that'll serve as the wallet.

And based from the "Powered by" links, it seems to be limited to pruned blockchain which is a huge limitation for an Electrum server.
But it'll work as a personal Electrum server.

[TheButterZone]

IDK, I'm about as far from an expert as you can get so that's why I wanted more eyes on discussing this... my understanding with pruned nodes was that it downloads everything, then prunes it down.

Let's say you create a new Electrum wallet & connect it to your Mandacaru node, on the Mandacaru side can you mark your client connection as "don't look back, it's new" then does your node take note of the Bloom filter but ultimately only accumulate UTXOs from peers that fit your filter after it connected? The peers see that your node is downloading all new UTXOs but they don't see that your node is insta-pruning them if they aren't relevant to your wallet addresses?

But if you're having the Mandacaru node filter for your imported Electrum wallet that was already filled with UTXOs, it has to process the whole UTXO set to find them all but also do it in stages so it doesn't have more than however little MB stored at a time vs gigabytes?

I'm reminded of https://walletscrutiny.com/android/de.schildbach.wallet/ which was all-in-one node & wallet, but I only watched it run & poked around changing settings without actually receiving to/spending from its wallet.

[nc50lc]

I'm reminded of https://walletscrutiny.com/android/de.schildbach.wallet/ which was all-in-one node & wallet, but I only watched it run & poked around changing settings without actually receiving to/spending from its wallet.

It's certainly similar, Mandacaru uses the improved version of that schildbach wallet's bloom filters which is "compact block filters".
I can't compare the two in detail yet though, since I've just stared reading Floresta's documentation.
(if you're interested to read, link: getfloresta.github.io/floresta-docs)

And I'm not even certain that Mandacaru completely follows its implementation since I'm not familiar with its language (Kotlin).
That's why I've asked for any specific documentation for Mandacaru.

Lastly, it's good that I found that library's docs since it contains a disclaimer for being "highly experimental".
We wouldn't want users to fully rely on Mandacaru where the library that it uses isn't even production-ready yet.
Ref:

⚠️ Keep in mind that Floresta is still highly experimental. We do not recommend using it for transactions involving meaningful amounts of satoshis.

[TheButterZone]

Let's say you create a new Electrum wallet & connect it to your Mandacaru node, on the Mandacaru side can you mark your client connection as "don't look back, it's new" then does your node take note of the Bloom filter but ultimately only accumulate UTXOs from peers that fit your filter after it connected? The peers see that your node is downloading all new UTXOs but they don't see that your node is insta-pruning them if they aren't relevant to your wallet addresses?

Indeed!

Pick your wallet's birthday year in Settings so the node only downloads BIP-158 filters from that point forward.

Wallet birthday year picker (in Settings) — choose the year your wallet activity starts, and the node only downloads compact filters from that point forward.
Initial storage drops from ~13 GB to under 2 GB — by skipping irrelevant historical filters, the on-device data footprint is roughly an order of magnitude smaller out of the box.
Changing the birthday automatically re-syncs the wallet, so transactions appear without manually re-loading the descriptor.

[nc50lc]

Let's say you create a new Electrum wallet & connect it to your Mandacaru node, on the Mandacaru side can you mark your client connection as "don't look back, it's new" then does your node take note of the Bloom filter but ultimately only accumulate UTXOs from peers that fit your filter after it connected? The peers see that your node is downloading all new UTXOs but they don't see that your node is insta-pruning them if they aren't relevant to your wallet addresses?

Indeed!

Pick your wallet's birthday year in Settings so the node only downloads BIP-158 filters from that point forward.

That's from yesterday's update, right?
It seems like they've just added a "birthday" feature to further decrease its resource requirement but "Compact Block Filters", BIP-158 is already being utilized even before that version.
This reminds me of light Monero clients.

Nice update BTW.

[TheButterZone]

My CanaKit RPi3B+ came with a SDC10G2/32GB Kingston microSDHC which is Class 10 but not A1?

Seems like it's not recommended to install Emteria Android on it, then?

Ultimately want to run Mandacaru on the Pi instead of on a mobile device which LOVES routing data through the mobile network for $$$ instead of the perfectly fine home WiFi 3 feet away...

[TheButterZone]

Alright, so I've updated through a few versions & it's up to v0.10.0 now.

https://github.com/jvsena42/mandacaru/issues/3 desperately needs resolution, it's been over a year... IBD & all intensive data needs a setting that forces them to WiFi & only allows mobile data failover for new blocks & light data. Had to disable mobile data in system settings once I realized that Mandacaru wasn't using my WiFi 3 feet away. Some Android apps include a network setting for WiFi-only, mobile-only, or both (WiFi if you're home/unmetered, mobile as failover, theoretically yet in practice...?!), but Mandacaru's would need to be more complex than general failover if we want to be absolutely certain the app will hold the intensive data phases for WiFi.

The other issues I've had with it on a phone (which I put the card CanaKit included into, so now my RPi can't run concurrently unless I buy another card): https://github.com/jvsena42/mandacaru/issues?q=is%3Aissue%20author%3Athebutterzone

I hope in the near future https://github.com/jvsena42/mandacaru/issues/57 will be resolved so it's not just bound to localhost & Electrum desktop can connect to the Mandacaru phone/tablet/whatever Android device as well. Then, I would want to card the RPi again & see if I could Android+Mandacaru the RPi to at least be my LAN Electrum server without also having to install Electrum Android on it & run another monitor, monitor switcher, or remote into it to use the client. I didn't realize it was only localhost-bound until I got in too deep LOL

At this point, IMO it needs 2 major & 2 minor things to bare minimum work well with Electrum Android (presuming a fresh install of it, importing the pubkeys from Electrum desktop):

Major:
Only report 100% sync when 100% of the TXIDs have filtered in, with no need for the user to RPC-command multiple rescans over hours, days? because some transactions from the birthday year to well-before Mandacaru's IBD started, are missing.

QR scanner in the app

Minor:
De-duplication of wallet descriptors, so you can have a long list of unique descriptors instead of uniques mixed with duplicates
jaoleal pointed me to https://github.com/getfloresta/Floresta/pull/821

Have the error/notification box display on top of everything, instead of the box's sides peeking out from below a slightly skinnier opaque layer

And about this...

Initial storage drops from ~13 GB to under 2 GB — by skipping irrelevant historical filters, the on-device data footprint is roughly an order of magnitude smaller out of the box.

11.26 GB total storage is used by Mandacaru v0.10.0, having run my current IBD, with 75 total transactions running from birthday year 2017->2025

So getting it to under 2 GB appears aspirational, not achieved yet? https://github.com/jvsena42/mandacaru/issues/53