Modern smartphones seem to pack quite a load.
I got a Samsung galaxy note 4, which boasts 3Gb of RAM and 8 cores.
One wonders - what if…?
Well, i compiled my standalone miner for it, and sadly it only does a hash per 138 seconds.
That is a bit too much for real use, since the average block time is 150 seconds.
Core count does not help here (only 3 are usable with this much RAM and OS load), since even if all of them were to make a hash, you’ll get 8 hashes that are too late rather than one hash that is too late.
Mine managed to wedge in two hashes over 15 minutes of run time, but only thanks to long inter-block times that won’t be common on the real net.
So, with this kind of hash time and block time, latency is everything - you can’t just upload the code to every fridge and lightbulb and get a slight improvement by sheer quantity over quality.
You need machines that can do at least one hash every minute.
MIPS laptop, Loongson CPU, 2Gb RAM. Takes 800 seconds to solve, useless.
ARM dev board, 1Gb RAM, Takes 300 seconds to solve, useless.
MacBook 2009, 2Gb RAM, takes 80 seconds to solve, useless.
In the end, i would guess the toppest of the top phones might be usable, but in general you can’t mine on devices.
Which is rather sad…
Anyway, that was the “what if” of the day. Back to work.
So long as the difficulty is adequate for the entire network and new blocks are taking two and half minutes to be found, any device that can solve within that time can make a useful contribution to a pool.
None the less, I’m impressed that you’ve been working on that kind of software for your phone. Do you know what its memory bandwidth should be? Or its other general hardware specifications?
General specs are easily googleable, but not really sure about the bandwidth is and similar things. I doubt this kind of hardware is publicly tested that much in such weird modes of operation.
One curious idea given by tromp on Slack was to multi-thread the single solver instance (rather than solving multiple instances), which should yield faster hash times, and thus make it practical.
I’m going to research this approach next, i think.
What solve time did you get for a single core?
btw I hope you get some good results with the multi-threaded solver.
Oh man, I’ve just started working on a mobile miner myself! Lol
138 sec is barely squeeking in on this side of feasible. Multithreading advancements might bring that down to something a bit more worthwhile (whenever that comes along).
I’ll give it a try on my SE and see how it benchmarks.
Are you coding natively? Or just using something (like phonegap) to wrap the existing code? It might make a performance difference (not sure, just speculating here).
I really hope we can get an open source miner that is optimized enough to run on a phone (and other smart appliances).
Imagine the mining decentralization we could achieve.
How are you cooling mobile devices? I mean, mining could be feasible, but they are not designed for long time high resources consumption and might just … melt?
Yeah, and also block time must be > battery time mining
Block time was 138 seconds.
I managed to bring it down to 100 as the code continues to optimize, but it’s still a bit too high without threaded version.
I’m coding natively, just running an ARM program directly on the underlying Linux-ish system through a terminal emulator.
Rest assured, there is no UI.
Overheating wasn’t really a problem, but the thing got pretty hot. I ran it wired to avoid overdraining the battery.
It’s not block time < battery time yet, but… Better be prepared.
Putting aside whether or not these platforms are fast enough, could your program execute on a Raspberry Pi 3 (with 1GB total memory)? What about a PiZero (with 512MB)?
It would run on the 1Gb one, assuming Linux won’t eat too much RAM (i.e. a 2 Gb RAM PC only got 1.6-1.8 Gb RAM available), but won’t on the 512Mb one - minimum memory is 560Mb of actual solution space, not counting the OS and so on.
I doubt phones are designed for continuous 100% CPU utilization, even when connected to USB. I think there is a high probability phone will stop working after a few days of such abuse. If that works however, one can create an app with the slogan “Magically top-up your phone while you sleep!”.
Most modern phones will shut themselves down if they get too hot. So overheating isn’t an issue. Other than that I don’t think ARM processors have any limitations w.r.t. maximum utilization.
There are a lot of other components in the phone apart from the processor that might not like constant baking.
See this component? It can perform several billion operations per second. But only on Sundays…
Makes sense. No one would be crazy enough to play games on their phone 24/7, right?
AFAIK, a human would die from this somewhere around 36 hour mark, so why bother making a phone that would survive for longer?
Any updates on this concept?
It was an experiment to see how portable my miner was, and once tromp, xenoncat and the rest discovered the index optimization the whole thing got dropped as obsolete.
Please can you share with our BitcoinZ community your Equihash android miner?
Could you improve it to us?
It would be cool with new coins like our coin, even
If we only can get one coin per day! It will worth much more this year and much more after a year!!
Thx! Come and join us Bro!
Not even sure if i still have the code, and in any case it was the early pre-index algorithm, the one that took tens of seconds per hash, not the later ones that do a hash or two per second.
Even then, modern GPU miners do hundreds of hashes per second, so the whole thing is pointless anyway.
Would you mind trying to compile my Cuckoo Cycle solver  on ARM and run on a modern phone?
I’m rather curious to see how much slower it is than a desktop CPU…
 GitHub - tromp/cuckoo: a memory-bound graph-theoretic proof-of-work system, specifically the mean30x1 target