To keep the discussion focused, here are a few assumptions I'm working under when evaluating the feasibility of running a node on a phone. While these assumptions may not be 100% accurate, they are meant to be true for a majority of the discussion.
Given we are fast approaching 1TB for all Bitcoin related data, I don't expect users to be running a phone with 1TB of storage. In the event they have access and can afford a phone with these resources, the recommended setup should instead be one of the platforms we already support, e.g., minipc or SBC running linux.
For an end user of Bitcoin who wants to run on Android, I assume they are also running a wallet either on the same device or networked as a data provider to another device (phone wallet, lightning wallet, electrum server, etc). While other use cases for running a node without a wallet may exist, I'd argue they are niche enough to ignore for this discussion.
While android can run on a variety of hardware, it seems primarily for smartphones and tablets, which we can bucket as having similar resource restraints (connectivity, battery, CPU, RAM, storage, etc). For bespoke hardware setups that are not a mobile environment, e.g., SBC's, I'd imagine most of these can also run linux.
One of the arguments for supporting Android as a build target is that many people only have access to an Android smartphone/tablet as a personal computer. For this user, I think we should also assume they do not also have access to desktop computer. Furthermore, I think we should be skeptical as to what sort of internet they have access to, meaning we cannot assume they have a dedicated home WiFi and are instead using a mix of public internet or metered cell connections. As an example, many phone users use "data free" connections around the world, where a provider is reverse billed for the data costs for certain apps, e.g., Facebook, WhatsApp. This raises questions of how feasible it is for a user to pay for the bandwidth to fully validate the blockchain + pay for the electricity and bandwidth of keeping the node always on and synced to tip.
When thinking of what a user needs in order to be fully validating, doing IBD on a mobile phone seems less interesting to me vs keeping up with the chaintip. Because Bitcoin Core uses assumevalid for the majority of historical blocks, I suspect the majority of the time spent is in validating the last few months of blocks, where assumevalid is not used. This means if the user does not keep the phone on at all times, it will likely not be able to keep up new blocks since every block after IBD is fully validated (scripts + signature checks).
This means a phone user will likely need to keep the phone at home, plugged in, and on a dedicated internet connection in order for this to be a useable node.
AssumeUTXO is one way in which a user can sync to chaintip from a snapshot , while fully validating genesis to snapshot height. This could help make the wallet more usable for the user right away, but does not address the issue of a mobile device keeping up. IIUC, assumeUTXO also does full validation without assumevalid during its background sync (although this may have changed, or could be changed). I'm not sure a mobile phone would be able to keep up with the chaintip while also fully validating from genesis, under the assumeUTXO model.
Furthermore, if an Android user only has access to a phone, this presents some challenges in my mind as to how the user is sourcing the AssumeUTXO snapshot and getting it on the phone.
For lower end phones (e.g., cheaper than a minipc/SBC setup), are the storage drives well suited for Bitcoin Core? Specifically, for phones with low RAM. The UTXO set is close to or at this point greater than 16GB, which means a node frequently needs to flush to disk / randomly read from disk in order to connect a new block to the chaintip. This historically has created problems for raspi's with older spinning disks/SD cards, as the node quickly chews through the storage and corrupts it. Are there any concerns here of bricking a users phone after a year or so of running Bitcoin Core. This is more a question from my side as I am largely unfamiliar with storage mediums of phones smartphones that would be cheaper than a SBC/minipc setup.
In running Bitcoin Core on a phone, I suspect many issues users will encounter will not be with the GUI App but more with the node itself, e.g., node not keeping up, phone storage getting corrupted, IBD stalled, and other specifics that might arise from running on a variety of hardware that we don't currently test for or build for in the project. These requests for support would necessarily be upstreamed to the Bitcoin Core project, increasing the maintaince and administrative burden. Troubleshooting/reproducing/proposing fixes would also need to come from the upstream project, which is why I remain skeptical that the maintaince burden involved is simply getting Bitcoin Core to cross compile for an additional architecture and is instead much, much more. Said differently, almost every other platform we currently support assumes a certain type of user and maintaining a release for a Mobile OS user introduces a whole new set of assumptions.
Thanks for writing these up. I'll share some thoughts (that might not be 100% thought through).
I can get a 2TB micro SD card on Amazon for ~€200. So a user with an existing phone might choose between that and getting a dedicated device. A Mini PC is probably a better option (better hardware, longer lifespan...), with a similar price tag (quick search shows options ~$180). Not disagreeing, just wanted to look at numbers.
In my testing, a 1 TB card was fine.
I found this interesting data point (via the Pew Research Center) that 15% of all U.S. adults are “smartphone-only” internet users – meaning they own a smartphone but say they do not subscribe to a home broadband service. That does not say anything directly about the speed/quality of their connection, but this being about the U.S., it's probably pretty good in a global comparison.
Hope I understand the concern here correctly. I tested the keeping up part (April 2023) and it was not a problem. A system task/notification that runs at all times keeps the process running and syncing. I did not test while being extensively out and about, traveling, shaky connections, etc, so I can't speak to that.
Regarding making transaction, there is also the question of how important it is that the node is synced at all times. Let's say price keeps going up and the minimum economic amount to send/receive increases, then users will make fewer transactions. Might only be rent, large purchases, etc. These do not have the same requirement for immediate availability as the all-important coffee-shop purchase. What still feels like a convenient amount of time to wait for syncing for an important transaction? 5 minutes? Not sure, but there is a difference.
I am also curious about the sourcing of the snapshot. My understanding is that this has not been 100% fleshed out in general (manual download, peer-to-peer download...). If it has been, I'd love to hear more about it.
Once the Version 2 Preview is live with the basic wallet features, I would love to do run some user research on this. Would be amazing to get 100 people or so across the world to use the application and keep a bit of a diary. This might be the only way we can actually get a feel for performance with real-world devices, which might then inform refining the target audience as well as development.
This can absolutely not be underestimated and is very much worth thinking through and creating a plan for.
I do think that bitcoincore.org can play a role in this, and I tried to consider that in my redesign concepts. Right now, the site speaks to developers. If all of a sudden another type of user shows up, it would be helpful for the site to allow the different user types to self-select to different areas (devs might look for technical docs and GitHub/IRC, while users want a feature list, a FAQ and a forum, etc).
No matter what it looks like in the end, doing more means that more people (or AI agents?) will need to chip in one way or another. Ideally, this can be done gradually at a slow-ish pace to find a natural state and reduce bumps along the way.