[ANN][RIC] Riecoin: constellations POW *CPU* HARD FORK successful, world record - page 195.

goodluck0319

sr. member

Activity: 420

Merit: 250

Quote from: gatra on March 18, 2014, 02:53:51 PM

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?

GreekBitcoin

legendary

Activity: 1428

Merit: 1001

getmonero.org

Quote from: Aboroth on March 18, 2014, 03:24:50 PM

Just to be a pedantic dick I don't think this is science, it's math (and math is most definitely not science), which is fine too.

i am studding relativity right now. please come and tell me about math being DEFINITELY not science...

cell.md

member

Activity: 104

Merit: 10

Quote from: a00k on March 17, 2014, 02:43:32 PM

Hi, this is my first post here:)
I'd like to share my RIC solo-miner code, embedded in riecoind.

https://bitbucket.org/a00k/riecoin

hi a00k

I've compiled your version of riecoind, but just a few second after entering setgenerate true 20 the riecoind exits. In console appear:

Quote

terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc

System is:

Quote

Linux srv 3.12-1-amd64 #1 SMP Debian 3.12.6-2 (2013-12-29) x86_64 GNU/Linux

CPU:

Quote

CPU model name : Intel(R) Xeon(R) CPU X5650 @ 2.67GHz

It's so sad Sad

gatra

hero member

Activity: 583

Merit: 505

CTO @ Flixxo, Riecoin dev

Quote from: dga on March 18, 2014, 03:39:20 PM

Quote from: gatra on March 18, 2014, 03:14:41 PM

Quote from: dga on March 18, 2014, 03:01:34 PM

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

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

gatra

hero member

Activity: 583

Merit: 505

CTO @ Flixxo, Riecoin dev

Quote

math is most definitely not science

oh, come on... I can be a pedantic dick too:

acccording to wikipedia

Quote

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

dga

hero member

Activity: 737

Merit: 511

Quote from: gatra on March 18, 2014, 03:14:41 PM

Quote from: dga on March 18, 2014, 03:01:34 PM

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

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

crendore

sr. member

Activity: 363

Merit: 250

Quote from: gatra on March 18, 2014, 03:14:41 PM

Quote from: dga on March 18, 2014, 03:01:34 PM

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

Looks 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!

This is one of the greatest things i've read on this board in a long time.

surfer43

sr. member

Activity: 560

Merit: 250

"Trading Platform of The Future!"

Bitcoin has positive feedback.
Riecoin has double positive feedback.
Once difficulty gets high enough, there will be record breaking prime sextuplets, which means press and more users.

Aboroth

member

Activity: 60

Merit: 10

Just to be a pedantic dick I don't think this is science, it's math (and math is most definitely not science), which is fine too.

vlax352

member

Activity: 95

Merit: 10

anyone managed to compile miner for windows which work on stratum pool?
i tried and it gives me errors...

gatra

hero member

Activity: 583

Merit: 505

CTO @ Flixxo, Riecoin dev

Quote from: dga on March 18, 2014, 03:01:34 PM

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

Looks 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!

northranger79510

sr. member

Activity: 308

Merit: 250

Riecoin and Huntercoin to rule all!

Quote from: dga on March 18, 2014, 03:01:34 PM

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

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

Wow. Excellent!

dga

hero member

Activity: 737

Merit: 511

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

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

gatra

hero member

Activity: 583

Merit: 505

CTO @ Flixxo, Riecoin dev

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

goodluck0319

sr. member

Activity: 420

Merit: 250

is there any miner that works with RIC pool perfectly?

gatra

hero member

Activity: 583

Merit: 505

CTO @ Flixxo, Riecoin dev

Quote from: surfer43 on March 18, 2014, 02:39:09 PM

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

Code:

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

surfer43

sr. member

Activity: 560

Merit: 250

"Trading Platform of The Future!"

OK, thanks for the help

Workers will be banned for 30 seconds if they submit more than 50% invalid shares. So please update :-)

gatra

hero member

Activity: 583

Merit: 505

CTO @ Flixxo, Riecoin dev

Quote from: surfer43 on March 18, 2014, 02:26:45 PM

Quote from: stratum-mining

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

Code:

# ******************** 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?

surfer43

sr. member

Activity: 560

Merit: 250

"Trading Platform of The Future!"

Quote from: stratum-mining

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.

gatra

hero member

Activity: 583

Merit: 505

CTO @ Flixxo, Riecoin dev

Quote from: crendore on March 18, 2014, 01:42:13 PM

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

Topic: [ANN][RIC] Riecoin: constellations POW *CPU* HARD FORK successful, world record - page 195. (Read 685381 times)

Topic: [ANN][RIC] Riecoin: constellations POW CPU HARD FORK successful, world record - page 195. (Read 685381 times)