After reading for the few weeks leading up to the hardfork, as well as the few days after, I've been both impressed and disappointed in the magi community. There are plenty of people that are happy with the growth in magi, and plenty that are simply upset they cant earn any mining. The mining issue has been one that has slowly been reaching a boiling point over the last few months, and was even an issue last time we forked. A lot of people are calling for limits for mining in the protocol, poolside, in the miners, etc. I'd like to take a minute to discuss the issues with each of these approaches and offer my suggestion.

To begin with, we need to understand the potential types of whales we're dealing with.
1 - Botnets
2 - People with large amounts of CPU/CPU power. This could quite simply be someone with a few, very powerful CPU at this point.
3 - People with a private or personal GPU/ASIC miner. Although this is a rumor, this should be considered.

We also need to look at some of the commonly proposed solutions to the hashrate.
1 - limit hashrate poolside
2 - limit hashrate in the protocol
3 - limit hashrate in the miner
I'm aware there are other suggestions as well, they simply dont come to mind as quickly as these and will likely fall under the same ineffective solution as these.

Looking at these issues, the first is easily avoided. Botnets can be configured to create workers for each CPU in the net, or if there is an account limit than a separate account. People with large amounts of CPU power can easily do the same, especially considering if they fall under the few, very powerful CPU category. This would solve the issue of a single miner/worker having a large hashrate, as would be the case for a GPU/ASIC miner, but these are unproven rumors and likely would have minimal impact. It would, however be nice to see.

Moving to limiting hashrate in the protocol. I've seen this suggested and I'm not a technical as many in this thread, however I can already see some issues with this. It will only be a matter of time before someone "cracks" the new update, and when that happens do you think this person will share the code? This will only punish those following the rules more and allow those that abuse the network even more success.

Finally, limiting hashrate in the miner. Same as above, this will just result in other miners without the limit being made, or endless guides on youtube/steemit showing you how to disable the limit.

So what can be done? In my opinion there is no silver bullet, and there is no perfect plan. No matter what the magi network as it stands and is designed will never function perfectly, but we can get closer to the ideal. To begin with, I do believe an updated miner should be released. This miner should use some sort of sweet spot control by default, so the hashrates adapt and change to promote healthy network hashrate. Of course this could be diabled, but that is an extra step that would need to be taken, and would help a good bit. Second, I believe the previously mentioned idea of having the miner suggest if you hashrate is too high/low/just right is good. This could potentially draw miners attention to this and may lead some of them to lower their hash, direct it elsewhere, or simply enable the previously mentioned "sweet spot" mode.
As for pools, simply suggesting on the dashboard whether a users/workers hashrate is too high/low/just right could also help, this would compliment the changes above as well.

The big change I'm suggesting is that we as a community start to seriously suggest and recommend dual mining XMG. I've been experimenting with this recently and I'll be posting some results in the following weeks, but this seems to be a good solution for a number of reasons. For starters, for big miners and botnets this offers the ability to earn more than mining either specific coin on its own. The main benefit for magi, at this point, is then that a majority of their hashrate is moved to another coin, however, some of it does remain. This would be a great point to bring up the idea that magi is supposed to be an "idle power" mine, in that you just use the idle power on you CPU, or in this case leftover from the other coin you're mining. A great example is XMR and XMG, XMR is very cache dependent, and so most of the time one runs out of cache before one runs out of cores. In this example, likely dual mining would take roughly 50-60% of the hashrate from magi, again not perfect, but better than where we are now. I know this wont encourage all of the botnets or large miners to switch, and I know this wont change everything, but I think that all of these things put into action would help to alleviate the strain on the network and small miners.

tl;dr
To help with the issues many are having mining these days I suggest:
1 - Modifying the miners to automatically use a "sweet spot" functionality
2 - modify the miners to suggest whether your hashrate is too high, too low, or just right
3 - draw attention to the fact that magi is design as a "idle power" mine, this can be done on the website, OP, regular posts through here, etc.
4 - suggest and draw attention to the benefits of dual mining XMG and others, such as XMR.

These are just my thoughts and I'd be interested to hear what everyone else thinks. I'm not trying to solve the problem, I'm just trying to come up with ways to help!! I'm sure magi will pull through though 

I've actually got an orange pi with the allwinner H3 on the way right now, can I ask if you're running a 64 bit OS on that? or if you know if it's possible?

well, i cant speak for him but i can give you numbers based on my results with a 1600 overclocked, assuming perfect scaling across cores. My 1600 at 3.9 and 3200 memory manages around 150-160 kh/s, or roughly 26.6 kh/s per core, or 13.3 per thread. Assuming good scaling, that puts a 1700 right around 210 kh/sec. I did a more in depth post waay earlier in the thread, if you want to see the whole post, I checked and its from August 1 2017.

