Riecoin appears to be a useless shitcoin, unless someone can prove to me why it isn't.  I checked its exchange rate 2 days ago, and it'd take about 40,000 Riecoins to equal one BitCoin.  That sucks.

I got signed up on ypool and am using the xptminer on several of my PCs to CPU mine Riecoin.

With a total of 5 CPU cores, split between i3, Athlon, and Celeron CPUs, I have gotten 3-1/2 Riecoins in a day and a half.

I am not impressed, to say the least.  I thought it'd be cool to have my CPUs mine something, like the early days of BitCoin, but to have gained less than 1/10,000th of a BTC (about 6 cents) after a day and a half isn't good.

(**) It took me about $50 of virtual server to mine about 100 ric over the weekend.  People mining are doing it at a loss, not paying for hardware/power or are using miners which are 40x more efficient that dga's.  Only ypool.net can tell if there is a super miner.

Hi! I've been a little sick  (just a flu) and I didn't touch a keyboard in like 4 days (!) that's weird for me... anyway, I'm still working but I didn't make much progress lately.


One idea I've been fantasizing about: we could make Riecoin2, based on the new ring signature anonymous coins (Monero/Bytecoin). It would be a fork of their code but using out PoW. There should be a way to transition from RIC to RIC2. Maybe we could have a burn period where we would burn RIC to transform them into RIC2, or I could just premine a lot of RIC2, sell them for at 1 RIC on an exchange and after a while just burn the unsold ones. The latter would be easier than monitoring both chains.

What do you think? those who don't like it would be allowed to continue in the current RIC, and the fact that you would be able to use it to buy RIC2 at a fixed price (for a while) would make the price (of RIC) go up. Or would it hold RIC2 down? who knows....

Hi all Riecoiners !

@bsunau7
Android port of DGA's miner was just a side note, I prefer Linux to Android.

I checked some net info about FPGA modular exponentation performance, nothing interesting or too expensive,
but possibly somebody has better info.

I've succeed to compile DGA's miner on the Parallella without any problem and the speed on the main dualcore ARM A9 CPU is 0.3655 2ch/s. Not impressive but I didn't expected more. The problem is with the share submission. In the moment it finds a share and trying to submit it, xptMiner crashes and I get the error message "Bus error". I didn't had the time to debug it yet. I think it's some alignment problem.
When I'll have some free time I will also start to port the code to use the 16-core Epiphany chip, just for fun. I don't expect to see any dramatic speed improvement.

I just got my parallella 2 days ago. I don't even remember when I ordered. Anyway it's time to play with it and find some primes . If anybody has some links to start with, I will thank them. I'm a noob in this territory.

very interesting!
I used to work with an ARM chip that had an "embedded cryptographic coprocessor", which basically means it had a few interesting features implemented by hardware, like sha2 and modular exponentiation (up to 2048bits in this case). Wish I could put my hands on one of those, but the development boards were expensive.

so you're really mining with ARM? cool!
well, thermal throttling means it's not literally cool, but you get the point

Slow thread right now. Need posters!  

// 32 = 2^5 ; (2^32 / 17) = 252645135.05882352941176470588 ~= 0x0f0f0f0f
uint32_t mod17(uint32_t n) {
        static uint8_t table[32] = { 0 ,1 ,2 ,2 ,3 ,3 ,4 ,4 ,
                                     5 ,5 ,6 ,6 ,7 ,7 ,8 ,8 ,
                                     9 ,9 ,10,10,11,11,12,12,
                                     13,13,14,14,15,15,16,16 };
        n = (0x0f0f0f0f*n + (n >> 4)) >> 27;
        return table[n];
}

Thanks for spotting this. I have committed a fix to the xptMiner repository. The performance difference should be insignificant on x64/x86.
I also know there are some other places in the xpt source where memory alignment can make problems. Especially all the xptPacketbuffer_* functions have unaligned read/write access which is supported on x86/x64 but not on other platforms, but I don't know if it matters on ARM.

