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

[one4many]

there is perhaps a gpu miner for this? i see a gpupool on the first post, but i think it's something else? or this is still under cpu only, not that i believe it lol, i guess someone is private mining with gpu already

gpupool offers only CPU mining for RIC.  I don't claim to understand the naming.

As with all "CPU-only" coins, someone(s) is either botnet mining, or GPU mining, but it's very hard to say which.  Because of the DDoS situation, I'd be willing to bet that there's a botnet involved somewhere, though.

+1 also my best guess ...

@Gatra have you contacted Polo already?

[1715060277]

1715060277

[1715060277]

1715060277

[xpoolx]

I think most of the riecoin users already contacted poloniex. In my case i post a ticket like 10 days ago and not answer yet.

[gatra]

Hi! yes, I did write to Poloniex, I'll let you know if I have some news to share

[MasterQ]

Been a while since I mined Riecoin but with the recent price & attention increase I thought I would give it another go.

Is anyone else using riepool.ovh? I am testing it on my Xeon D-1520 server and getting 2,500 Kh/s https://gyazo.com/8bbaddbfe9c62eaa535c5ced37a49edb

They advertise their total hash at 2,876,360.48 KH/s but with only 202 workers. How does that work? That would mean each worker is averaging at 14239 KH/s

[ziiip]

Been a while since I mined Riecoin but with the recent price & attention increase I thought I would give it another go.

Is anyone else using riepool.ovh? I am testing it on my Xeon D-1520 server and getting 2,500 Kh/s https://gyazo.com/8bbaddbfe9c62eaa535c5ced37a49edb

They advertise their total hash at 2,876,360.48 KH/s but with only 202 workers. How does that work? That would mean each worker is averaging at 14239 KH/s

Honestly there is no good way to calculate hashrate on Riecoin, most of the pools are just guessing what it should be based on RIC/day and the total network hashrate. It's best to check your share rate on the miner directly for an accurate comparison. ( i would take the share-rate value of Riepools miner with a grain of salt, as it's closed source)

Most of the "workers" are usually many workers sitting behind a stratum proxy etc, so they only register one worker with the pool even though they have many

Also you might want to look at other pools who aren't using a closed source miner. (Riepool's miner is closed source, so their is no real way to determine if it contains a virus or not, use at your own risk!!)
It would also help to further distribute the hashrate, uBlock.it only needs a few more workers for more consistent payouts. Please check us out if you can.

[jaroag]

5000 sats in btc38 

[kharismac999]

5000 sats in btc38 

Why on poloniex just about 3k?

[jaroag]

5000 sats in btc38 

Why on poloniex just about 3k?

wallet disabled I guess

[chrysophylax]

Been a while since I mined Riecoin but with the recent price & attention increase I thought I would give it another go.

Is anyone else using riepool.ovh? I am testing it on my Xeon D-1520 server and getting 2,500 Kh/s https://gyazo.com/8bbaddbfe9c62eaa535c5ced37a49edb

They advertise their total hash at 2,876,360.48 KH/s but with only 202 workers. How does that work? That would mean each worker is averaging at 14239 KH/s

Honestly there is no good way to calculate hashrate on Riecoin, most of the pools are just guessing what it should be based on RIC/day and the total network hashrate. It's best to check your share rate on the miner directly for an accurate comparison. ( i would take the share-rate value of Riepools miner with a grain of salt, as it's closed source)

Most of the "workers" are usually many workers sitting behind a stratum proxy etc, so they only register one worker with the pool even though they have many

Also you might want to look at other pools who aren't using a closed source miner. (Riepool's miner is closed source, so their is no real way to determine if it contains a virus or not, use at your own risk!!)
It would also help to further distribute the hashrate, uBlock.it only needs a few more workers for more consistent payouts. Please check us out if you can.

so the question is simple ...

WHERE do we find the opensource miners that are CURRENT - so we can look at the algo code - and implement a 'proper' cpuminer for riecoin? ...

almost everywhere i have looked - is 'almost' a dead end ... ie - VERY old miners - closed source - no current codebase we can look at - etc ...

gatra - do you have a collection / list of ACTIVE miners that actually work ( and can be compiled - as the link for cpuminer on this thread simply DOES NOT compile ) ... we would be interested mainly in the git / source of the coin / algo ...

i know you have pointed me in the right direction previously for the stratum - but there is no way to implement that easily in our setup ( cwi-stratum ) without breaking it and recoding again ... especially due to the lack of exposure of what the algo 'actually' is ... otherwise we would have had the ability to create a python / c++ hash for the algo - and implement it everywhere ...

