 Show Posts
|
|
Pages: « 1 2 3 4 5 [6]
|
I just published some rieMiner Benchmark results here, so people can compare and have an idea of mining speeds. Do not hesitate to benchmark and submit your result too. Be sure to use the Standard or Easy Benchmark parameters. One standalone binary for Windows 64 bits is provided for rieMiner 0.9β1, but was not much tested. It should work on Core 2 Duo computers and higher. I even got it working on Wine! You can download it in the rieMiner GitHub release page. How can i setup it to riepool.ovh? Create a rieMiner.conf file next to the executable containing: Host = riepool.ovh
Port = 8000
User = User.Worker
Pass = Password
Protocol = Stratum
Threads = 8 Change User, Pass, and Threads fields to what they should be. Read the README.md file in the source code/project's page for more options. For XPoolX: Host = mining.xpoolx.com
Port = 5000
User = User.Worker
Pass = Password
Protocol = Stratum
Threads = 8 For uBlock.it: Host = mine.ublock.it
Port = 5000
User = User.Worker
Pass = Password
Protocol = Stratum
Threads = 8 For solo mining (change Host and Port if needed, and set the User, Pass, Address, and Threads to what they should be): Host = 127.0.0.1
Port = 28332
User =
Pass =
Protocol = GetBlockTemplate
Address =
Threads = 8 |
|
|
|
Now, rieMiner 0.9β1.5 (2018-09-15) drops GetWork support and proposes a better Standard Benchmark. I will publish some results soon. Hi PttnMe, Right now I am testing your miner using fx8350, 32GB of RAM and W7 64bits trying solo mining with these rieMiner.conf settings: Host = 127.0.0.1; Port = 28332; User = (my wallet address); Pass = (my password); Protocol = GetBlockTemplate; Address = (my wallet address); Tuples = 6; Threads = 8; Sieve = 4073741824; (because why not?  ) Refresh = 30; Miner works fine, trashing my CPU  at full speed, but still, I am unable to switch into GetBlockTemplate Protocol. (Benchmark only). Any idea how to turn it on? Remove the ; at the end of each line. Normally, rieMiner told you "Invalid Protocol", and the Benchmark Mode is the default "Protocol". |
|
|
|
rieMiner 0.9β1 (2018-09-14) - Benchmark mode added  ! Also, some bug fixes, and a huge code refactoring. The miner should now be stable enough to replace the older fastrie/xptMiner without problem. There are also instructions on how to build a standalone executable on Windows. I am waiting the official Riecoin Wallet update and letting some time to find and fix remaining bugs and do some minor refactoring before releasing the stable rieMiner 0.9. At this moment, official standalone binaries for Windows and probably Linux will be provided. As always, feedbacks and suggestions are welcome, do not hesitate. And to pool owners, if you could tell about rieMiner in your homepages, it would really help me and I would be grateful; we would have more people testing rieMiner. 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/tk0pfeOhttps://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? Great! Thank you for letting me know that it also works on uBlock.it. It should also be the case for rieMiner 0.9β1. And now, you have an answer about including the Dlls when building. 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
I hope that you are satisfied with rieMiner. Else, please report bugs to improve the software until the stable release. Some were fixed in 0.9β1. I think the GetBlockTemplate problem (actually it was submitblock) is fixed.
I confirm this, solo mining with GetBlockTemplate via your wallet seems to work fine 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 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.
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? |
|
|
|
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? 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 : 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. 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. 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. 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. |
|
|
|
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, issuesrieMiner'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 ./bignum.h:57:24: error: invalid use of incomplete type ‘BIGNUM’ {aka ‘struct bignum_st’}
/usr/include/openssl/ossl_typ.h:80:16: note: forward declaration of ‘BIGNUM’ {aka ‘struct bignum_st’} typedef struct bignum_st BIGNUM;
./bignum.h:62:9: error: ‘BN_init’ was not declared in this scope
./bignum.h:68:30: error: cannot convert ‘CBigNum*’ to ‘BIGNUM*’ {aka ‘bignum_st*’}
/usr/include/openssl/bn.h:219:25: note: initializing argument 1 of ‘BIGNUM* BN_copy(BIGNUM*, const BIGNUM*)’
The last 2 lines multiple timesOn Debian 9 stable, there is no Bignum error, but I get: test/test_riecoin.cpp: In member function ‘CBlock TestChain100Setup::CreateAndProcessBlock(const std::vector<CMutableTransaction>&, const CScript&)’:
test/test_riecoin.cpp:151:84: error: could not convert ‘(& chainparams)->CChainParams::GetConsensus()’ from ‘const Consensus::Params’ to ‘offsetType {aka arith_uint256}’
while (!CheckProofOfWork(block.GetHash(), block.nBits, chainparams.GetConsensus())) ++block.nNonce;
~~~~~~~~~~~~~~~~~~~~~~~~^~
test/test_riecoin.cpp:151:97: error: ‘class CBlock’ has no member named ‘nNonce’
while (!CheckProofOfWork(block.GetHash(), block.nBits, chainparams.GetConsensus())) ++block.nNonce;
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. 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.
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. |
|
|
|
Anyway, when I start riecoin community forum we may move there to talk for that and to look deeper in codes  If you set a forum up, it will be more appropriate to continue the discussion there, in a topic dedicated to rieMiner, to keep this one clean for general discussion. I will come back in September to continue working on it. If you could set your forum up until then, it would be nice. |
|
|
|
The failure is a bad alloc, so I do not think that the problem is CPU related. Just for fun, I compiled it once on a Pentium 3 laptop, unfortunately it has this issue. But I encountered it in some recent computers as well. I suspect that for some reason, rieMiner needs much more memory to start, than it actually uses/needs. I will investigate this later in September. I likely just removed one line too much or so.
This exception is throw when "new" in C++ cant allocate memory. In fact calling new not guarantee it will allocate the needed memory. So it throw that exception and you have to handle it in your code, or you can stop throwing the exception and you should check if returned pointer is not null. Second method is slower, so first one is better practice. On P3 machine it is obvious that there is not enough memory, but if you doubt about memory leaks valgrind and gdb are your best friends. They will show you where you allocating memory and not freeing it. In DGA's fastrie miner there is some points where memory leaks are possible. but they are not a problem. It is always good practice to call "delete" in C++ when you don't need any more allocated memory from heap with "new" and to call mpz_clear for mpz structures, even when there is no obvious point to do it. Ok, so you are right, I did some quick debugging, and the problem occurs when I use new for an array called segment_hits. It is allocating almost 30 GB... For some reason, the miner is much more sensitive to this problem on Windows than Linux, so I thought at first that it was a Windows specific problem. Unfortunately, as I did not study the miner optimizations, I do not have any idea of what are the "segment hits" :| ... The huge memory allocation problem seems to be fixable by reducing the max_increments value (with for example 1 << 25 instead of 1 << 29), but this seems to decrease noticeably the performance (by about 40%). But by doing that, I was able to get the Pentium 3 laptop mining properly! It is about 100 x slower than one 2700X unthrottled thread, but would still find a Testnet block each hour. This variable might simply be an user configurable variable, like the sieve size. I will commit in minutes to reflect these observations (essentially updating the Readme and restore the allocation checks that I stupidly removed). Thank you for pointing out the bad alloc origin. |
|
|
|
...
AFAIK, regtest mode isn't available on the 0.9 codebase, at least not easily... so having an easy testnet will most likely help dev work. I would suggest throttling your miner (on a low power VM) to keep the difficulty manageable. Correction, regtest is there. Still, it probably would be helpful to have a low diff testnet. Sure, I will mine very slowly by using cpulimit. I will try to produce about 1 block each 2,5 min at difficulty 304. |
|
|
|
When you developing miner it will be better to have low difficulty, so checking if your algorithm is right will be faster, it is annoying to must wait hours or days just to check if block you found is correct The Testnet is more meant to look like the Mainnet network, where people (not just developers) can test Riecoin with "play tokens". Developers who are creating programs other than a miner would like to be able to send and receive coins too, with new blocks found regularly. If I am not mistaken, there exist a "regression mode", more adapted to do such testing, with an own local network. Raw performance testing is preferably done by using some fixed data from a chosen block. Cool, my plans are to build riecoin community site with a lot HOWTOs and information about riecoin so if you don't mind will include your miner. Your source code looks very clean and ordered, it is good to have as much as possible different and various software for riecoin, that will attract more people to the community.
No problem, and thank you for the feedback. I wish you all success with your website. With what error execution fails ? You are using gmplib which is highly optimized for calculations, and big parts from it are in assembler. It gives big speedup but portability is lower, for example if you compile with gmplib optimized for i7 or xeon it will fail to run on P4. many modern compilers put by default optimizing flag -mtune=native which will auto detect CPU instructions set and will optimize for it, which can break portability too. Maybe to be portable one cpu miner you should use -march=pentium4 your code will run on any modern CPU , but you will lose speed.
The failure is a bad alloc, so I do not think that the problem is CPU related. Just for fun, I compiled it once on a Pentium 3 laptop, unfortunately it has this issue. But I encountered it in some recent computers as well. I suspect that for some reason, rieMiner needs much more memory to start, than it actually uses/needs. I will investigate this later in September. I likely just removed one line too much or so. |
|
|
|
[...] That list are my nodes I started before, and using them from time to time to testing builds or miner modification. It is not stuck, just there is only 34 blocks left on them from my tests. [...]
Oh Ok, this is fine in this case. I just expected that there would be much more blocks, and new ones found regularly, so I thought that something was wrong. Lol, I just mined hundreds of blocks at the rate of 1 block each 3 second or so, difficulty 304 is so low. In contrast, I was unable to mine anything using the wallet's built-in miner. I might leave one mining thread for the testnet network, so developers and testers can experience more realistic behavior when using it. A Testnet explorer would be welcome too. Thank you again for your nodes, and your reply. If anyone is interested in, I merged the original gatra's miner ( rminerd) and the latest dave-andersen's one ( fastrie), so anyone can solo mine Riecoins using the optimized algorithm. Here is the rieMiner's GitHub repository. I heavily simplified and modernized (making it more C++ish) the code. Indeed, the fastrie's code contains many parts of unused or outdated code. In another hand, I am not knowledgeable enough to improve the miner algorithm, so this miner is more a convenience improvement than a performance one. Currently, you should be able to compile it easily on Linux and Windows. The miner works fine on my computer, and is currently mining blocks, but for some reason, its execution might fail in some computers. Moreover, only the old protocol Getwork is supported. I plan to work on it on September and later to add the GetBlockTemplate (and custom payout addresses) and Stratum (and pool mining as well) protocols support, a benchmark mode (dummy mining at constant difficulty), and fix remaining problems. The Testnet nodes will be very useful for me! |
|
|
|
[...]
For testing and developing, started two test nodes, and created dns record for them, so if you want to use testnet add these lines to your riecoin.conf
addnode=testnet.riecoin-community.com
testnet=1
If you have or plan to start a node in testnet for longer and want to be put in nodes list, please send me private message with your ip address.
Thank you IGJ (and everyone who supports the project). Unfortunately, using your nodes, I am stuck at block 34 (36 weeks behind). Do I need to configure something else? Does anyone have more Testnet IPs? |
|
|
|
|
