Quote from: clo1 on September 09, 2018, 09:48:30 PM

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.

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?

Quote from: clo1 on September 10, 2018, 03:07:53 AM

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?

apt-cache policy gives for respectively Sid and Stretch :

Code:

openssl: Installed: 1.1.1~~pre9-1
libssl-dev: Installed: 1.1.1~~pre9-1

openssl: Installed: 1.1.0f-3+deb9u2
libssl1.0-dev: Installed: 1.0.2l-2+deb9u3

Note: I installed libssl-dev instead for Stretch (version 1.1.0f-3+deb9u3) and got Bignum errors as well.
I think that installing libssl1.0-dev in Sid will fix the problem.

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.

Quote from: clo1 on September 09, 2018, 05:06:10 AM

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

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.

Quote from: clo1 on September 09, 2018, 09:48:30 PM

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

IGJ will certainly gladly upload the binaries on his website.

Quote from: czakris on September 10, 2018, 09:24:42 AM

Quote from: PttnMe on September 09, 2018, 08:33:41 PM

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.

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.

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

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