Why does reward have to proportionate to hash power? E.g. have it more of a "Lottery" with Miners than "who solves this mathematical problem first". This way there is incentive to use the "lightest" or most "power efficient" devices, while still keeping to the (at least I thought) goal of "everyone being equal". This may kill pools, but IMO they aren't helping the distribution of the Magi network, just consolidating it into various entities.
Wouldn't it be nice if a Pi 0 could "mine" (and get a reward)? For $20 I can make one that is solar powered, network connected, and a battery backup.
Maybe make block time / rewards equal to the number of nodes supporting the network? The more nodes, the higher the rewards across the network?
I do like this idea. Perhaps the chance of finding a block could be tied to the network hashrate so that if the network hashrate is high, devices with lower hashrates have a better chance of finding a block. This would encourage miners to use less-powerful devices and mine solo (better for the network).
Block rewards could be based on the number of connected nodes. With this system, rewards could be lowered when too many nodes are connected (This is to prevent people from setting up hundreds of low-power solo miners on AWS or running lots of local miners at 1 h/s) and raised when less are connected. This means that people are still encouraged to solo mine with a small number of devices since pool nodes would have a very small chance of finding a block due to having such a high hashrate.
I haven't actually looked at the cost of AWS services, but my Pi 3 (arch64) "magid -daemon" is using 213MB of Swap, Reserved 691MB, and Sharing 20MB of "Memory", and additional storage of the BChain just to be connected to the network, so there is a tangible cost of resources just to run a wallet, then if limited that to per IP, would make the complexity, setup, and cost of added nodes prohibitive to most, and likely not worth the payout.
From Crypto ID
=======================
84 connections
Network Clients seen in the last 24 hours
Sub-version Protocol Count Network Share
/m-core:1.4.5.3/
71064 178 91.3 % 91.3 %
/m-core:1.4.5.1/
71064 15 7.7 % 99.0 %
/m-core:1.4.5.2/
71064 1 0.5 % 99.5 %
=======================
178 Clients seen in the last 24 hours of the latest version, or sub 200 for all of them.
Wouldn't it be nice if rewards were just evenly split between these nodes provided they are active on the network (regardless of stake)? Then you just removed all the complexity on the end user to "mine", and open it up for any device capable of running the wallet software with a stable connection to the network can earn a "ticket" (as someone else referred to it), so that those running the wallet software on their "Smart Phones", can contribute to the network and possibly earning some rewards in the process. Which makes you even more poised to be used for everyday transactions. As the network grows, decrease minimum time between blocks, to distribute the rewards a little bit quicker, but possibly reduce the amount of rewards (maybe at certain milestones?).
What about the equivalent of stratum with the above? When the network needs work done, it can be split among multiple nodes (and rewards divided accordingly?), that way one low powered device isn't trying to tackle a bunch of complicated transactions, but still can have a part, while offering scalability to the network? Make the network the pool (sorry operators) /brainstorming