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

[paulthetafy]

Thanks for the response Joe.  I've had limited contact with OpenCL and none at all with CUDA, so will admit I'm not in a position to comment with any authority on your assumptions. But I do know that other algorithms implemented on the GPU that had to move some processing out to the CPU (such as XPM's early GPU miner) came to the same conclusion... It is inefficient to have have to keep switching context and processing out to the CPU and back.  So on that basis alone your assumption that multiple repetitions should mean disproportionately slower performance of GPU mining seems sound.

So is there anything left that needs fixing/testing before launch?

[1714257091]

1714257091

[1714257091]

1714257091

[1714257091]

1714257091

[joelao95]

As mentioned before, XMG won't advertise it as a solution to cpu-only mining (hope it is), "but here going forward, we believe this is a beginning, based on the efforts undertaking." Therefore, I do hope all can comment, probably somewhere in the near future, if XMG can't prove its cpu algo, there will be a coin which picks ideas from here, just like we picked M7.

[joelao95]

Thanks for the response Joe.  I've had limited contact with OpenCL and none at all with CUDA, so will admit I'm not in a position to comment with any authority on your assumptions. But I do know that other algorithms implemented on the GPU that had to move some processing out to the CPU (such as XPM's early GPU miner) came to the same conclusion... It is inefficient to have have to keep switching context and processing out to the CPU and back.  So on that basis alone your assumption that multiple repetitions should mean disproportionately slower performance of GPU mining seems sound.

So is there anything left that needs fixing/testing before launch?

Thanks; I am preparing stuffs to initiate the launch.

[xx63245613]

where is the wallet and the miner?

[crypto_currency]

no win wallet,instamined?Is that what you so-called fair distr?

[paulthetafy]

no win wallet,instamined?Is that what you so-called fair distr?

Don't spread FUD.  The wallets are being worked on.  Until a genuine windows wallet is completed, windows users can very easily use the Linux wallet via Cygwin.  There is no instamine here, only a swap for the the old coin. 

[luckykitty]

So where are the WIN wallet and miner?

[djm34]

[A quick survey]

I've literally manipulated multiplication and division of hashes, which can be repeated any many times as desired. The more repeating, the lower hash rate, which also means less probable of GPU miner as I understand. Only deficiency is the less hash rate making hashing being hard. Let me know if you have any concerns or have something in mind.

I would personally suggest to continue the "repeating", to lower the probability of GPU mining being possible. Then, this would be a true "CPU-only" coin

My testing in my AMD cpu (8 core)  shows 500 khps hash rate for pure M7; and it was down to half, when I add an extra fortran subroutines; and then repeats of multiplication and division lead to nearly tens of hps depressing per repeat. I feel not very good to keep repeating once we reach very small hash. Ref.: mining the scrypt coin with my AMD gives 10 khps.

Well, you should (not feel good about that) because this is just plain stupid... You are just making your coin hard to mine (but not especially on gpu...).
but it is your right to listen to moron (who will not mine the coin or with big botnet and big server) basically you are just shutting down the coin to many.

"Hard to mine" is relative to difficulty, so you will get the same mining reward regardless of how low your hashing speed is, as everyone has to do the same work, so difficulty will just be lower.  So stop throwing accusations of stupidity when clearly you don't understand how mining works at all.

Of course this is also true of gpu miners. Joe, can you confirm that repeating the functions is making it DISPROPORTIONATELY harder for gpu over CPU? If so, then your target should be as many repetitions to ensure that an average gpu will always be slower than an average CPU. Thus you're not guaranteeing that this would be CPU only, but you would have ensured that mining with gpu would not adventagous. If it is not going to be disproportionately harder for gpu with every repetition, then it's pointless repeating it

It is very clear to me, that dev doesn't have a gpu miner to compare with... so all this is just guessing (based on an idea, m7, which has been already proven wrong in the first place).
So let add more divisions, more steps is (sorry to reiterate) just stupid because no comparison has been done.
So for the moment he is just decreasing cpu hashrate expecting gpu will decrease faster... (may-be you just learn a little bit more about gpu yourself)

Blind faith in action is nice to watch but it hurts any normal brains at the same time...
and some point, just stick with what have rather than changing every hours...

Hi djm, would you please take a look at the algo and then write your comments?! Please just don't attack a simple thought, sometimes simple thoughts could lead to something. I am unaware of any significant algo, please tell me which is a good one you have in mind since you don't believe in M7. I cannot compare with gpu, because no idea how to implement gpu in this case, that's why I ask you to take a look since you are more experienced than me in this regard. Simply let's see what's happening after launch, rather than wording game. If someone likes to implement gpu, let's see how he is doing.

p.s., the algo is just a portion of this coin project, not whole; no significant points being forged here, let's just move on.

I never say that I didn't believed in m7 (I am running a lot on it... with my gpus).
But the multiplication on that algo are a lot less hard than what was expected at first (and we arren't using any fast multiplication algo... just standard schoolbook multiplication algo with some part written in asm to speed up things...
(I assume nothing change since yesterday):
What I don't like in your algo is the fortran routine because calculation are made with real number and this may cause rounding problem accross platform (hopefully I am wrong) when the number are converted back to integer, meaning if the rounding is a bit different one one platform it could be impossible to validate the hash.... so it is a step I really don't like.

Anywhay the result of the spectral weight is multiplied to the 8th hash (which is the sum of the 7 previous hash).
I don't know the way it is done as you don't keep any number greater than u512 in your calculation, but that's ok. so why not

Then you multiply that by the Spectral weight then divide the result of the multiplication by the result of the previous operation. which should be roughly (I didn't check in detail) 38*64bit/512bit operation.
In that part the spectral weight seems to me useless (except as an attempt to slow down things, but by itself it has no purpose. The division between the product and hash[7] should have been enough.  (and this part will slow the gpu more than the spectral stuff).

then  sha256 of the resulting hash....

 again the spectral stuff applied to the resulting hash (this I don't understand this at all..., it doesn't slow down anything, since it has been already calculated

then again the quotient of the fisrt division is divided again by spectral*hash of sha256   then re-sha256 and it is over...

I think it is long enough like that and I don't see the interest in bringing the spectral_weight at all (and even less using it a second time).

That's about it, and I am not sure I answered your question...

[IMJim]

uhhm, when did we start speaking Martian in here:-)

[djm34]

uhhm, when did we start speaking Martian in here:-)

that's change a bit from Klingon (or troll language) 

[paulthetafy]

So where are the WIN wallet and miner?

None of them have been released yet.  The coin hasn't launched, it was delayed.

[joelao95]

I never say that I didn't believed in m7 (I am running a lot on it... with my gpus).
But the multiplication on that algo are a lot less hard than what was expected at first (and we arren't using any fast multiplication algo... just standard schoolbook multiplication algo with some part written in asm to speed up things...
(I assume nothing change since yesterday):
What I don't like in your algo is the fortran routine because calculation are made with real number and this may cause rounding problem accross platform (hopefully I am wrong) when the number are converted back to integer, meaning if the rounding is a bit different one one platform it could be impossible to validate the hash.... so it is a step I really don't like.

Anywhay the result of the spectral weight is multiplied to the 8th hash (which is the sum of the 7 previous hash).
I don't know the way it is done as you don't keep any number greater than u512 in your calculation, but that's ok. so why not

Then you multiply that by the Spectral weight then divide the result of the multiplication by the result of the previous operation. which should be roughly (I didn't check in detail) 38*64bit/512bit operation.
In that part the spectral weight seems to me useless (except as an attempt to slow down things, but by itself it has no purpose. The division between the product and hash[7] should have been enough.  (and this part will slow the gpu more than the spectral stuff).

then  sha256 of the resulting hash....

 again the spectral stuff applied to the resulting hash (this I don't understand this at all..., it doesn't slow down anything, since it has been already calculated

then again the quotient of the fisrt division is divided again by spectral*hash of sha256   then re-sha256 and it is over...

I think it is long enough like that and I don't see the interest in bringing the spectral_weight at all (and even less using it a second time).

That's about it, and I am not sure I answered your question...

Thanks, djm, for taking time to look though the algo. Anyway we will carry on with this and see what's happening. Though pretty much meaningless stuffs, I hope this would be better than solely a copy of M7 (if any), and hope people can see the tiny idea behind these superficially bunch of functions, being incentive leading to something else.

[workminer]

tomorrow is 15 or 16 sep?

[joelao95]

[Test miner & Launch time]

Windows standalone miner (thanks TestZ):
https://www.dropbox.com/s/68shi3is0mw5rbw/magi-minerd-win32-v2.zip?dl=0
http://cryptomagic.com/files/magi-minerd/magi-minerd-win32-v2.zip

https://bitcointalk.org/index.php?topic=735170.msg8824996#msg8824996
Linux minerd available here: http://cryptomagic.com/files/magi-minerd/
Source code: https://github.com/magi-project/magi-minerd

To test the miners, download the testnet wallet:
http://cryptomagic.com/files/magi-release/testnet/

Instructions to set up testnet: Edit magi.conf. This file should be in the folder: %appdata%\magi (windows) or ~/.magi (linux); with following contents:

Code:

testnet=1
rpcport=19232
daemon=1
server=1
rpcallowip=127.0.0.1
rpcuser=rpcuser
rpcpassword=rpcpass

NOTE: They only work on the testnet.

If you cannot run the linux wallet and minerd,

Code:

chomd 755 file-to-be-run

Command line to run minerd looks like this

Code:

minerd.exe --url http://127.0.0.1:19232 --user rpcuser --pass rpcpass --threads 1

Code:

./minerd --url http://127.0.0.1:19232 --user rpcuser --pass rpcpass --threads 1

Notice user and pass should match with magi.con

[joelao95]

[CPU miner windows how-to - Cygwin]

Download cpuminer source code and compile:
https://github.com/noncepool/m7m-cpuminer (pool mining)
https://github.com/magi-project/magi-minerd (solo mining)

The following guide is for compiling though cygwin in windows. testz did the standalone windows compilation before, I will ask him again for help.

1) Compile cpuminer in cygwin
Download setup-x86_64.exe (or setup-x86_32.exe) from the first page of https://www.cygwin.com, and then install it; installation asks for installing packages, be sure following are checked:

Code:

devel/git
devel/gcc-g++
devel/gcc-fortran
libs/libcurl-devel
devel/automake
devel/make
net/openssl-devel
math/libgmp-devel
editors/nano

2) Open up Cygwin64 Terminal, issue following commands

Code:

git clone https://github.com/magi-project/magi-minerd
cd magi-minerd
./autogen.sh
CFLAGS="-O3 -march=native -mtune=native" CXXFLAGS="-O3 -march=native -mtune=native" ./configure
make

The compiled minerd lies in C:\cygwin64\home\USER\magi-minerd; Cygwin is a unix environment, so you have run the miner through console.

3) Solo mining

Code:

./minerd.exe --url http://127.0.0.1:8232 --user rpcuser --pass rpcpass --threads <number of threads>

8232 is rpcport, rpcuser and rpcpass are user and password you set in magi.conf
set <number of threads> to a number, matching with the threads of your needs.

4) Pool mining
Typical command

Code:

./minerd.exe -o stratum+tcp://pool:port -u <username> -p <password> -t <number of threads>

Exampe,
Nonce-pool:

Code:

./minerd.exe -o stratum+tcp://mine2.magi.nonce-pool.com:4090 -u <username> -p <password> -t <number of threads>

Suprnova pool:

Code:

./minerd.exe -o stratum+tcp://xmg.suprnova.cc:7127 -u <username> -p <password> -t <number of threads>

set <username> and <password> which should match with your setup in the pool; go to pool site for detail information.

You can use following scrypt file; if you don't know how, simple run from above command line:

Code:

nano magi-minerd.sh

Edit and save it; magi-minerd.sh is a file coming with the git source. Issue

Code:

./magi-minerd.sh

If you cannot run it,

Code:

chmod 755 magi-minerd.sh

That's it!

[Shadow_Runner]

Can someone compile CPU miner?

[joelao95]

How to run minerd (pool and solo mining)

Please use the binary compiled from Wolf's optimized miner (V2); for downloads see links in OP. The old miners are placed at the end of this post.

Pool mining is suggested

1. Pool mining
1) Download minerd, e.g., http://graymines.net/miners/magi/cpuminer_win64_magi_byMarcusDe-generic.zip

2) Run minerd (following examples for Windows; for linux, using./minerd instead of minerd.exe)

Code:

minerd.exe -o stratum+tcp://pool:port -u <username> -p <password> -t <number of threads>

Exampe,
Nonce-pool:

Code:

minerd.exe -o stratum+tcp://mine2.magi.nonce-pool.com:4090 -u <username> -p <password> -t <number of threads>

Suprnova pool:

Code:

minerd.exe -o stratum+tcp://xmg.suprnova.cc:7127 -u <username> -p <password> -t <number of threads>

set <username> and <password> which should match with your setup in the pool; go to pool site for detail information. minerd.exe should be run from DOS command line, or ./minerd from linux terminal (details see VPS mining guide)

2. Solo mining
1) Create a conf file which should be in the folder: ~/.magi (linux) or %appdata%\magi (windows)
(magi.conf is not necessary, unless you will sole mine; use more complicated pass as you like)

daemon=1
server=1
rpcport=8232
rpcallowip=127.0.0.1
rpcuser=rpcuser
rpcpassword=rpcpass

2) Run minerd

Code:

minerd.exe --url http://127.0.0.1:8232 --user rpcuser --pass rpcpass --threads <number of threads>

8232 is rpcport, rpcuser and rpcpass are user and password you set in magi.conf
set <number of threads> to a number, matching with the threads of your needs.

         1. The original minerd
           Spexx's package - Original post, Release 12/03/2014, Release 11/02/2014, Speed controller ; Files hosted on coinmagi.org
           MarcusDe's package - Dowload, Guide, Generic miner; Files hosted on coinmagi.org

          2. Wolf's optimized miner (source code)
           Download from sourceforge

[opossum]

Win wallet does not start
libgfortran-3.dll missing

[joelao95]

Can someone compile CPU miner?

testz did the standalone windows compilation before, I will ask him again for help.

[joelao95]

Win wallet does not start
libgfortran-3.dll missing

I uploaded here: http://cryptomagic.com/files/magi-release/DLL/

My system have all installed, so I don't know which of those are needed. Can you try and tell me the necessary DLL files?