I compiled a Mac version of dga's miner, you can find it here: http://riecoin.biz/xptminer-macI used the latest github but it prints b11, and compiled using OSX 10.8.5, please test it and let me know how it works. Looks like we'll have OSX versions for the next version of the wallets ("Riecoin core")! It has a default developer fee of 2%, half for dga and half for me |
|
|
|
I think this would be a nice time to update dev.  When prices are still dropping. Still working on cpuminers and on new client version. I want to include all changes from bitcoin 0.9.0 plus continuous difficulty adjustments, but I have to be very carefull no to mess up anything. I guess it's a good time to buy... |
|
|
|
any pool?
My pool will launch in a few more hours. It is deployed on a high performance cluster in multiple datacenters so it should be quite fast and resistant to attacks. In order to mine with me you will need any miner that supports the stratum protocol such as the main riecoin miner linked on the first post: https://bitcointalk.org/index.php?topic=446703.msg4912512#msg4912512Dave (dga) has been so kind as to open source his very fast mining client but it does not support stratum. Please encourage gatra to pull Dave's optimizations into the default miner or someone else to add stratum to Dave's miner. Right now a single pool controls the Riecoin network with over 90% of the computing power. Riecoin will become much more valuable to all of us once other pools come online to distribute the power. I'm looking at dga's code and trying to understand it in order to decide if it's better to add his optimizations to my miner or to add stratum support to his...... |
|
|
|
@gatra and @northranger79510:
Was the main technical PoW explanation removed from riecoin.org? I was about to reference it. Think it used to be after "What is new about Riecoin" and before "How is Riecoin different from Primecoin"
You're right, I thought it was there but I couldn't find it on the new site. We need to add this back asap! In the mean time, you can still find it in the old site here: http://riecoin.biz/ |
|
|
|
Hi riecoiners! Update for last week: So we are heading towards a more decentralized and healthy network, and closer to the prime 6tuple world record! Riecoin should take off soon. My current priorities: - Bitcoin core 0.9.0 is out and now I have a lot of new features to add to RIC. Expect new "Riecoin Core" versions. Looks like we'll have a 64bit version for windows: this will make PoW verification much faster
- I'm working on an optimized open source version of the miners. Stratum first, then xpt.
- After latest difficulty swings, I'm considering switching to a constant difficulty adjusment instead of every 288 blocks.
Thanks and regards, gatra |
|
|
|
im trying to compile miner in windows under mingw, and i got error:
In file included from d:\mingw\include\curl\curlbuild.h:124:0,
from d:\mingw\include\curl\curl.h:34,
from cpu-miner.c:38:
d:\mingw\include\ws2tcpip.h:38:2: error: #error "ws2tcpip.h is not compatible wi
th winsock.h. Include winsock2.h instead."
#error "ws2tcpip.h is not compatible with winsock.h. Include winsock2.h instead
."
^
In file included from d:\mingw\include\curl\curlbuild.h:124:0,
from d:\mingw\include\curl\curl.h:34,
from cpu-miner.c:38:
d:\mingw\include\ws2tcpip.h:147:8: error: redefinition of 'struct ip_mreq'
struct ip_mreq {
^
In file included from d:\mingw\include\windows.h:93:0,
from cpu-miner.c:24:
d:\mingw\include\winsock.h:315:8: note: originally defined here
struct ip_mreq {
^
make[2]: *** [rminerd-cpu-miner.o] Error 1
make[2]: Leaving directory `/d/Mingw/cpuminer-rminerd-master'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/d/Mingw/cpuminer-rminerd-master'
make: *** [all] Error 2
anyone can help with that?
looks like a problem in curl and not in the miner, my guess is that you have a mingw installation problem |
|
|
|
Since ypool has most of the hashing power and this is not good i want to mine in other pool.
But is there any other stable pool? Which? And how much less income do you expect to have in other pool?
income depends on the fee of the pool why would you expect less income? http://ric.upcpu.com/ already has 4 blocks |
|
|
|
YAY, more CRLF/CR/LF/Encoding/whatever bullshit... I give up. Please provide some unmangled sourcecode or at the very least, a 32 bit linux build.
I had faith in this coin from launch but it's just been a disappointment to me. Missed the boat due to, seemingly, dev's that take cross platform code, change a line or two (aka/ie, a new coin), and completely fuck up all code portability. Seems like there's only a handful of actual developers in the cryptocurrency community that know what cross-platform/portable means.
If you have sympathy or pity this fool, RAvAQ3TrUNWrG2DDgfuPvdhzaiXtg2wjEu
I'll pay with knowledge... Install dos2unix or 'sed -e "s/^M$//"' (you'll need to ^V ^M to get the right string). I understand that not everyone can code or can navigate a unix-ish CLI but is that the fault of a dev? PS. My Verilog sucks but I don't blame the *coin ASIC miners for that. -- bsunau7 heh, I actually did try dos2unix among other sed/perl/python/etc one-liners but all failed due to not mangling the sourcecode even further (and all in different ways, which I think backs up my higgledy-piggledy theory of encoding) But as for the last I error I got fatal error: gmp.h: No such file or director That actually seems to be unrelated to the line termination/encoding issues. Stuck for a fix though (installed all lib-devs that look relevant, no joy) I understand that not everyone can code or can navigate a unix-ish CLI but is that the fault of a dev?
Navigating a CLI? No, but forking opersource crosspatform software and messing up one or both of those main features (yes, they are main features) is the fault of the/a dev The gmp.h error is because you a are missing one of the dependencies: gmp (package libgmp-dev or you can get it from http://gmplib.org/ as stated in the README file) Yes, it's possible that I messed up the CR/LF, I edited the files in some crappy windows editor and it changed my line endings. |
|
|
|
I guess we can easily get many such 32-bit numbers, without obtaining them from true prime sextuplets... ??
sure! you pick numbers that would form a valid 6tuple modulo each prime and then use the Chinese Remainder Theorem to get your remainder modulo your primorial (for example 1 mod 2, and 1 mod 3 gives you 1 mod 6). When numbers get larger, you'll have to do some trial and error in order to have your number fit in 32bits |
|
|
|
I just added RieCoin to our pool and would love some help testing it please ? www.altcoinspool.comThanks. Alt. please have in mind that algo is not scrypt as your site puts |
|
|
|
ric.upcpu.com is also open for testing They use xpt insted of stratum, so the optimized miners for ypool should work on the upcpu pool too how do I transfer RIC coin into the wallet? xptMiner.exe -o ricpool.upcpu.com -u RCeZfFMVsJqkeZi21w8j3U8mUhwzDW2T99.worker -p x -t 8 or xptMiner.exe -o ricpool.upcpu.com -u RCeZfFMVsJqkeZi21w8j3U8mUhwzDW2T99 -p x -t 8 which one is correct? in upcpu I think the former is valid just make sure RCeZfFMVsJqkeZi21w8j3U8mUhwzDW2T99 is your address and you'll receive payouts there |
|
|
|
^^ I would assume the latter.
Can anyone provide an equation for calculating the estimated 4-chains required to find a 6-chain and thus mine a block?
it's possible but kinda tricky, one of the variables is how many primes you put in your sieve. Will think about it |
|
|
|
Following up on my earlier tracing of offsets and difficulty, here's a new graph: http://www.cs.cmu.edu/~dga/crypto/ric/diff_offset_2014_03_18.pngLooks like within a few days, the low-primorial miners will mostly be gone. Supercomputing alluded to this, but I think it'll be interesting to see what happens with coprimes (offsets relative to the primorial) other than the first. The ypool miner and mine both use only the first (+97 for 2310, and +16057 for big primorials). But a00k's uses a different coprime for each worker. I'm not sure I see a fundamental advantage to using the coprimes unless we start exhausting the 256 bit nonce space with large primorials and need to search more densely, but it seems like something to keep in mind. I'll see if I can add a coprime-detector to my analysis code for some graphs next week. That should also provide a better signature of the miner used to mine the block - interesting stuff. All these primorial optimizations are assuming that all 'coprimes' as you say (I'm not sure it's the correct term, I'd call them 'remainders' since they are the remainder of the first prime of the sextuplet modulo the primorial) are equiprobable (ie sextuplets are distributed evenly amongst different remainders). It's logical to assume that, but I think it's not proven to be true. Some may give better performance than others - and it could be a big difference. The safest approach would be to choose one at random and switch every few minutes or something. And of course the best would be to research if they are truly the same or not. Some of you people thought your were mining this for the money? while you were distracted, I made you do science! ha! *grin* Sorry - coprimes was a00k's term, I call them offsets, but remainders is probably better. Oh, I'm in this for the fun. Would be interesting to know if we could embed more information in the block to help do that study more to be able to tease apart miner popularity/performance/probabilities. Cool idea, it would be impossible to enforce or to avoid some miners lying, but those would be a minority - if any. We could have some standard way to store that in the coinbase transaction, but it wouldn't work for miners that use "getwork"... let's think about it. Another thing: different remainders or offsets would be a good way to implement threading, better than dividing the nonce space as rminerd does. |
|
|
|
math is most definitely not science oh, come on... I can be a pedantic dick too: acccording to wikipedia Carl Friedrich Gauss (1777–1855) referred to mathematics as "the Queen of the Sciences".[13] Benjamin Peirce (1809–1880) called mathematics "the science that draws necessary conclusions" here at UBA, Math shares the same building with Physics and Computer Science at the Faculty of Exact Sciences Now you could say that Computer Science is most definitely not science... but I'd pretend I didn't hear |
|
|
|
Following up on my earlier tracing of offsets and difficulty, here's a new graph: http://www.cs.cmu.edu/~dga/crypto/ric/diff_offset_2014_03_18.pngLooks like within a few days, the low-primorial miners will mostly be gone. Supercomputing alluded to this, but I think it'll be interesting to see what happens with coprimes (offsets relative to the primorial) other than the first. The ypool miner and mine both use only the first (+97 for 2310, and +16057 for big primorials). But a00k's uses a different coprime for each worker. I'm not sure I see a fundamental advantage to using the coprimes unless we start exhausting the 256 bit nonce space with large primorials and need to search more densely, but it seems like something to keep in mind. I'll see if I can add a coprime-detector to my analysis code for some graphs next week. That should also provide a better signature of the miner used to mine the block - interesting stuff. All these primorial optimizations are assuming that all 'coprimes' as you say (I'm not sure it's the correct term, I'd call them 'remainders' since they are the remainder of the first prime of the sextuplet modulo the primorial) are equiprobable (ie sextuplets are distributed evenly amongst different remainders). It's logical to assume that, but I think it's not proven to be true. Some may give better performance than others - and it could be a big difference. The safest approach would be to choose one at random and switch every few minutes or something. And of course the best would be to research if they are truly the same or not. Some of you people thought your were mining this for the money? while you were distracted, I made you do science! ha! |
|
|
|
ric.upcpu.com is also open for testing They use xpt insted of stratum, so the optimized miners for ypool should work on the upcpu pool too
|
|
|
|
OK, thanks for the help Workers will be banned for 30 seconds if they submit more than 50% invalid shares. So please update :-) high difficulty is hard! just got 1 share at your pool [2014-03-18 16:42:31] accepted: 1/1 (100.00%), 2446513 khash/s (yay!!!) gotta go now. Miner and pool seem ok, so later I'll release binaries of the latest miner at github and then I'll start to implement the optimization. |
|
|
|
2014-03-18 15:24:30,137 DEBUG mining # Worker invalid percent: 100.00 stox.worker_rie1 STILL BANNED!
What does banning do? Will this worker be unbanned if it submits a valid share? Most workers will be banned, 95% of shares submitted are deemed invalid by stratum-mining. you should get people to use the latest miner, I had 99%+ accepted (testnet) I don't know how unbanning works, that's a question for ahmed_bodi I guess, but I can investigate. You have these settings in config.py # ******************** Worker Ban Options *********************
ENABLE_WORKER_BANNING = True # Enable/disable temporary worker banning
WORKER_CACHE_TIME = 600 # How long the worker stats cache is good before we check and refresh
WORKER_BAN_TIME = 300 # How long we temporarily ban worker
INVALID_SHARES_PERCENT = 50 # Allow average invalid shares vary this % before we ban
so I guess with default settings they will be unbanned after 300 seconds? |
|
|
|
Is there a windows binary available of the latest client? i do not have a windows dev environment setup at the moment.
Alternatively i would be happy with a mac binary.
not yet, but the latest changes are needed only if you want to run your own pool |
|
|
|
|
Show Posts