it is frustrating for us - let alone the community members who WANT ( note - not NEED ) to mine and trade and work with this coin ...

if this list exists of WORKING links - sourcecode and miners - please send me ...

tanx ...

#crysx

[ziiip]

Been a while since I mined Riecoin but with the recent price & attention increase I thought I would give it another go.

Is anyone else using riepool.ovh? I am testing it on my Xeon D-1520 server and getting 2,500 Kh/s https://gyazo.com/8bbaddbfe9c62eaa535c5ced37a49edb

They advertise their total hash at 2,876,360.48 KH/s but with only 202 workers. How does that work? That would mean each worker is averaging at 14239 KH/s

Honestly there is no good way to calculate hashrate on Riecoin, most of the pools are just guessing what it should be based on RIC/day and the total network hashrate. It's best to check your share rate on the miner directly for an accurate comparison. ( i would take the share-rate value of Riepools miner with a grain of salt, as it's closed source)

Most of the "workers" are usually many workers sitting behind a stratum proxy etc, so they only register one worker with the pool even though they have many

Also you might want to look at other pools who aren't using a closed source miner. (Riepool's miner is closed source, so their is no real way to determine if it contains a virus or not, use at your own risk!!)
It would also help to further distribute the hashrate, uBlock.it only needs a few more workers for more consistent payouts. Please check us out if you can.

so the question is simple ...

WHERE do we find the opensource miners that are CURRENT - so we can look at the algo code - and implement a 'proper' cpuminer for riecoin? ...

almost everywhere i have looked - is 'almost' a dead end ... ie - VERY old miners - closed source - no current codebase we can look at - etc ...

gatra - do you have a collection / list of ACTIVE miners that actually work ( and can be compiled - as the link for cpuminer on this thread simply DOES NOT compile ) ... we would be interested mainly in the git / source of the coin / algo ...

i know you have pointed me in the right direction previously for the stratum - but there is no way to implement that easily in our setup ( cwi-stratum ) without breaking it and recoding again ... especially due to the lack of exposure of what the algo 'actually' is ... otherwise we would have had the ability to create a python / c++ hash for the algo - and implement it everywhere ...

it is frustrating for us - let alone the community members who WANT ( note - not NEED ) to mine and trade and work with this coin ...

if this list exists of WORKING links - sourcecode and miners - please send me ...

tanx ...

#crysx

dga has done some work on the open source miner recently. You can find it here.
https://github.com/dave-andersen/fastrie/tree/stratum

Readme has also been updated a bit, you might find it helpful as some CentOS/RedHat instructions have been modified.
https://github.com/dave-andersen/fastrie/blob/stratum/xptMiner/README.md


I can confirm that this build offers a slight performance increase over the previous miner.
However, I've only been able to compile this for Linux, I've had zero luck compiling for Windows.

I believe dga might be working on a static compile for Windows soon but he's a busy guy you know.

If someone has successfully compiled this new build for Windows, please share how you did it.

[chrysophylax]

Been a while since I mined Riecoin but with the recent price & attention increase I thought I would give it another go.

Is anyone else using riepool.ovh? I am testing it on my Xeon D-1520 server and getting 2,500 Kh/s https://gyazo.com/8bbaddbfe9c62eaa535c5ced37a49edb

They advertise their total hash at 2,876,360.48 KH/s but with only 202 workers. How does that work? That would mean each worker is averaging at 14239 KH/s

Honestly there is no good way to calculate hashrate on Riecoin, most of the pools are just guessing what it should be based on RIC/day and the total network hashrate. It's best to check your share rate on the miner directly for an accurate comparison. ( i would take the share-rate value of Riepools miner with a grain of salt, as it's closed source)

Most of the "workers" are usually many workers sitting behind a stratum proxy etc, so they only register one worker with the pool even though they have many

Also you might want to look at other pools who aren't using a closed source miner. (Riepool's miner is closed source, so their is no real way to determine if it contains a virus or not, use at your own risk!!)
It would also help to further distribute the hashrate, uBlock.it only needs a few more workers for more consistent payouts. Please check us out if you can.

so the question is simple ...

WHERE do we find the opensource miners that are CURRENT - so we can look at the algo code - and implement a 'proper' cpuminer for riecoin? ...

almost everywhere i have looked - is 'almost' a dead end ... ie - VERY old miners - closed source - no current codebase we can look at - etc ...

