[ANN] [XMG] MAGI | CPU mining | mPoW | mPoS | [MagiPay]

[joelao95]

[hardfork] - sorry we have a few hardforks to be done and all gonna happen soon

1. M7M-v2 (hardfork on 10/26/2014 9:30:00 AM EST)

A switchover of the mining algorithm to M7M-v2 will occur on 10/26/2014 9:30:00 AM EST. Details about M7M-v2 can be found here: https://bitcointalk.org/index.php?topic=735170.msg9230961#msg9230961. The expected hashrate using the new algo is 2.545 times less than that with the prior algo. To continue with mining, download the new minerd (we will add download links here and in the OP soon), and follow the pool mining guide.

Be sure that you are using the new wallet v1.1.0.1 too.

2. Block rewarding system (hard fork at block 32,750)

A change in the block rewarding system is needed. This won't change the block rewards, but to be better to comply with the change of hashrate due to the M7M-v2 algo. The new algo leads to less network hashrate; the new block rewards will have maximum value at diff = 0.68 (for low block height); according to hashrate = diff * 2^32/180, that is about 16 Mh/s. We have also made increasing maximum diff with block height, to allow more people mining later on, e.g., optimum hashrate of 27 Mh/s which produces 300XMG at block 40,000.

3. A new difficulty adjustment method - Magi quantum wave (MQW) (hard fork at block 33,500)

