The bottom line is that the original multi-algo solution really had 5 independant algos.
This was only slightly more secure than typical single algo, with the extra security mostly steaming from attracting more people to mine.
If you think this involves no social considerations you missed the whole point.
The assumption that having N algos attracts 1/N computing power per algorithm is just nonsense.

MYR was badly timewarped some months ago. Since then, the multiple-algos have been mildly 'bound toghether'. MentalCollatz basicall made a ELI10 explanation on r/myriadcoin some time ago but I fail in finding decent keyword to search.
As far as I remember, diff calculations are still the same but the way the good chain is selected is much improved.

For a distributed system, I'd say the logic driving this is surprisingly simple: they could do full statistical analysis of some sort. That's probably still not enough; nonetheless it's obvious we need to reject this so we can move forward </sarcasm>.

Nice thread of one-liners.

Based on my research for an industrial automation project I recently had to look at.

Arduino
+ More affordable
+ Analog I/O
+ Extremely low power draw; running on batteries seems viable
~ Arduino is really a whole family of products and performance varies widely; the most interesting Arduinos (Uno, Leonardo, Micro, Esplora) are microcontroller-based and cannot run any "widespread" OS.
- Connectivity is usually a bit problematic; restricted on specific models or using specific shields/addons.
- CPU performance typically anemic; no GPU

It is clearly targeted at digital/analog circuits experimentation and prototyping. Extremely good at it.

Raspberry
+ 2(+1) standard products being manufactured AFAIK; the cheaper being microcontroller based is probably not quite a good deal even at 20 bucks
+ very flexible platform, with the most recent versions being able to run a whole OS
+ Considerably more powerful CPU, video decoding (encoding?) ASICs, I have been told the GPU is quite powerful (but no idea on shader model etc)
+ Ethernet, USB, HDMI, composite video
~ Nice addons (HATs); mostly cosmetic though
~ Heat spreaders are optional; I'm not sold on the idea of running it at load without them
- As far as I can tell, no analog I/O, needs an HAT.
- A board, a case, an hat, PSU and maybe an SD card and you'll be quickly over 100 bucks.

Raspberry (2) is much closer to a fully featured computer and "average joe" problems. The digital functionalities allows it to take a stab at some of Arduino problems but it's a whole different thing at its core.

There are two possibilities. At the bottom, they use proper SIMD programming. Just open some random Cuda kernel and you'll notice their scan hash is sometimes 2D. This allows them to sum the amount of registers and fill the worksize more effectively as multiple WIs are used on the same hash.

The other point is that NV exposes SIMD shuffle in Cuda (being device-specific). OpenCL tries to be device-independent and therefore has no SIMD shuffle (CL2 has some basic shuffle functionality but still lacks full shuffle). AMD driver team is either too busy fixing bugs or improving perf on the game of the month so they couldn't be bothered in providing CL_AMD_GCN_SIMD_shuffle.

You should talk to your professor. If he talked about capacitance and such, odds are he might want something different from what you'll end up with.

Who cares. The shelf price is at least 30% lower here.

So, maybe it's the same thing to you. It isn't to me.

Doing it fully digital on the microcontroller would be an exercise in futility and as a side note, against the objectives of the Arduino system.

You don't want to do scrypt as it has a whole load of memory to take care of - 128KiB.

Every time you see a rotate instruction in hashing that's equivalent to shuffling the wires.
Every time you see a "shuffle registers" section, that's equivalent to shuffling bundles of wires.

Because microcontrollers don't run generic operative systems compiling a generic miner will be problematic. Perhaps adapting them would be enough complicated to be a project in itself.

If you think you can make any money from it, you're better stop right now.

If you want to do scrypt do it. I cannot see how you're going to fit the 128KiB of scratchpad (I see from microcontroller data sheet you have 2KiB at most).
Do you want to do SHA256? That's easier.

Same as loading GPU.

Because of course loading CPUs don't increase power consumption.

This is starting to get really funny.

There's a dude trying something with Arduino... perhaps you could read that topic as well.
My suggestion: get creative with GPIO and implement (say) Qubit on an analog HAT, would be nice.

You cannot find GPU memory latency easily because it's a function of the kernel being run.
For graphics kernels, latency is effectively 0.
Scrypt on my 7750 is not memory limited at all (using GAP 2), my performance scale with GPU clock perfectly.

The memory you're talking about exists in commercial products. GPUs have it, it's called Local Data Share or "local memory". It's already twice as big as L1 (just because some idiots think cache is efficient), it has lower latency (potentially a couple of clocks), twice the bandwidth, it has a 32-way crossbar (!!!) and I've been told it burns 1/4 of the power.

I have no idea how you guys insist on top-end cards. They have a well known premium.
It looks to me the card to buy is 380. It seems very affordable around here and Tonga has byte-lookup instructions. With recompiled kernels there could be a nice speedup (or not...).

As a side note: 7750 can do well in excess of 2 qubit MHS with publicly available kernels. Users able to run it on big cards (I don't remember which card) told me they go over 10M. I'm inclined to believe another 50% is possible.

Arduino is not a compute-oriented system so I don't see this going anywhere.
Nonetheless, the Salsa passes in scrypt are known to be very ASIC friendly some parts of them can be done in analog since they're just shuffling the wires. Maybe you can set this as your first target.

In theory you could reduce the memory footprint till it fits your memory and use the analog Salsa'ers to compute what you don't have in memory.
It seems very interesting from a purely educational experience.

I'm not sure however where is the problem with the analog quantities. Scrypt is digital in nature.

Bullshit. The difference is whatever the miner is public or not. In the latter case, you're screwed harder.

Hello fellow programmer!
Shall you need inspiration, feel free to take some MIT code. It was also written with clarity as a primary objective and has been refactored a few times already. There are only an handful of kernels but at least they are unencumbered by GPL constraints.

No, I definitely didn't read your post as a recruitment. It was just a bit opaque.

So basically what you're writing is:

thank you for your for your work guys. Have you considered helping even more?

GPU mining is still very much alive... not very well however.
To mine on the cheap, nothing beats GPUs, especially if you already have a decent one in your processor!
Try multi-algo coins. Install wallet once, play with multiple algos. MyriadCoin is currently quite low diff, odds are you might hit a few blocks even without joining a pool (not that I suggest to solo-mine). Digibyte is also multi-algo now but diff is high.

Oh well, I guess I'm ok knowing you're aware of this.

How exactly is people jumping to conclude Lyra2 FPGA exist?