gatra - do you have a collection / list of ACTIVE miners that actually work ( and can be compiled - as the link for cpuminer on this thread simply DOES NOT compile ) ... we would be interested mainly in the git / source of the coin / algo ...

i know you have pointed me in the right direction previously for the stratum - but there is no way to implement that easily in our setup ( cwi-stratum ) without breaking it and recoding again ... especially due to the lack of exposure of what the algo 'actually' is ... otherwise we would have had the ability to create a python / c++ hash for the algo - and implement it everywhere ...

it is frustrating for us - let alone the community members who WANT ( note - not NEED ) to mine and trade and work with this coin ...

if this list exists of WORKING links - sourcecode and miners - please send me ...

tanx ...

#crysx

dga has done some work on the open source miner recently. You can find it here.
https://github.com/dave-andersen/fastrie/tree/stratum

Readme has also been updated a bit, you might find it helpful as some CentOS/RedHat instructions have been modified.
https://github.com/dave-andersen/fastrie/blob/stratum/xptMiner/README.md


I can confirm that this build offers a slight performance increase over the previous miner.
However, I've only been able to compile this for Linux, I've had zero luck compiling for Windows.

I believe dga might be working on a static compile for Windows soon but he's a busy guy you know.

If someone has successfully compiled this new build for Windows, please share how you did it.

tanx for that ...

we are ALL busy - and so we understand ... a little help goes a long way - and we appreciate your help with this ...

linux ( fedora 25 x64 ) is what we work with - as well centos for the daemons ( which we have yet to successfully compile ) ... so all and ANY help is appreciated ...

ill personally look into the links you supplied in a day or so - as busy means getting all the 'real life' stuff out the way and working on this after that is all done ...

as for windows ... ummm ... ...

tanx again ...

#crysx

[dga]

dga has done some work on the open source miner recently. You can find it here.
https://github.com/dave-andersen/fastrie/tree/stratum

Readme has also been updated a bit, you might find it helpful as some CentOS/RedHat instructions have been modified.
https://github.com/dave-andersen/fastrie/blob/stratum/xptMiner/README.md


I can confirm that this build offers a slight performance increase over the previous miner.
However, I've only been able to compile this for Linux, I've had zero luck compiling for Windows.

I believe dga might be working on a static compile for Windows soon but he's a busy guy you know.

If someone has successfully compiled this new build for Windows, please share how you did it.

tanx for that ...

we are ALL busy - and so we understand ... a little help goes a long way - and we appreciate your help with this ...

linux ( fedora 25 x64 ) is what we work with - as well centos for the daemons ( which we have yet to successfully compile ) ... so all and ANY help is appreciated ...

ill personally look into the links you supplied in a day or so - as busy means getting all the 'real life' stuff out the way and working on this after that is all done ...

as for windows ... ummm ... ...

tanx again ...

#crysx

I welcome patches to get it building on Windows.  I'm sorry - I've been trying to find time to get my build environment for cross-compiling for windows back up, but I'm simply not managing to juggle that and my day job(s).  I would love, and gratefully acknowledge, help on this.

#crysx, if you're having compile problems with my miner, please let me know what they are.  I can fix things for Linux pretty easily.  Windows... is another beast, since I don't have it and have never developed for it.  Centos shouldn't be *too* much of a problem (he says, fingers crossed).  At one point, I was doing some of the initial development of the miner on a Centos machine, in fact.  As long as you've got a recent g++ installed via devtoolset, it should be OK.

[chrysophylax]

dga has done some work on the open source miner recently. You can find it here.
https://github.com/dave-andersen/fastrie/tree/stratum

Readme has also been updated a bit, you might find it helpful as some CentOS/RedHat instructions have been modified.
https://github.com/dave-andersen/fastrie/blob/stratum/xptMiner/README.md


I can confirm that this build offers a slight performance increase over the previous miner.
However, I've only been able to compile this for Linux, I've had zero luck compiling for Windows.

I believe dga might be working on a static compile for Windows soon but he's a busy guy you know.

If someone has successfully compiled this new build for Windows, please share how you did it.

tanx for that ...

we are ALL busy - and so we understand ... a little help goes a long way - and we appreciate your help with this ...

linux ( fedora 25 x64 ) is what we work with - as well centos for the daemons ( which we have yet to successfully compile ) ... so all and ANY help is appreciated ...

ill personally look into the links you supplied in a day or so - as busy means getting all the 'real life' stuff out the way and working on this after that is all done ...