Probably, given the right amount of time and the right power costs. Its too hard to say with no information though. Beyond that that kinda goes against what XMG is all about, more hashrate =/= more rewards, look into the POW II posts to see this explained more. ideally everyone would only have to chip in 5-10% of their CPU power and everyone would get the same amount of XMG they're getting now, or even more. As it stands, me personally the "highest end" i would consider would be something like a R3 1200 or similar, seems to be the sweet spot for price/performance.

There are numbers somewhere for 4770k, im not sure but iirc it's something around 100kh/s at 100% efficiency setting. Ideally you wouldnt mine at that though, that goes against what XMG is about. Reward changes every block based on network hashrate, so it is hard to estimate rewards. When mining is back up there are commands built into the console in the wallet you can use to estimate rewards based on current difficulty and rewards for the current block though.

There is an average in there, and a rather good one at that. I figured the reward/2^32*Difficulty individually for every block for the last 2 weeks, over 19,000. The average of those numbers was then multiplied by the appropriate hashrate and timeframe, in the example I gave 100kh/s and 1 day. I know that this wouldnt work as an estimate for magi without an average, which is why I went for a quite large one, to get accurate approximations. I feel that if this uses the correct formula, etc. this would be just as accurate of an indicator, if not more so than the included calculator in the miner, which does base rewards off of the current reward/difficulty.

Can anyone share the math for figuring mining rewards for a given hashrate? I worked something out earlier and I think my numbers are coming out wrong.
I used the formula for BTC (B=(h*r*t*)/(2^32*D)) (which I suspect may be the issue) to figure the est. earnings per block for the last 14 days, then took that and averaged it out to come up with a "long term" estimate. Exact math as follows, using block 1592129 as an example:

dif. = 0.0102
reward = 0.11453505
time = 86400 (1 day in seconds)
hash = 100,000 (100kh in hash)

0.11453505/(2^32*0.0102) = 0.000000002614438178 (this is done for every block, independent of hashrate/time so the calculator works with different values)
0.000000002614438178*(100*1000)*86400 (values for hash and time can be changed to suit other needs, hour/day/week, etc. and for hashrates other than 100)

The basic break down is that the first part is done for every block, then this number is averaged for every block. Then, the other aspect that remains constant (hashrate) and the duration (time) are calculated after. Shouldn't matter that these come after because order of operations, if I'm not mistaken.

For the last 2 weeks, all 19195 blocks, the first part average is 0.000000001290530053. When appropriate values are added for time (in this case one day, 86400 seconds) and hashrate (in this case 100kh, 100000h), the "average" earning per day would be around 15.61 XMG a day, which seems far too high, especially given my mining and observations. Which leads me to believe there is a problem with my methods.

Is this just a case of "I have the wrong formula"? Have I accidentally done something wrong with my math? Could this have to do with pool mining vs. solo? Have I missed the point? Is XMG really this awesome and I've just been mining wrong?

Bear in mind, this isn't supposed to be a calculator for the future, rather a good, long term example that can be used as an estimate for the future. If over the period of the last week a consistent 100kh/s will net 15 XMG, then I feel safe assuming that earnings for the next week would be around 15, with what level of variance I'm not sure, but it's a start and to me much more applicable than the "current block estimate" calculator in the wallet. That said, is there any reason why this WOULDN'T work, even in the slightest, due to something I've missed in XMG's POW II system?
If someone smarter than me wants to help me out that would be great!  There is a reason I'm not a math major, after all.
If someone wants to comment on if this applicable/waste of time, useful or just interesting data, that too would be well appreciated! After all, there is probably something really dumb that I'm missing.

Last note, all data was taken from https://chainz.cryptoid.info/xmg/

That might have changed. The one I'm looking at using seems to have a micro usb for power, and alternatively also even supports POE. The listed specs on aliexpress state the power is supplied from "usb otg" which to me means micro usb, especially looking at the pictures. Could it just be the older models?

I'll have to check in on the 32 vs. 64 bit situation. It very well may be the case. I was interested specifically in the orange pi zero h2, which seems to keep up with the rpi3 in some cases, lag in others. the advantage is the price, around 10-11 bucks each, which is much cheaper than the rpi3. Even if I can only manage 70% or so the same hashrate it'd still be fine for me! Thanks for the heads up on the instruction support though, is there anything else that you or others could think of that might hang the idea? Nothing comes to mind, but in my experience with SBC there's always something...

I think he meant it more as a good spirited "I keep investing in this coin because I like it" kind of deal, rather than a "I'm bleeding money into magi" kind of deal. The comment about 4k is just him wanting to realize good profit and a good exit on his investment so far then, not a need to like break even. Could be wrong though.

It's been a minute since I last checked in.. Last time I was here the hard fork madness had just blown over. Glad to see things are back to normal with magi and the community is as friendly as ever. I have 2 questions as they go with magi.

