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

I think the GetBlockTemplate problem (actually it was submitblock) is fixed.

Whoah! nice changes this week on riecoin.

let's see if gatra aproves the new wallet to start working on the pool implementation for it.

And thanks a lot Prtnme for the new miner. Im going to test it right now

hi man !
just to inform you that i compiled a x64 windows version of your miner and it works perfectly in ublock.it as well !
https://imgur.com/a/tk0pfeO
https://imgur.com/a/RXjqDBj
* mine.ublock.it = mine.blockocean.com

Many thanks for your work !!

EDIT: Since compiling stuff is not my area of expertise (its been a loooong time from uni), i'd like to ask if there is a way to export the needed .dll in/from MinGW in order to have a stand alone version running straight from windows?

I love CPU only coins!

Greetings clo1,

Thanks for posting your code. I've skimmed it and would like to assist if possible (I can perhaps help with gitian, builds, and tests). In the interest of more easily auditing/maintenance would it be possible to add your commits on top of the latest 0.16 code from upstream, preserving the git history? Also, it might be easier to not unnecessarily rename files to ease future merges.

For instance, I've created a new github organization:

https://github.com/riecointeam/riecoin

If you put your changes on the master branch it might make things more clear. (Or gatra can update riecoin/riecoin.git master to 0.16, whatever.)

FWIW, I don't have an interest in taking a share of your rightly deserved bounty.

Nice work!

Hello guys

Very good work clo1 !!! And to you pttn !

I wrote few words in community board about openssl 1.1 and created a patch for 16.0 you can check there in developers corner.

For faster sync I don't think is good idea to easier the miller-rabin test, we should keep it as close to 10.2 as possible, because this may lead to forks. miller-rabin is probabilistic test, so some nodes may accept the prime the others may reject, as many test is done more sure is, it will be accept by all.

GMPlib have high optimized miller-rabin test as far as I know, and I believe it will be faster than openssl, but strong tests will be needed to see if openssl and gmplib will give same result for all blocks we have by now.

The duplicate shares problem is now fixed and rieMiner seems now be usable for pooled mining. Miners, please try rieMiner and give some feedbacks.

And lucky you XPoolX, I even found a block during testing...


I did not know that these "3" addresses already existed in 2014. But in this case, we should change the prefixes anyway to avoid confusion with Bitcoin "3" and "bc1" addresses.

Edit: I finished syncing and tested quickly rieMiner with your wallet via GetBlockTemplate. Unfortunately, I am getting "CheckProofOfWork() : not valid pow" messages in Testnet when finding blocks, but the miner seems to be able to extract correctly the mining information (else, it would not mine anything, yet it is actually working and finding/submitting things).

The GetBlockTemplate command in 0.16 seems to give the same results for the needed fields (previousblockhash, coinbasevalue, bits,...), so I think that the miner should still have been compatible without any changes. The version changed, but submissions are still rejected if I hard change it to 2. Can you see in your side what might have changed when the wallet receives proof of work?

It took me a little over a day to sync which was a big improvement over the 5 days it took me on the original code. I think the speed improvement comes because the proof of work is only checked on 20% of blocks if the block is older than the latest checkpoint. The last checkpoint is now almost 4 years old in the original code. One possibility would be to only check each prime a single time instead of multiple times if the block is older than the latest checkpoint. In either case we should regularly add checkpoints.

I think the miner improvement comes from needing to check fewer primes, not from speeding up the checks themselves.


I haven't taken anything out so if it is in Bitcoin it should be in the new code. The '3' and '2' come from the SCRIPT_ADDRESS that gatra set.

Your project sounds good, it looks very interesting and promising and your team work was so impressive. I hope it will be a great project in the future so keep it up guys and all the best for your bright future.

Oh, sorry, I missed this part of your text. So I was able to compile your wallet after disabling the testing part on Debian 9 stable, and execute it on Debian 9 Sid. It is so great to run this version of Riecoin, you did a fantastic job, and I wish you good luck for the bounties! I am also using libdb 5.3.

I am currently syncing. This is really slow for a network with very few transactions, but this seems more a CPU bottleneck than a network one, as one core is used at 100% during sync.
Do you think that the POW validation could be optimized like the miner was, in order to sync much faster?


apt-cache policy gives for respectively Sid and Stretch :


I only got Bignum errors. Here is a pastebin of the errors that I got.

The miner currently uses GMP, so you might consider using it as well in the wallet and remove the Bignum usage like the Bitcoin devs did.
It should be Ok as long as the proof of work is mathematically the same: checking if n, n + 4, n + 6, n + 10, n + 12, and n + 16 are prime using Rabin-Miller primality tests (with 40 iterations if I remember correctly).
You could even take this opportunity to optimize the POW validation to speed up the syncing as I said, if possible.


Do you plan to fully support the "3"/"bc1" addresses for Riecoin, and change the prefixes (I would suggest "3" -> "T" (2nd letter after R) and "bc1" -> "bcR" (1 became R for legacy addresses))?
The closer we are to the Bitcoin features support, the easier we will be able catch up its future updates, and there will be better compatibility for exchanges listing and other services.


IGJ will certainly gladly upload the binaries on his website.


I was thinking in this direction as well and might have found a solution.

Edit: this problem was fixed and will be commited soon.

AFAIR it can be something similar to that issue when you try to generate random numbers using loop having only one variable to store them you will get same numbers changing every second. Every CPU thread needs unique variable. I think to fix this you need to declare as many variables as possible at the very beginning of your code and then limit them to what you need.

The code builds on both my systems - 16.04 and 17.10.