as for windows ... ummm ... ...

tanx again ...

#crysx

I welcome patches to get it building on Windows.  I'm sorry - I've been trying to find time to get my build environment for cross-compiling for windows back up, but I'm simply not managing to juggle that and my day job(s).  I would love, and gratefully acknowledge, help on this.

#crysx, if you're having compile problems with my miner, please let me know what they are.  I can fix things for Linux pretty easily.  Windows... is another beast, since I don't have it and have never developed for it.  Centos shouldn't be *too* much of a problem (he says, fingers crossed).  At one point, I was doing some of the initial development of the miner on a Centos machine, in fact.  As long as you've got a recent g++ installed via devtoolset, it should be OK.

thats the issue ...

the gcc / cuda is 'too' recent ...

fedora 25 x64 gcc632 ... so the when the cpuminer is being compiled - it fails immediately with an error about an unknown command - ^M ... i have rewritten the script - but its still complains about that control code for some reason ...

the other miners have their own issues ... so i downloaded the code and bin ( some of them have code - others are just binary ) xptminer - xptminer2 - rminer - etc and still no real 'mining' per se ( cpuminer-rminer hashes but never gets accepted shares ) and xptminer2 ONLY runs on riepool with no option to run on any other pool ... so the ONE miner that actually works - will ONLY work on that pool ...

the coin code itself is a different issue - due to the broken ( crippled ) openssl inherent in most of the earlier rhel based systems ... trying to get it built using a local build of the later compiled openssl102k - and still not winning on this either ... i think its a linking issue ... but i couldnt spend too much time more on it ...

if we can isolate the algo part alone - we could probably implement it into other miners ...

tanx for your help mate ...

#crysx

[dga]

thats the issue ...

the gcc / cuda is 'too' recent ...

fedora 25 x64 gcc632 ... so the when the cpuminer is being compiled - it fails immediately with an error about an unknown command - ^M ... i have rewritten the script - but its still complains about that control code for some reason ...

the other miners have their own issues ... so i downloaded the code and bin ( some of them have code - others are just binary ) xptminer - xptminer2 - rminer - etc and still no real 'mining' per se ( cpuminer-rminer hashes but never gets accepted shares ) and xptminer2 ONLY runs on riepool with no option to run on any other pool ... so the ONE miner that actually works - will ONLY work on that pool ...

the coin code itself is a different issue - due to the broken ( crippled ) openssl inherent in most of the earlier rhel based systems ... trying to get it built using a local build of the later compiled openssl102k - and still not winning on this either ... i think its a linking issue ... but i couldnt spend too much time more on it ...

if we can isolate the algo part alone - we could probably implement it into other miners ...

tanx for your help mate ...

#crysx

Sorry, but to be really clear, can you copy/paste the make output when compiling from *my* source tree specifically?

https://github.com/dave-andersen/fastrie/tree/stratum

(note that you want the stratum tree).
cpu-rminerd is very stale and you don't want to use that except for experimentation.

Please include the last 20 lines up to and including the failing command of the make output, and I'll happily help out.  This miner will work on any stratum-supporting pool.  I'd suggest trying Ziiip's (ublock.it) -- it's what I was testing against when I made the most recent improvements.

[onedeveloper]

thats the issue ...

the gcc / cuda is 'too' recent ...

fedora 25 x64 gcc632 ... so the when the cpuminer is being compiled - it fails immediately with an error about an unknown command - ^M ... i have rewritten the script - but its still complains about that control code for some reason ...

the other miners have their own issues ... so i downloaded the code and bin ( some of them have code - others are just binary ) xptminer - xptminer2 - rminer - etc and still no real 'mining' per se ( cpuminer-rminer hashes but never gets accepted shares ) and xptminer2 ONLY runs on riepool with no option to run on any other pool ... so the ONE miner that actually works - will ONLY work on that pool ...

the coin code itself is a different issue - due to the broken ( crippled ) openssl inherent in most of the earlier rhel based systems ... trying to get it built using a local build of the later compiled openssl102k - and still not winning on this either ... i think its a linking issue ... but i couldnt spend too much time more on it ...

if we can isolate the algo part alone - we could probably implement it into other miners ...

tanx for your help mate ...

#crysx

Regarding that code, can you run the following script:

Code:

sed -i 's/\r//g' <offending_filename>

Change "<offending_filename>" for the actual file name to change.

[Simba84]

Solo miners continue to withholding blocks 

Then they are broadcasted after 5-10 minutes! Not enough power you have to even cheat !!!!

 