First is to do with mining. I usually mine XMR on my CPUs, but I try to throw any extra CPU power I have at magi, less for rewards and more for support of the project/network. That said, I'm interested if anyone has come up with a way of "estimating" profit over a longer period of time. I know there is the command in the wallet to get the current estimate based of reward, etc., but I'm interested in predicting over a long period of time. Is there somewhere where I could get data over the last month or so for reward per block, and from that derive what my earnings could have been over say the last month for "x" hashrate? Or some other method? Is there another calculator I'm unaware of? Realistically it seems that one only needs a data table of the changes in hashrate, and reward, and can then apply the methods for calculating reward to each of these instances across a period of time to recieve an average, but I could be mistaken! If I'm wrong or overthinking this someone please let me know.

Second, I know there has been plenty of use/talk of XMG with the Raspberry pi. Has anyone ever tried these on other SoC? Specifically interested in Orange Pi, although experience with others would be interesting and helpful. If it matters and people that have worked with magi on the Rpi feel like helping I can dig up information as it pertains to the orange pi as needed. Thinking about maybe setting up a little miner/node, think it might be an interesting project for a boring winter weekend.

All that out of the way I really am glad to see magi is growing and doing well, especially in value. Crazy to think about where XMG was this time last year and compare to now. Is there anything else major that I've missed since the forking fiasco? I'll be sure to go back and read through the thread in the next week or so, but just as a quick and dirty recent history?

I'm always interested in CPU only coins, botnet issues or not (they all seem to have them). These hashrates looks very promising, however what would 24 hour rewards look like with these hashrates? Or adjusted down to an even 100h/s? Anyone have any input here? I'm interested in the coin and currently reading up, seems like the tech is there as far as I can tell, nice to see something like zerocoin implemented as CPU only

this is whats wrong with mining magi. Absolute disregard for the most useful, interesting, and important part of the m7m algorithm.

I'm not sure if these are all tied together, but as i see it there are a number of major issues facing magi right now.
First and foremost is the issue of securing the blockchain. At this point and after this number of forks and pools on the wrong chain(s) something needs to be done, if that means taking mining offline for a number of days so be it. I've been against a rollback this entire time as well, but at this point if this will fix the issues currently facing the network what must be done must be done.
Secondly, something MUST be done about large miners, botnet mining, block rewards, and pool distribution. Perhaps there is someway to rework the m7m algorithm to FORCE the -e stipulation to be observed based on network hash, as well as local hash.
Third, I feel a lot of blame falls not on the developers of magi, but the community or rather those looking to exploit magi for a quick return, as well as the pools and operators for flat out refusing to enforce the "maximum" hashrates, as well as continuing to let this abuse slide.
We need to fix our blockchain and our coin, then worry about fair mining rewards/botnet/massive hashrates, then worry about how to deal with pools dominating the network hashrate and refusing to act against miners with large hashrates.

I'm with Frisian on this one. I almost feel like this influx of miners complaining is directly related to the high hashrate miners and potential botnet operators. I got into magi almost a year ago because I thought it might be nice to have a CPU coin to mine with my GPU mining, and after looking at the project goals and reading up on the coin fell in love with the community. As far as coins or projects go this one has a unique algorithm, with the unique twist of actually trying to prevent an arms race in terms of hashrate, as well as good rewards for POS while still remaining a CPU only coin. Sure, there are things that need work, as we've obviously seen in the last 2 weeks and even before hand with the lack of effective marketing, but the project has great development and an excellent vision.
Stop treating this like the CPU Ethereum, that isn't was magi is, and it will never be a huge mining currency. Unlike other pump/dump mining coins you actually have to read a little, know a little, and care a lot to get anything out of magi, and I'm 100% OK with that.

just tried this and no dice, still the same issue.

still no luck with the solo mining. Tried moving the wallet to the main desktop off of the NAS and still the same issue. .conf looks like so:
rpcuser=rpcuser
rpcpassword=rpcpass

rpcport=8232

rpcallowip=127.0.0.1

listen=0
connect=104.128.225.215

daemon=1
server=1
rpcport=8232
rpcallowip=127.0.0.1
rpcuser=user
rpcpassword=x

it could be that! I have my wallet on my NAS currently, will try moving the miner to the NAS/wallet to main machine

Thank you so much for this!! Will try it out.

Also, I seem to be having issues solo mining. I believe everything is set up correctly in my .conf file, however whenever I try to run m-minerd I'm given this error message: "HTTP request failed: Failed to connect to 127.0.0.1 port 8232: Connection refused"
followed in the next line by:
json_rpc_call request failed, retry after 30 seconds
what do I need to do here to be able to solo mine? Is this something stupid I've missed? Or perhaps a windows issue?
m-minerd .bat looks like so: m-minerd --url http://127.0.0.1:8232/ --user user --pass x -t 6 -e 95

Is there any way for me to go about installing the wallet on a NAS, rather than on the desktop? At least without configuration files being stored on the desktop or the machine running the wallet as well? I'm a bit confused by all this and I'd like to have my wallet self contained on my NAS if possible, due to reliability concerns on my desktop.