And people don't be greedy dicks!
Use lower hashrate on pools - less mining costs, better reward! -.-
I fixed your post. Use lower hashrate on pools - less mining costs, better reward! -.-
Topic: [ANN] [XMG] MAGI | CPU mining | mPoW | mPoS | [MagiPay] - page 1201. (Read 2375926 times)
And people don't be greedy dicks!
I've released fastest miners few days ago and didn't get any donation at all, even single coin -.-
I've released fastest miners few days ago and didn't get any donation at all, even single coin -.-
I haven't even switched to your miner yet, but I appreciate the effort. Here, have 10 coins on behalf of the free loaders.
Sorry by the hard work we sometimes forget the good things
I send you directly 50 XMG.
Please let me know whether you have received them.
I am glad that such people like you are in the XMG community.
MarcusDe received XMG yet? Or are you sleeping right now?
Don't know the time at your place right now.
If it did not work let me know
nice one thank you.
I tried to mine coin this but i could not get the miner working.
i tried 3 miners and 2 pools and it just crashes.
then for kicks i checked out the pools hash rates and its botnet city
i tried 3 miners and 2 pools and it just crashes.
then for kicks i checked out the pools hash rates and its botnet city
And people don't be greedy dicks!
I've released fastest miners few days ago and didn't get any donation at all, even single coin -.-
I've released fastest miners few days ago and didn't get any donation at all, even single coin -.-
I haven't even switched to your miner yet, but I appreciate the effort. Here, have 10 coins on behalf of the free loaders.
Sorry by the hard work we sometimes forget the good things
I send you directly 50 XMG.
Please let me know whether you have received them.
I am glad that such people like you are in the XMG community.
And people don't be greedy dicks!
I've released fastest miners few days ago and didn't get any donation at all, even single coin -.-
I've released fastest miners few days ago and didn't get any donation at all, even single coin -.-
I haven't even switched to your miner yet, but I appreciate the effort. Here, have 10 coins on behalf of the free loaders.
And people don't be greedy dicks!
I've released fastest miners few days ago and didn't get any donation at all, even single coin -.-
I've released fastest miners few days ago and didn't get any donation at all, even single coin -.-
can any1 post the latest windows 64bit miner plz 
Spexx Beta version here:-
https://www.dropbox.com/s/hiadf8o5u7bsit7/XMGpoolminerWin64.rar?dl=0
There are other versions available (see OP) but this one seems to run the fastest, albeit with limited support for the use multiple threads. If you want to run more than 2 threads, come back to me since there are some tuning instructions which I have yet to compile into a full release version.
Fastest? Let he test it himself:
http://graymines.net/miners/magi/
What is your opinion about the following idea? We talked about it long time ago, but didn't push it further (had a discussion with Bojcha too):
modify the algo, keep it half-closed source, and pool setting a limit to the hashrate.
modify the algo, keep it half-closed source, and pool setting a limit to the hashrate.
That was mine proposal for this hashrate limiting. If this 5 coin reward stays so and hashrate does not fall under 50MH/s, it will be needed much longer time to mine all coins. This can be double-edged sword for sure but it's possible. Here is how it should work, by also looking and learning on errors of other coins that used same thing.
- Source is (how i like to call it) half-closed, meaning olny dev, pools and exchange have source.
- wallet mining disabled
- pools limit hashrate
- pools need to have worker limit (1 worker) - if more PC's are in use, all can be pointed to 1 worker without problems.
- etc..
This way hashrate will be easy controlled and easy to follow by everyone. Everyone can follow blocks on pools so if some blocks are missed then someone is mining out of system. However when POS blocks starts in the middle of POW those block will be missed on pools ofc!
So what you all think?
LOL, pool limiting hashrate is impossible. Use a proxy and create more workers.
You're trying to make mining into something it's not - centralizing it and forcing people to use small amounts of hash just... isn't going to work.
What is your opinion about the following idea? We talked about it long time ago, but didn't push it further (had a discussion with Bojcha too):
modify the algo, keep it half-closed source, and pool setting a limit to the hashrate.
modify the algo, keep it half-closed source, and pool setting a limit to the hashrate.
That was mine proposal for this hashrate limiting. If this 5 coin reward stays so and hashrate does not fall under 50MH/s, it will be needed much longer time to mine all coins. This can be double-edged sword for sure but it's possible. Here is how it should work, by also looking and learning on errors of other coins that used same thing.
- Source is (how i like to call it) half-closed, meaning olny dev, pools and exchange have source.
- wallet mining disabled
- pools limit hashrate
- pools need to have worker limit (1 worker) - if more PC's are in use, all can be pointed to 1 worker without problems.
- etc..
This way hashrate will be easy controlled and easy to follow by everyone. Everyone can follow blocks on pools so if some blocks are missed then someone is mining out of system. However when POS blocks starts in the middle of POW those block will be missed on pools ofc!
So what you all think?
LOL, pool limiting hashrate is impossible. Use a proxy and create more workers.
You're trying to make mining into something it's not - centralizing it and forcing people to use small amounts of hash just... isn't going to work.
But i agree.
Dev, Please don't do this and forget what said.
can any1 post the latest windows 64bit miner plz
Spexx Beta version here:-
https://www.dropbox.com/s/hiadf8o5u7bsit7/XMGpoolminerWin64.rar?dl=0
There are other versions available (see OP) but this one seems to run the fastest, albeit with limited support for the use multiple threads. If you want to run more than 2 threads, come back to me since there are some tuning instructions which I have yet to compile into a full release version.
Re: Opinions on the state of play.
Restricting the source code and restricting hasrate by brute force is the wrong way to go and unlikely to win friends. Excessive tinkering at this point would be unwise and it seems good the way it is right now imho. Far better to simply get the message across to the miners with over say 1 Mh/s at their disposal that they are actually the problem. These miners need to realize that they could be throwing far far less hashing at it and get much higher rewards. Yeah - it's counter-intuitive and people need to wise up. Perhaps this particular feature requires greater emphasis in publications. From a few back-of-a-cigarette-packet calculations I reckon miners should be aiming for a maximum 200 Kh/s each, then we can see how the totals work out in more detail. The only problem I see with this approach is that self-restraint in not general human nature while greed is generally the norm. XMG is different - greed should not be rewarded.
Restricting the source code and restricting hasrate by brute force is the wrong way to go and unlikely to win friends. Excessive tinkering at this point would be unwise and it seems good the way it is right now imho. Far better to simply get the message across to the miners with over say 1 Mh/s at their disposal that they are actually the problem. These miners need to realize that they could be throwing far far less hashing at it and get much higher rewards. Yeah - it's counter-intuitive and people need to wise up. Perhaps this particular feature requires greater emphasis in publications. From a few back-of-a-cigarette-packet calculations I reckon miners should be aiming for a maximum 200 Kh/s each, then we can see how the totals work out in more detail. The only problem I see with this approach is that self-restraint in not general human nature while greed is generally the norm. XMG is different - greed should not be rewarded.
Very suggestive comments, Spexx; you're right we should emphasize lower hash getting higher rewards. There is a feature I didn't disclose yet, the diff where maximum XMG occurs increases over time, that will allow more and more people mining XMG and share the maximum rewards later on.
What if hashrate never drops? If more people finds this coin interesting, as i also hope, - no big reward.
What if they actually realize that with lower hashrate they can have more, but if one alone do that it will get in worse position. It's hard to belive that they all will realise (in more or less same time) that they should use much less hashrate.
At least some big red letters should be on homepage of pools to "ask" miners to not use more then xx kH/s.
can any1 post the latest windows 64bit miner plz
It's few pages back, not yet have time to update the OP; Spexx, can you post your compilation for Zlush1337?
Re: Opinions on the state of play.
Restricting the source code and restricting hasrate by brute force is the wrong way to go and unlikely to win friends. Excessive tinkering at this point would be unwise and it seems good the way it is right now imho. Far better to simply get the message across to the miners with over say 1 Mh/s at their disposal that they are actually the problem. These miners need to realize that they could be throwing far far less hashing at it and get much higher rewards. Yeah - it's counter-intuitive and people need to wise up. Perhaps this particular feature requires greater emphasis in publications. From a few back-of-a-cigarette-packet calculations I reckon miners should be aiming for a maximum 200 Kh/s each, then we can see how the totals work out in more detail. The only problem I see with this approach is that self-restraint in not general human nature while greed is generally the norm. XMG is different - greed should not be rewarded.
Restricting the source code and restricting hasrate by brute force is the wrong way to go and unlikely to win friends. Excessive tinkering at this point would be unwise and it seems good the way it is right now imho. Far better to simply get the message across to the miners with over say 1 Mh/s at their disposal that they are actually the problem. These miners need to realize that they could be throwing far far less hashing at it and get much higher rewards. Yeah - it's counter-intuitive and people need to wise up. Perhaps this particular feature requires greater emphasis in publications. From a few back-of-a-cigarette-packet calculations I reckon miners should be aiming for a maximum 200 Kh/s each, then we can see how the totals work out in more detail. The only problem I see with this approach is that self-restraint in not general human nature while greed is generally the norm. XMG is different - greed should not be rewarded.
Very suggestive comments, Spexx; you're right we should emphasize lower hash getting higher rewards. There is a feature I didn't disclose yet, the diff where maximum XMG occurs increases over time, that will allow more and more people mining XMG and share the maximum rewards later on.
Thank you very much, dcct. I love the explorer, particularly the diff vs time graph:
It's clear that diff is nearly constant between 09/18 and 09/21, while it declines after 09/21 when hard fork happened.
Currently 530 active miners.
can any1 post the latest windows 64bit miner plz
Re: Opinions on the state of play.
Restricting the source code and restricting hashrate by brute force is the wrong way to go and unlikely to win friends. Excessive tinkering at this point would be unwise and it seems good the way it is right now imho. Far better to simply get the message across to the miners with over say 1 Mh/s at their disposal that they are actually the problem. These miners need to realize that they could be throwing far far less hashing at it and get much higher rewards. Yeah - it's counter-intuitive and people need to wise up. Perhaps this particular feature requires greater emphasis in publications. From a few back-of-a-cigarette-packet calculations I reckon miners should be aiming for a maximum 200 Kh/s each, then we can see how the totals work out in more detail. The only problem I see with this approach is that self-restraint in not general human nature while greed is generally the norm. XMG is different - greed should not be rewarded.
Restricting the source code and restricting hashrate by brute force is the wrong way to go and unlikely to win friends. Excessive tinkering at this point would be unwise and it seems good the way it is right now imho. Far better to simply get the message across to the miners with over say 1 Mh/s at their disposal that they are actually the problem. These miners need to realize that they could be throwing far far less hashing at it and get much higher rewards. Yeah - it's counter-intuitive and people need to wise up. Perhaps this particular feature requires greater emphasis in publications. From a few back-of-a-cigarette-packet calculations I reckon miners should be aiming for a maximum 200 Kh/s each, then we can see how the totals work out in more detail. The only problem I see with this approach is that self-restraint in not general human nature while greed is generally the norm. XMG is different - greed should not be rewarded.
Will hold swapped coins, wouldn't want to miss out on the fun later.
Good choice I do the same! If the price is right I buy a little more XMG!
hmm am afraid that people who now sell cheaply later going to regret this.
Will hold swapped coins, wouldn't want to miss out on the fun later.
Jump to: