win32? how about win64? seems will be like instamine...))

Sorry dev, is this coin minable with gpu???

"minerd --url http://127.0.0.1:8232 --user rpcuser --pass rpcpass --threads 1"


rpcuser = my wallet adress?
http://127.0.0.1:8232 = localhost? --> solomining?

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

I'm asking the same question over and over... no answer

debian live 7.2  where can I find the package that contains gmp header?

checking for openssl/evp.h... yes
checking for SSL_library_init in -lssl... yes
checking for EVP_DigestFinal_ex in -lcrypto... yes
checking gmp.h usability... no
checking gmp.h presence... no
checking for gmp.h... no
configure: error: gmp headers missing
root@debian:~/magi-minerd#

Could you please plus 2 hours, it will be the good time for people around the world.

Thanks.

my friend use AMD cpu can open wallet
INTEL can't!!!

how to build magic miner of sources on linux debian wheezy 7.3

./autogen.sh
CFLAGS="-O3 -march=native -mtune=native" CXXFLAGS="-O3 -march=native -mtune=native" ./configure
make

sudo apt-get install gfortran

Win wallet does not start
libgfortran-3.dll missing

Can someone compile CPU miner?

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

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

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

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

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

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...