PttnMe, can you tell me what version of OpenSSL you are using on Debian 9 (Sid)? I'm using 1.02g. Were all your errors related to bignum on Debian 9 Sid?

Bitcoin has completely removed bignum and replaced it with a custom class (arith_uint256). I used this whenever possible but couldn't use it for the prime validation code. My first thought was to use GMP, but I ended up staying with bignum so I could use the exact same validation code as in the original. I'm a little concerned now that we might have compatibility problems later on if we stick with bignum. Does anyone have any thoughts on this?

Awesome Clo1 and PttnMe! I am looking forward to your stable releases! Keep the good work up!

Who is the idiot who dumped at 50 while 2 devs are releasing great advancements?

Thanks for testing this.

If you got to the test units there is a good chance you already built riecoind and possibly also riecoin-qt.

The test units have not been updated and won't compile. To eliminate the errors you need to re-configure.

./configure --disable-tests
make

I'm not sure why it didn't work on debian sid. My plan for this week is to install ubuntu 18.04 and try to build for windows. I'll see if I get a similar error.

The binaries are over 100 MB so they can't be placed on github. Maybe we can put them on the community site.

I'll take a look at GetBlockTemplate a little later.

rieMiner 0.9α3 (2018-09-09) - Stratum support added ! You can now solo + pool mine (although Stratum support is still experimental)

Testing, feedbacks, or even contributions are welcome to fix remaining bugs and improve the miner.

The miner is working for RiePool and XPoolX. However, there is a bug that produces many duplicate shares for powerful CPUs. This problem is present if many threads are used, but seems to disappear if mining with just 4 threads or less (and it seems possible to launch 4 instances using 4 threads for a 16 threads CPU without issue). I will investigate this.

I do not have an uBlock.it account, so I was not able to test for this pool.

Pools owners are also invited to test the miner and make suggestions or contributions.

rieMiner's GitHub repository, issues
rieMiner's thread on Riecoin-Community.com forum

Great clo1, thank you very much for helping the project and providing your work.

On Debian 9 (Sid), I have many Boost/Bignum errors while compiling. Do you have any idea why this is happening? I installed libboost-all-dev. Errors look like

On Debian 9 stable, there is no Bignum error, but I get:


I am however able to compile the latest Bitcoin Core in both computers, without any issue.

I guess that for now, I will need to install Ubuntu 16.04 to test your code.


GetBlockTemplate support was already added a few days ago and blocks were successfully mined with it (also works if it contains transactions). Example: Block 947897 with transaction fees. As soon as I am able to compile your code, I will test rieMiner with your update to make sure that rieMiner still works, and adapt the code if needed. I will see what it needed to change when the BIPs are activated. And if I have more time, I will test further your code.

Stratum support for pooled mining, at least experimental, will come today as well. Miners are welcome to test the code and submit bugs/open GitHub issues.
Once everything is finished, fixed and tested, we will be able to upgrade xptMiner as well. rieMiner provides a much more developer friendly code for people wanting to improve the algorithm.

I've posted my code on github.
https://github.com/clo-prime/riecoin-0.16

So far I have built it on Ubuntu 16.04 and tested on Ubuntu 16.04 and 17.10. I have run on testnet and mainnet. I have tested mining, sending, and receiving. I have tested the GUI and command line. This code is still experimental. I make no guarantees.

To build, follow instructions in doc/build-unix.md. The test runs have not been updated and will not compile. Configure with –disable-tests (2 dashes, then 1 dash).

Until segwit is enabled you must run with addresstype=legacy in your riecoin.conf file. Without this segwit addresses will be used. I believe the transactions will be accepted but you won't be able to spend them until segwit is enabled. When generating an address, make sure it starts with 'R' (or 'r' on testnet) and not '3' (or '2' on testnet).

I've temporarily set the default directory to be .riecoin16 instead of .riecoin so that all testing is kept separate from the current core. This can be overridden  with -datadir from the command line or riecoin.conf file.

Getwork is no longer supported in bitcoin. Pttn, it would be awesome if you could add GetBlockTemplate support to rieMiner. I’ve temporarily added getwork support to the code for testing although the format is slightly different. It takes an address as an input.

Wallet mining was removed from bitcoin several versions ago. I recently noticed there is some mining code for testing purposes (generateblocks and generatetoaddress). I haven’t implemented this. Is this needed and if so what code should be used here? I know the code currently in the core is outdated.

I haven’t added any seed addresses but this will be simple once we determine what they should be.

IGJ – thanks for running the testnet and your work setting up the community site.

The softforks haven't been tested yet but I don't expect any problems here. The older BIPS are coded to become active at a specific block. I have currently set them to become active at block 1000000 but this can be changed to a block that will be reached shortly after the code is released. Once this block is reached any block mined with an old miner (using an old block version number) will be rejected even if the block is otherwise perfectly valid.

The newer BIPS become active if a super-majority of blocks are mined using a miner indicating support. I believe it is 95% within a 288 block window. This must occur within a specific time window which we will need to set before releasing code.

We've seen nothing to support this from looking through the data.  We obviously can't reveal customers behind trades but the pattern is not that of institutional dumping.

I noticed that even after September 2, the balance is decreasing. Are they already slowly dumping the coins on Zapple? If so, they might be the ones who sold 2 times 100 k at 70 sat...

In the other direction, just a 1-2 BTC buy would wipe the sell orders and the price would return to 300-400... And a 3-4 BTC one would make the price return to the precrash values. Buyers, do not be shy! In particular the dude who places ridiculously small buy orders, just wipe these sell orders already!

It is really painful to mine with these miserable prices as well. Riecoin must be profitable again.

Hey Guys,

How are the updates coming along?? Very excited to see Riecoin shine!!