Superficially a name here: Magi quantum wave (MQW) (http://en.wikipedia.org/wiki/Wave_function). This adjustment is done by averaging prior 15 block difficulties. A significant difference here from other adjustment implementations is that each block difficulty accounted is given a weight, and higher weights are given to more recent blocks; in addition to that, block time is also taken into account. Usually the lower difficulty, the smaller block time. The adjustment algo considers less weight of a block which has the lower difficulty. See details here: https://github.com/magi-project/magi/blob/master/src/main.cpp#L1296

4. Finalizing the PoW-II

As we can see the PoW-I  (will be finished at block 50,000) has produced less coins than expected. To continue the CPU mining, also along with the new algo implementation, it will be very necessary to continue the PoW mining, that will finally make XMG a hybrid PoW/PoS-II coin and that is supposed to remain years long. The hybrid system is more secure than the pure PoW or pure PoS. The PoW-II block reward has maximum 50 XMG and minimum 3 XMG, with the same block rewarding adjustment as the PoW-I. Similarly, the optimum diff grows over time.

Wallet v1.1.0.1:

http://cryptomagic.com/files/magi-release/v1.1.0.1/

Github source code: https://github.com/magi-project/magi

[1714257222]

1714257222

[1714257222]

1714257222

[1714257222]

1714257222

[1714257222]

1714257222

[1714257222]

1714257222

[Spexx]

Spexx and MarcusDe, can you help to compile the new miner for windows? Thx

https://github.com/noncepool/m7m-cpuminer-v2

I have a 64 bit minerd.exe compiled for the new algo and am currently testing it via the testnet wallet, since I am unaware of any test pool that may have been setup by Noncepool and/or Suprnova. The hashrate I am getting has averaged out at 31.42 percent of the hashrate I was getting on the current algo and it pleases me greatly that this number bears an uncanny resemblance to pi. Thus, to estimate the hashrate you can expect from your CPU, go to https://ww.cpubenchmark.net/cpu_list.phpw and find your CPU Passmark, divide by 1000 and multiply by pi (3.142). Isn't that wonderful?

This 64 bit minerd.exe is intended for pool mining, but works just fine on the wallet without having to specify the coinbase address for payouts, which is nice. However, it only generates "hashmeter" output when it actually mines a block via the wallet so benchmarking takes time, even on the testnet. If people would kindly tone down their hashrate on the testnet, it would make my job here a little easier . The miner seems pretty solid so far - nothing unexpected has happened with it. 100% compatible with my automine.bat too. I have not run it up on a few other processors yet for proofing, but have little doubt that it will prove good. I have a day off work so it will not be long before I am finished testing, so we should be good to go before the hardfork.

I am not so certain about a 32 bit version - that is my next main task.

[Bombadil]

The expected hashrate using the new algo is 2.545 times less than that with the prior algo.

What about the PoM campaign? I currently only have a 35kh/s cpu, so it will fall below the 30kh/s level. Will you also lower the limit on the PoM minimums?

[joelao95]

Spexx and MarcusDe, can you help to compile the new miner for windows? Thx

https://github.com/noncepool/m7m-cpuminer-v2

I have a 64 bit minerd.exe compiled for the new algo and am currently testing it via the testnet wallet, since I am unaware of any test pool that may have been setup by Noncepool and/or Suprnova. The hashrate I am getting has averaged out at 31.42 percent of the hashrate I was getting on the current algo and it pleases me greatly that this number bears an uncanny resemblance to pi. Thus, to estimate the hashrate you can expect from your CPU, go to https://ww.cpubenchmark.net/cpu_list.phpw and find your CPU Passmark, divide by 1000 and multiply by pi (3.142). Isn't that wonderful?

This 64 bit minerd.exe is intended for pool mining, but works just fine on the wallet without having to specify the coinbase address for payouts, which is nice. However, it only generates "hashmeter" output when it actually mines a block via the wallet so benchmarking takes time, even on the testnet. If people would kindly tone down their hashrate on the testnet, it would make my job here a little easier . The miner seems pretty solid so far - nothing unexpected has happened with it. 100% compatible with my automine.bat too. I have not run it up on a few other processors yet for proofing, but have little doubt that it will prove good. I have a day off work so it will not be long before I am finished testing, so we should be good to go before the hardfork.

I am not so certain about a 32 bit version - that is my next main task.

That's interesting, pi and you won't believe there is a pi in the new algo too.

The 64 bit one is fine. We will need to P2pool to work out direct payout to address. aceoyame, do you have prior experience in setting up p2pool?

[joelao95]

The expected hashrate using the new algo is 2.545 times less than that with the prior algo.

What about the PoM campaign? I currently only have a 35kh/s cpu, so it will fall below the 30kh/s level. Will you also lower the limit on the PoM minimums?

Dont worry about the PoM, hashrate will be automatically lowed by taking into account a factor, so the threshold will be around 10kh/s with the new algo.

[SamWalters]

looking forward to this update. great job!!

[hardfork] - sorry we have a few hardforks to be done and all gonna happen soon

1. M7M-v2 (hardfork on 10/26/2014 9:30:00 AM EST)

A switchover of the mining algorithm to M7M-v2 will occur on 10/26/2014 9:30:00 AM EST. Details about M7M-v2 can be found here: https://bitcointalk.org/index.php?topic=735170.msg9230961#msg9230961. The expected hashrate using the new algo is 2.545 times less than that with the prior algo. To continue with mining, download the new minerd (we will add download links here and in the OP soon), and follow the pool mining guide.

Be sure that you are using the new wallet v1.1.0.1 too.

2. Block rewarding system (hard fork at block 32,750)

A change in the block rewarding system is needed. This won't change the blow rewards, but to be better to comply with the change of hashrate due to the M7M-v2 algo. The new algo leads to less network hashrate; the new block rewards will have maximum value at diff = 0.68 (for low block height); according to hashrate = diff * 2^32/180, that is about 16 Mh/s. We have also made increasing maximum diff with block height, to allow more people mining later on, e.g., optimum hashrate of 27 Mh/s which produces 300XMG at block 40,000.

3. A new difficulty adjustment method - Magi quantum wave (MQW) (hard fork at block 33,500)

Superficially a name here: Magi quantum wave (MQW) (http://en.wikipedia.org/wiki/Wave_function). This adjustment is done by averaging prior 15 block difficulties. A significant different here from other adjustment implementations is that each block difficulty accounted is given a weight, and higher weights are given to more recent blocks; in addition to that, block time is also taken into account. Usually the lower difficulty, the smaller block time. The adjustment algo considers less weight of a block which has the lower difficulty. See details here: https://github.com/magi-project/magi/blob/master/src/main.cpp#L1296

4. Finalizing the PoW-II

As we can see the PoW-I  (will be finished at block 50,000) has produced less coins than expected. To continue the CPU mining, also along with the new algo implementation, it will be very necessary to continue the PoW mining, that will finally make XMG a hybrid PoW/PoS-II coin and that is supposed to remain years long. The hybrid system is more secure than the pure PoW or pure PoS. The PoW-II block reward has maximum 50 XMG and minimum 3 XMG, with the same block rewarding adjustment as the PoW-I. Similarly, the optimum diff grows over time.

Wallet v1.1.0.1:

http://cryptomagic.com/files/magi-release/v1.1.0.1/

[unsoindovo]

hey guys,
any profit calculator for magi???
how many magi/day with win 7 64bit i7 4770?

 thanks!

[The Frisian]

hey guys,
any profit calculator for magi???
how many magi/day with win 7 64bit i7 4770?

 thanks!

25 XMG!  = 1/1000 BTC

[111magic]

Enormously proud of this community!
I've never seen so many developments and cooperation.
It really is exellent to see.
Keep it up.
The marketing side of Magi is working hard to expand the possibilities and the community of XMG.

[YYY888]

Continue to pay attention.So far the development of more smoothly.Just suggest dev cared more about the market development.

[111magic]

Continue to pay attention.So far the development of more smoothly.Just suggest dev cared more about the market development.

Thanks.
Working on that. But the value will probably rise when new goals have been achieved.
It is currently important to work on a larger community.
XMG has already a lot Achieved Within six weeks.
Now is the time to work on expanding opportunities.
 

[Spexx]

hey guys,
any profit calculator for magi???
how many magi/day with win 7 64bit i7 4770?

 thanks!

25 XMG!  = 1/1000 BTC

Interesting estimate. While it would depend on the CPU clock speed to some extent, I would expect this CPU to mine around 50 XMG per day if set up the way I recommend i.e. connected to both mining pools and started as multiple instances of minerd. The machine I use has a processor less than half the speed of an i7 4770 and mines around 20 XMG per day on average with the current algorithm. It remains to be seen how things turn out with the new algorithm. The block reward system makes the actual mining returns very variable and depends very much on the total network hashrate, so any profit calculator would have a hard time giving you an accurate figure. XMG is rather unique!

[qiwoman2]

It's great to see a coin that is working for a long period. Kudos to the Team and Community. 

[joelao95]

Continue to pay attention.So far the development of more smoothly.Just suggest dev cared more about the market development.

We have few persons working on the marketing inside and outside bitcointalk, and I also keep talking to exchanges about XMG. We will give more details. Any suggestions/helps to the marketing will be appreciated.

hey guys,
any profit calculator for magi???
how many magi/day with win 7 64bit i7 4770?

 thanks!

25 XMG!  = 1/1000 BTC

Interesting estimate. While it would depend on the CPU clock speed to some extent, I would expect this CPU to mine around 50 XMG per day if set up the way I recommend i.e. connected to both mining pools and started as multiple instances of minerd. The machine I use has a processor less than half the speed of an i7 4770 and mines around 20 XMG per day on average with the current algorithm. It remains to be seen how things turn out with the new algorithm. The block reward system makes the actual mining returns very variable and depends very much on the total network hashrate, so any profit calculator would have a hard time giving you an accurate figure. XMG is rather unique!

It will be difficult to calculate XMG mining based on a calculator. The block rewards are determined by the network difficulty which is in turn affected by the amount of hash rate people have. Calculating a rough close number will be possible though. To help difficulty stabilizing we will have a new diff adjustment method - MQW, to avoid the large variation, and hence the big holes of rewards. These lucky rewards seem like incentive to mining, but somehow are beyond expectation. The variation is not because of actual varying hashrate, but rather a self-adjustment of the block chain. With the actual constant mining hash, this variation will be a type of oscillation. Similar behavior can be found in the PoS diff. Stabilizing the difficulty absolutely benefits equal block time. The MQW operates like moving average, but does a better job on averaging difficulty at rising side which emphasizes tendency of higher weight on the recent hash variation in the network (really pulled my hair out to deal with this complication).

Given more stable difficulty should make the calculation further accurate; either way practice is mining it a day or two and don't forget the PoM (https://bitcointalk.org/index.php?topic=802681.0).

[aceoyame]

spexx miner work fine for me. i am BUSTING the hash. cheers spexx!

Not sure how, supposedly it's using the generic miner. have you tried the previous one with the right feature set for your CPU?

Yes it is using the generic 64 bit Windows miner, which works on any 64 bit CPU running Windows 7 SP1 or higher, Windows Server 2008 SP1 or higher for best results. The miner is compiled from the code provided by Noncepool and the source can be found at:-
https://github.com/noncepool/m7magi-cpuminer
The compiled minerd.exe might be called "generic" but that does not mean that it is an under-performer. As I understand it, the compiled code contains multiple program streams to support a range of CPU architectures and instruction sets, which simply means that the executable file is much larger than any version compiled for a specific CPU.

According to my benchmarks, the generic miner compiled (by me) under Cygwin, when run according to my advices i.e. starting multiple instances of minerd with a single thread, as opposed to a single instance of minerd with multiple threads, runs at a higher hashrate than any of the processor-specific miners EXCEPT the one for Intel Haswell class processors, where that one has the edge by 4 percent. I should admit that the idea of running multiple instances of minerd instead of multiple threads was not my original idea, but something I picked up on that was posted here by somebody else. There is a wealth of information to be found in this forum, but I do appreciate that nobody is going to read through the whole lot of it (or even understand a lot of it) so I created automine.bat et al to try and make it easy for people to get their wallet and miner setup just right for best performance.

Anybody having trouble just running up automine.bat is kindly asked to specify the problem they have with it. I cannot assist or begin to diagnose the problem without information about the hardware/software environment and the error messages you are getting. Certainly every machine I tried the package on worked first time and others have it working too. The one person who reported their problem precisely (i.e. it didn't support 40 processors) was provided with a patched version within minutes of me seeing their post. What more am I expected to do? It is no use just sitting there, arms folded with a stern expression on your face, saying it doesn't work. Is it plugged in? Is it switched on? Is it online? Has it got paper in it? Has it got ink/toner in it? Did you mess with it? I can't see what you are seeing and I'm not making housecalls

There was a good reason for having the default behavior of automine.bat to open multiple windows and it is easy to change that behavior via Setup.bat, or you could also run automine.bat with parameters - parameter 8 controls that behavior and is fully documented in the file header if you take a look at the code.  There is also a good reason for every question asked by Setup.bat and in fact, depending on what type of mode you choose to operate, it will skip certain questions anyway. For example, if you are setting up mining with the wallet on the same computer AND have just completed the section to set up the magi.conf file, it will not ask you for the rpcuser, rpcpassword and rpcport again - it will take the info you just provided (or the defaults if that was what you selected). If you are very experienced with mining under Windows, you must surely see the sense of every question. Every question includes explanatory text and suggests a default. One thing that it does not ask about is whether you are mining via a proxy. If you have to do that, you will have to edit the file failover.bat manually and this is documented in the read.me file. There are various proxies that work in different ways and I did not want to open that can of worms.

Setup.bat does not ask for a pool username. It asks for a pool login name, worker name and worker password, all of which are required to construct the correct minerd.exe command line e.g. --user loginname.workername --pass workerpassword so your gripe there is noncense old boy (yes I deliberately mis-spelled that) Maybe you are attempting to be too clever with it? It was designed to be mostly foolproof, not geniusproof.

The package included cpuz (four files) because I had it lying around. It is not required as such. Take it or leave it, or delete it - it's irrelevant. Maybe I will leave it out of the next package if it is so annoying. Every other file is required. Maybe having a large number of required dll files does not look good, but who said it had to look pretty? The new algo coming up requires one more dll file.

Finally, If you want to use another minerd.exe version, go right ahead with my blessings. I have tested and benchmarked all of them. If you try it on its own with multiple threads, benchmark it, then try it again using automine.bat as a "wrapper" instead you might just find an improvement in hashrate. That was my finding.

Still not sure why my pool login is needed. Stratum only requires Pool URL, Pool worker name and worker password.

Also, the generic miner if I recall only utilizes SSE2 and no further instruction sets. I strongly suggest removing the requirement for Pool login name and compiling multiple versions of your miner and then include logic to detect the instruction sets the cpu supports. I can assist with that. Also you can move the files into a subfolder. As it stands it is just a giant mess and hard to make work.

I can assist with rewriting it to be simpler\making it more user friendly. I even have a way to have you have your multiple instances vs multiple threads run silent as well as including a script to kill the silent tasks in the background.

As for why multiple instances runs faster than multiple threads that tells me the thread management in minerd is pretty shitty and that windows' built in thread scheduling is more efficient.

[joelao95]

It's great to see a coin that is working for a long period. Kudos to the Team and Community. 

Thanks Ellie, can't wait to see promo from your experienced skills in the area, and I wish this will be further advancing of our marketing role in XMG later on.

[joelao95]

Still not sure why my pool login is needed. Stratum only requires Pool URL, Pool worker name and worker password.

Also, the generic miner if I recall only utilizes SSE2 and no further instruction sets. I strongly suggest removing the requirement for Pool login name and compiling multiple versions of your miner and then include logic to detect the instruction sets the cpu supports. I can assist with that. Also you can move the files into a subfolder. As it stands it is just a giant mess and hard to make work.

I can assist with rewriting it to be simpler\making it more user friendly. I even have a way to have you have your multiple instances vs multiple threads run silent as well as including a script to kill the silent tasks in the background.

As for why multiple instances runs faster than multiple threads that tells me the thread management in minerd is pretty shitty and that windows' built in thread scheduling is more efficient.

aceoyame, here is the new miner. Hope you can give the compilation a try; multiple thread thing might be about windows, as it works well on linux. I am keen to see different versions of compilations and comparisons among them.

https://github.com/noncepool/m7m-cpuminer-v2

[Spexx]

multiple thread thing might be about windows, as it works well on linux.

That's it precisely. The problem with multiple threads seems to be unique to Windows 64 bit and appears to be something to do with processor scheduling of posix threads. From my researches into this, it would appear that if the source code used boost-threads instead of pthreads then the problem would go away. However, I am no expert on such things and I have a workaround anyway so there is really no need to re-write the code and install additional compiler libraries to support boost-threads.

[aceoyame]

multiple thread thing might be about windows, as it works well on linux.

That's it precisely. The problem with multiple threads seems to be unique to Windows 64 bit and appears to be something to do with processor scheduling of posix threads. From my researches into this, it would appear that if the source code used boost-threads instead of pthreads then the problem would go away. However, I am no expert on such things and I have a workaround anyway so there is really no need to re-write the code and install additional compiler libraries to support boost-threads.

If you have a workaround though then what we can do is simply include my scripts to make the multiple windows silent except for the one with output and upon termination it closes all the processes.

It's kinda easy to make work, I have something similar in simplicity although I didn't think to automate process termination. As it stands for mine everything is silent and to close you have to run another script. It's not terrible though.

I guess my biggest concern is that it appears your miner was meant to be made as user friendly as possible but if I can't get it to run, odds are most other people can't either. I don't mind working to help rewrite this with VBS. Batch scripting is a lot harder to read when it's as lengthy and formatted as yours. Batch scripting also doesn't have as many features either. For instance you can't utilize WMI whereas I can with VBS.

The biggest problem with ease of use right now is definitely in how you are authenticating with stratum. For the life of me I cannot get it to authenticate.

[Spexx]

Still not sure why my pool login is needed. Stratum only requires Pool URL, Pool worker name and worker password.

If you say so, but that is at variance with the instructions provided by Noncepool and Suprnova.

http://magi.nonce-pool.com/index.php?page=gettingstarted
https://xmg.suprnova.cc/index.php?page=gettingstarted

Also, the generic miner if I recall only utilizes SSE2 and no further instruction sets.

Nope and you have not done your homework. It supports AVX, AVX2 and XOP provided that the CPU and operating system support them. Take a look at the documentation provided with the source code at https://github.com/noncepool/m7magi-cpuminer and then re-read what I said earlier about CPU architectures and instruction sets. I have done my homework.

I can assist with rewriting it to be simpler\making it more user friendly. I even have a way to have you have your multiple instances vs multiple threads run silent as well as including a script to kill the silent tasks in the background.

Go right ahead. I had a few ideas myself about bundling the whole thing up, but also have a life with other things to do in my spare time. What I have works fine on everything I tried it on, so anything more is window-dressing imho. You still have not specified what your problem was at runtime with automine.bat and neither has the other person who said "it doesn't work".

As for why multiple instances runs faster than multiple threads that tells me the thread management in minerd is pretty shitty and that windows' built in thread scheduling is more efficient.

The problem is not really the fault of the minerd code. It runs fine under Linux, which is what it was developed for. The fault is more to do with the Cygwin compiler for 64 bit Windows and its iimitations with handling pthreads. The 32 bit Windows version does not exhibit the problem, but is very much slower as it does not support the more advanced instruction sets. 64 bit versions compiled using Msys/Mingw64 do not exhibit the problem as much as Cygwin, but still benefit from being started as multiple instances. Personally, I find that I can't get Mingw64 to install (it appears to be broken and all I get is an error message that says "res: ERROR" which is useless) and Mingw32 is a complete pain that needs libcurl shoe-horned into it with nothing being easy and straightforward. Mingw is such a pain in the butt that I have wasted more than enough of my spare time with it now and have abandoned it permanently. Now while I was writing this, I just successfully compiled a 32 bit Cygwin version of minerd with the new algorithm and will now go and test it.