I can confirm above mentioned change helped,
ARM riecoin miner delivered first 4 primes share (after quite a long time) :

p4=0x803a9a745c512a58eaceaafd83f4259ffd0e9bcec9d306484a0e0a7944efc5762b * 2**1452 + 0x32e238469041bc6ef8edc6dcd5d872f664bcbd5ae7e76fd1385ec97334d4c0f

[00:54:07] Share found! (Blockheight: 54252)
====xptShare:: algo=7,ver=2,nTime=1399991211,nBits=33993728,userExtraNonceLength=4
xptShare->prevBlockHash :: dc 4c 98 04 9e ac af 34 2e a5 4a 7b 64 88 07 5a 64 1c 1b 0b c4 f8 2f c8 33 7f 0d 3b f0 21 87 75
xptShare->merkleRoot :: e9 e6 b4 09 ad 1c 4e 87 8b 10 7b 6e 48 08 23 1d 5f 1a 4e c4 e5 bb ad c2 22 f6 a5 fc 1b 9d 45 91
xptShare->merkleRootOriginal :: 7a 7c e8 0d 6d 07 91 7a e8 40 60 55 0f 46 09 e2 86 9a 49 ca ae 4e e6 28 29 13 d3 4d b9 a8 19 d2
xptShare->userExtraNonceData :: 12 00 00 00
xptShare->riecoin_nOffset :: 0f 4c 4d 33 97 ec 85 13 fd 76 7e ae d5 cb 4b 66 2f 87 5d cd 6d dc 8e ef c6 1b 04 69 84 23 2e 03
1716[00:54:08] 2ch/s: 0.7239 3ch/s: 0.0454 4ch/s: 0.0013 Shares total: 1 / 1

"Bus error" is still present, so a watchdog had to be implemented, but hey, now everybody can mine coins with their android cell phone

I agree, dga, and I know, but ... just few lines below ifdef ... else ... *(uint32*)(nOffset+d*4) = z_temp2->_mp_d[d];
and it was in the code since the beginning. But to be sure, I'll double check.
I know (u)intXX_t is the right way, I already burned myself doing data exchange x64<->mips32 long time ago
I think I replaced some in some previous miner version, doing cleanup as well, but your version is far more superior, so I ditched old changes.
regarding win - that was exactly what I was thinking
but no results yet apart from "uninitialized values" seem to be in the libraries and/or old kernel (so no apparent problem in the code),
killed in valgrind soon because with sieve=9e8 its close to my memory limit,
and that I checked couple returned triplets, they seem to be primes (like p - 4,  p - 6,  p - 16 ; p - 4,  p - 12,  p - 16 ; p - 4,  p - 10,  p - 16 ; ....)
Which points us to your original point

I'll post some results soon, but the speed is horrible and it does not make sense to run on this ARM architecture

Perhaps I'm misunderstanding, but:

(a)  Using the 40th primorial (plus or minus depending on which of the miners you're talking about) means that you never sieve factors that fit into a word anyway.

(b)  The majority of time in my code is spent doing three things, in order:
  - Fermat primality test (gmp)
  - Calculating T_rounded_up % p  (gmp)
  - Sieving large primes that still occur multiple times in the maximum number of nonces (primes under 2^29).
    Most of this time is actually spent asking one thing:   if (offset < sieve_size)
    which mostly fails with a sieve of 8M entries and a prime of, e.g., 100m.

My guess, though I might be wrong, is that a lot of the optimizations you're looking at start to become less dominant when you go for a really huge primorial.  For example, almost _no_ time is spent in checking the actual sieve - as far as I can tell, there's basically zero benefit to trying to optimize finding candidates.  The code spends somewhere between 1-2 seconds doing primality testing for each iteration through the sieve (8 million bits).  The time to check each bit position is a few tens of microseconds of that 1-2 seconds.

Hi, all - I've posted b14 source and binaries for the fastrie xptMiner:

- Binaries:      http://www.cs.cmu.edu/~dga/crypto/ric/
- Source:        https://github.com/dave-andersen/fastrie
- ChangeLog:  https://github.com/dave-andersen/fastrie/blob/master/ChangeLog
- README:      http://www.cs.cmu.edu/~dga/crypto/ric/readme.html

This is a speed-boost release targeting larger sieves, and the binaries are now
linked against gmp 6.0.0a, which provides faster code targeting avx and avx2
in particular.  Sandy Bridge, Ivy Bridge, and Haswell machines should see a very
reasonable 5-15% speedup.

The larger sieve support comes from borrowing a trick from a00k's miner,
which reduces memory consumption with sieves > 500m and slightly improves
speed.

Older, slower machines will probably not get much of a boost from this release,
but newer, faster boxes may benefit from a larger sieve - I'm seeing 10-20% speedups
on i7-4770 (Haswell) CPUs.

Thanks to the folks on ypool for kicking the tires on this.  As always, there
are likely to be bugs, but hopefully not too many.   Please do read the
README before worrying about some of them, and before tweaking
the sieve size too much.

if(!(psieve[j>>5] & ( 1U << (j & 0x1f)))) break;

if(tmp & 0xffffffe0UL) continue;

if(!psieve[j>>5]) { j += 31; offset += 210*31; continue; }

fastrie is only 5% faster with 6.0.0a than with 5.1.3 (I have SandyBridge)

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

Credit where due - I really wanted to make an alternate, pre-computation and memory-heavy approach to this work, but I've given up.  It's tough to beat straightforward sieving, and you (@supercomputing) were right - I ended up just going to a big primorial with a highly optimized sieve.  I haven't rewritten any of the routines currently handled by gmp (and my GMP is probably compiled horribly), but my pool miner is now somewhere in that ballpark.  I've solved 14 or so blocks in 24 hours using 14 machines, which is about in the same range you mentioned for your miner.  Block 17920 is an example, if you're curious to extract my primorial.

I'd still love to find a more satisfying way to crack this nut, though.  But for now, the sieves and fast prime tests have it.

Gatra, thank you for creating Riecoin.  It's terribly fun, has one of the more intellectually interesting proof-of-work cores (as does XPM, in fairness), and I hope it starts producing record prime tuples one of these days.  I'm planning on proposing high-speed RIC sieving cores as a class project for our parallel computing class next week.  Should be fun!

  -Dave

Money on me being at fault, to save memory (make it fit!) I merge two smaller sieves...
--
bsunau7

@bsunau7 - mine does the same.  I kill any location that fails to produce a six-set.  I wonder which of us has a bug?  *grin*  I'll check my sieving code again.  As one way to start comparing, the polynomials for the first few primorials are:

Generator at Pn7 (210)
97  

Generator at Pn11 (2310)
97  937  1147  1357  2197  

Generator at Pn13 (30030)
97  1357  2407  3457  4717  5557  5767  6817  7867  8077  8287  10177  10597  11647  12907  13747  13957  15007  16057  16267  17107  18367  19417  19837  21727  21937  22147  23197  24247  24457  25297  26557  27607  28657  29917  

@Supercomputing - Did you figure out a way to combine wheel factorization with storing a dense bitvector div 2310 (or div 210)?  Or do you just allow a large bitvector and handle it through segmentation?  I liked the way the jh implementation saved a lot of sieve space that way, and a straightforward prime sieve achieves a less dense packing (3-4x).

$ od -t u8 sextuplet.bin | head
0000000                    1                    7
0000020                   97                 1357
0000040                 3457                 4717
0000060                 5767                 8077
0000100                10597                12907
0000120                19417                23197
0000140                29917                30127
0000160                32947                34417
0000200                35797                36847
0000220                37897                38107