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

[gatra]

New Riecoin client v0.9.1 binaries are ready. Download from here:

https://sourceforge.net/projects/riecoin/files/riecoin%200.9.1/

We have 3 packages for windows: 32 bit installer, 64 bit installer, and the full zip with sources and binaries.
For linux, one tar includes all binaries and sources.


Changes included:

- submitblock rpc bug fix
- speed optmizations
- getprimes RPC call!
- networkhashpers rpc call

And all the changes from Bitcoin Core 0.9.1 that apply to Riecoin.
These include the openssl update, coin control, 64-bit windows client, new makefiles, and payment requests among many others.

EDIT: I forgot to mention another change regarding testnet. The trailing zeros limit was removed so miners with high primorials can now be used on testnet too. The problem is that old riecoin clients will not accept those blocks so it will cause a fork. So this version should be considered a hard fork for testnet. But hey, it's only the testnet, I only see 3 clients connected and there were no blocks for many days.

Hey Gatra, will focus be concentrated on stratum mining now?

yes, and I'm trying to see what's wrong the android wallet too

[1715616278]

1715616278

[1715616278]

1715616278

[1715616278]

1715616278

[1715616278]

1715616278

[1715616278]

1715616278

[gatra]

My math is not that good .. anyone knows why primes generated by RIC miners have lots of zeros in the middle?

They have a lot of zeros in the middle (when you write them in base 2 or hex, you won't see this in base 10) because of the way they are encoded, we "insert" zeros to adjust the difficulty, and only store the quantity of zeros and an offset. This way the block header remains a structure with constant size but has the ability to store numbers of different sizes (potentially huge numbers, so large they won't fit in a hard drive).

[primer10]

My math is not that good .. anyone knows why primes generated by RIC miners have lots of zeros in the middle?

They have a lot of zeros in the middle (when you write them in base 2 or hex, you won't see this in base 10) because of the way they are encoded, we "insert" zeros to adjust the difficulty, and only store the quantity of zeros and an offset. This way the block header remains a structure with constant size but has the ability to store numbers of different sizes (potentially huge numbers, so large they won't fit in a hard drive).

Thanks for the insight! That's ingenious!

if that's the case then https://darmstadt.goxadidi.dk/cgi-bin/block/block_crawler.py 's representation is correct but not http://chainz.cryptoid.info/ric 's.

Could you point me to the src code where this encoding occurs? if you have some spare time of course.

[gatra]

Thanks for the insight! That's ingenious!

if that's the case then https://darmstadt.goxadidi.dk/cgi-bin/block/block_crawler.py 's representation is correct but not http://chainz.cryptoid.info/ric 's.

Could you point me to the src code where this encoding occurs? if you have some spare time of course.

I think both are correct. Take for example block 52879. The first prime in the 6tuple is 1717 bits, or 517 decimal digits.
Both sites say the first prime is this:

Code:

3704548176830082402354888184036735265457513707514114282827126923346807719350909942106612520104867140576183570834177334161620337378149933509025093323038949528156249517533245340639394255761738073988903532935654252009350389903363559279831135436000899487506000499319552851131755478195997174057396243136009137212692071774950889359968473782298676131797996654711544972318803208178611638849274173834397469436974459765232720733141700830653120916133514543679046891468928196323731230202881016252244325991624419491234321088355327

This number has 517 digits, of which 50 are zeros, 56 are 1s, etc. Pretty close to what one would expect statistically.

The one at https://darmstadt.goxadidi.dk/cgi-bin/block/block_crawler.py gives us extra info: this number is the result of:

Code:

29729085016233304338613443050818417113406958567487­755830292125671859583168405516 × 2^1452 + 98073904408287305294319139144127310667729966524052­49038309180536196528315391

When written in base 2, the number has a string of about 1200 consecutive zeros "in the middle".

The function that transforms the parameters into the number is here: https://github.com/riecoin/riecoin/blob/0.9.1/src/main.cpp#L1243-L1266 - this generates the "base" from the difficulty and the block hash to which you have to add the "offset" (which acts as the nonce) to get the first prime of the tuple.

EDIT: also, in base 16 each hex digit represents 4 bits, so the number will be 430 digits long, and you'll see 299 or 300 (I haven't counted them) zeros in the middle.

[aamarket]

I did not have the time to finish ARM port, and there is another problem ...
after couple of runs the miner always ends with something like this :
1717[00:23:20] 2ch/s: 0.4447 3ch/s: 0.0380 4ch/s: 0.0000 Shares total: 0 / 0
Bus error

... which is mentioned only in sph_types.h #if SPH_SPARCV9_GCC

probably inttypes conversion is needed as mentioned already...

[primer10]

Thanks for the insight! That's ingenious!

if that's the case then https://darmstadt.goxadidi.dk/cgi-bin/block/block_crawler.py 's representation is correct but not http://chainz.cryptoid.info/ric 's.

Could you point me to the src code where this encoding occurs? if you have some spare time of course.

I think both are correct. Take for example block 52879. The first prime in the 6tuple is 1717 bits, or 517 decimal digits.
Both sites say the first prime is this:

Code:

3704548176830082402354888184036735265457513707514114282827126923346807719350909942106612520104867140576183570834177334161620337378149933509025093323038949528156249517533245340639394255761738073988903532935654252009350389903363559279831135436000899487506000499319552851131755478195997174057396243136009137212692071774950889359968473782298676131797996654711544972318803208178611638849274173834397469436974459765232720733141700830653120916133514543679046891468928196323731230202881016252244325991624419491234321088355327

This number has 517 digits, of which 50 are zeros, 56 are 1s, etc. Pretty close to what one would expect statistically.