[dga]

Solo miners continue to withholding blocks  

Then they are broadcasted after 5-10 minutes! Not enough power you have to even cheat !!!!

 

Can you point to where in the blockchain you saw this?

Normally, a selfish mining attack results in an increased orphan rate, and is pretty visible.  It doesn't seem unusual thus far:

https://chainz.cryptoid.info/ric/orphans.dws

But maybe I'm not understanding what you're saying.

Also, nice diff - if this stays through tomorrow's high-diff block it will produce a new record.

[Simba84]

Solo miners continue to withholding blocks  

Then they are broadcasted after 5-10 minutes! Not enough power you have to even cheat !!!!

 

Can you point to where in the blockchain you saw this?

Normally, a selfish mining attack results in an increased orphan rate, and is pretty visible.  It doesn't seem unusual thus far:

https://chainz.cryptoid.info/ric/orphans.dws

But maybe I'm not understanding what you're saying.

Also, nice diff - if this stays through tomorrow's high-diff block it will produce a new record.

If someone holds over 50% of the nodes they can broadcast the blocks when they want without generating orphans! Strange you (programmer) do not know these things.....

Remember the superblock of last week? It was broadcasted on the network with 2 hours and 40 minutes delay !!!! Do you feel normal? Or do we do the kids?

As we are here programmers, what you have to understand you understand!

The diff rises because of the egoists who solo mine and those only miners who withholding blocks!

If others have not noticed this... open your eyes!

Solo miners are ruining the work of pool administrators, that's for sure!

Keep doing so..... good.....

[dga]

Solo miners continue to withholding blocks  

Then they are broadcasted after 5-10 minutes! Not enough power you have to even cheat !!!!

 

Can you point to where in the blockchain you saw this?

Normally, a selfish mining attack results in an increased orphan rate, and is pretty visible.  It doesn't seem unusual thus far:

https://chainz.cryptoid.info/ric/orphans.dws

But maybe I'm not understanding what you're saying.

Also, nice diff - if this stays through tomorrow's high-diff block it will produce a new record.

If someone holds over 50% of the nodes they can broadcast the blocks when they want without generating orphans! Strange you (programmer) do not know these things.....

Remember the superblock of last week? It was broadcasted on the network with 2 hours and 40 minutes delay !!!! Do you feel normal? Or do we do the kids?

As we are here programmers, what you have to understand you understand!

The diff rises because of the egoists who solo mine and those only miners who withholding blocks!

If others have not noticed this... open your eyes!

Solo miners are ruining the work of pool administrators, that's for sure!

Keep doing so..... good.....

Um, what I don't understand is what you are saying.  This may simply be a language barrier.  (And one for which I won't criticize - your English is better than I am at any of the other languages I speak, and I appreciate that we're able to communicate here in my native tongue.)

A > 50% miner cannot profitably withhold blocks without creating orphans.  That's precisely the *reason* to withhold blocks -- you let other people waste their hashing effort, orphan them, and mine the blocks without increasing the difficulty.  (The other reasons to withhold attacks involve trying to double-spend, which isn't relevant in this context, since no exchanges accept 0-confirmation RIC transactions.)

The delay you're seeing is much more likely due to DDoS or network anomalies than intentional withholding.  But I was curious to try to investigate it, which is why I *asked you to point to it*, which you have not done.

Yes, the solo miners are harming the income achieved by the pool administrators, but who cares?  (I mean, obviously, you do, because it's your income stream, but why should anyone else care?).

A solo miner at 50% is concerning in a more fundamental sense, of course, just as a pool at 50% is concerning, because they can easily orphan others' blocks.

The diff rises because there is a ton of mining going on.  Which may or may not have something to do with:



(Image screenshot from coingecko - they don't have a 2Y chart, unfortunately.)

[dga]

Ah, just spotted this on security news:

https://www.guardicore.com/2017/05/the-bondnet-army/

"A 15,000 servers strong botnet currently suspected of operating out of China is being used for mining cryptocurrencies. The botnet is made up of compromised Windows Server machines.
...
The miner’s installer picks which cryptocurrency to mine and then downloads and installs a matching miner, with priority given to Monero. Additional miners include ByteCoin, RieCoin or ZCash, all convertible to USD"

I think it would be quite worthwhile to track down some of the large mining addresses and see if there's a joint investigation to see if they are, in fact, botnet monetization.  One of the best ways to stop botnets is to follow the money - that's where they gateway to the real world.