The one at https://darmstadt.goxadidi.dk/cgi-bin/block/block_crawler.py gives us extra info: this number is the result of:

Code:

29729085016233304338613443050818417113406958567487­755830292125671859583168405516 × 2^1452 + 98073904408287305294319139144127310667729966524052­49038309180536196528315391

When written in base 2, the number has a string of about 1200 consecutive zeros "in the middle".

The function that transforms the parameters into the number is here: https://github.com/riecoin/riecoin/blob/0.9.1/src/main.cpp#L1243-L1266 - this generates the "base" from the difficulty and the block hash to which you have to add the "offset" (which acts as the nonce) to get the first prime of the tuple.

EDIT: also, in base 16 each hex digit represents 4 bits, so the number will be 430 digits long, and you'll see 299 or 300 (I haven't counted them) zeros in the middle.

Thanks!

[Emmi-state]

Glad to see more interest in the coin.Keep up the good work!

[northranger79510]

New Riecoin client v0.9.1 binaries are ready. Download from here:

https://sourceforge.net/projects/riecoin/files/riecoin%200.9.1/

We have 3 packages for windows: 32 bit installer, 64 bit installer, and the full zip with sources and binaries.
For linux, one tar includes all binaries and sources.


Changes included:

- submitblock rpc bug fix
- speed optmizations
- getprimes RPC call!
- networkhashpers rpc call

And all the changes from Bitcoin Core 0.9.1 that apply to Riecoin.
These include the openssl update, coin control, 64-bit windows client, new makefiles, and payment requests among many others.

EDIT: I forgot to mention another change regarding testnet. The trailing zeros limit was removed so miners with high primorials can now be used on testnet too. The problem is that old riecoin clients will not accept those blocks so it will cause a fork. So this version should be considered a hard fork for testnet. But hey, it's only the testnet, I only see 3 clients connected and there were no blocks for many days.

Hey Gatra, will focus be concentrated on stratum mining now?

yes, and I'm trying to see what's wrong the android wallet too

Let me know if you need help

[aamarket]

tested ARM miner a bit more, seems like data in xptClient_sendShare are OK, at least xptShare->prevBlockHash is the same as in x64 miner running in parallel and xptShare->riecoin_nOffset is a valid part of the first in prime 4-tuple, but it seems there is no hash in the high order bytes of the prime present... hopefully problem found !

[PeaMine]

Are there any special instructions for making the stand alone miner on Ubuntu 13 64bit?
Such as AVX or AES flags for CPUs that support it?
What's the example command line to use for Windows solo mining would be optimal?
Should only run one instance per hardware correct?

[northranger79510]

Bump! Sorry I havn't been on this past week. Still busy with projects.

[primer10]

Are there any special instructions for making the stand alone miner on Ubuntu 13 64bit?
Such as AVX or AES flags for CPUs that support it?
What's the example command line to use for Windows solo mining would be optimal?
Should only run one instance per hardware correct?

I just ran make using the default Makefile. It should compile to AVX if you have the correct architecture (your CPU)

[aamarket]

ubuntu should work fine with ./buildAll

fedora required a bit of help (see history here).

Also a small progress with ARM miner, investigation led me to the part of code,
I already marked with "?" long time ago when trying to understand some old miner ...

having

    uint32* powHashU32 = (uint32*)powHash;

    for(uint32 i=0; i<256; i++)
    {
        mpz_mul_2exp(z_target, z_target, 1);
        if( (powHashU32[i/32]>>(i))&1 )
            z_target->_mp_d[0]++;
    }

It needs ">>(i%32))" I'd say - and I do not know why it works fine on x64, but the change helped to get seemingly proper targets on ARM.
Still no share submitted, so I do not know if it helped.

[Siexpert]

I'd be interested to see the prime numbers found by the Riecoin network, is somewhere a link for it?

[fairglu]

I'd be interested to see the prime numbers found by the Riecoin network, is somewhere a link for it?

I'm regularly compiling a text file with the first primes of each constellation at http://chainz.cryptoid.info/ric/, you can also view them in the blocks pages.

[aamarket]

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

[northranger79510]

Hey Fairglu, what is the rich list based off? Will coins held on exchanges be counted?

[fairglu]

Hey Fairglu, what is the rich list based off? Will coins held on exchanges be counted?

It's based on the individual address balances, if it's a paper wallet (only added to), then it's accurate.

If it's an address in a regular wallet (qt or similar), then it's an under-estimation of the wallet (because of change addresses the client creates every time you don't spend an exact input)

If it's an address in an exchange, then things are quite muddy, as the exchanges will mix'n match funds from deposit addresses to perform their withdrawals, and they will have funds scattered on deposit & cold addresses.

For instance here is the (currently) largest address known to the explorer to be part of MintPal wallet: http://chainz.cryptoid.info/ric/address.dws?34776.htm
It's part of a "guesstimated" wallet of more than 1000 addresses, if you follow the link, you'll see most are empty. Many of those are deposit addresses of Mintpal users, but it doesn't say anything about those users MintPal balance, which is kept in MintPal's database (off the blockchain).
All the explorer can then says is that the MintPal wallet holds more than 200k RIC (this being just a minimum).

I'm mulling adding a "rich wallets" list, as for some coins exchange addresses dominate the rich list (like for PIG).

[primer-]

There is a bug in the new Windows wallet (same as in the previous version). To reproduce leave it running for a couple of days or maybe couple of hours, not sure, i dont use it often (listen=0). Interface shows 2-5 active connections. Initiate a transfer. Transaction details : Offline, not broadcasted. Re-broadcasting with -rescan now works but only after 1 hour.

[primer10]

Of recent times, I am believing more in Riecoin than Primecoin.

I think ppl should move to UpCPU