Appreciated!  I replied to their tweet too, and tagged you guys and 0xPolygon, hoping that will stir something

Ok, but there's nothing stopping you reaching out to them on twitter. 

I understand that cointracking are only a user of the polygonscan API, but at some point you need to either pressure them to fix it or find an alternative API for cointracking to use.  I pay subscription fees to your for your service, so frankly don't need to hear about issues with your integrators, I just need to know when cointracking will start working again.

Please can you reach out and put some pressure on the guys at polygonscan?  As a paying customer, I am not able to use your service right now - it's not my responsibility to check on the status of your third-party integrations.

Thanks

Is there any update on this?  Can you guys switch over to an alternative RPC?

1) We do still use SHA-3 as part of the hashing for the hash channel.  Our quantum resistance comes from a number of factors... not only from our adoption of post-quantum hashing functions such as FALCON, but also through our Signature Chains architecture, which constitutes one-time use public/private keys and limits the window of opportunity for brute-force cracking.   All aspects of Nexus's quantum resistance is covered in detail on the website here https://tech.nexus.io/quantum-resistance

2) No Nexus is not ASIC resistant, though I'm not aware that any have been developed so far.  There have been FPGA bitstream's developed for the Nexus hash channel and Blackminer is offering an FPGA (to use with their pool) complete with a Nexus bitstream.

3) The GPU miner for the hash channel was updated last year.... https://github.com/Nexusoft/NexusMiner.  The hash channel didn't have too much room for improvement, but this miner includes significant speed improvements for GPU mining on the prime channel.  Jack (aka Blackjack) who originally developed NexusMiner whilst working for Nexus, has since made further updates to NexusMiner on his personal github repo.  I can't find the link to it at the moment but I'm sure someone could post it of you need it. 

Agreed. Jabar, we get that you have some kind of personal vendetta against Nexus and like trolling this project at every opportunity, but personal attacks are a step too far.   

nexusminingpool is for the prime channel (CPU) only.

Yup no secrets here, I use AWS.  I have great instance limits.  I pay for it and mine using it when something is profitable.  Anyone with a credit card can sign up for AWS and do the same with a little learning (or google-fu, it's not hard).

It wasn't a botnet and it wasn't 2000 miners, it was 1000 ( they were mine).  The pool just disconnects them so often that it gets the count wrong.  I also crashed the pool frequently with only 1000 machines, which is pretty bad.  If the author wants to make his source public, I'll host an additional pool myself to take load away (I host other pools)

yeah the pool is not coping with the 1000+ miners on it. 

Your stratum and website appear to have died with more than a couple of hundred miners.  You might want to beef up your servers.

I'm getting 13% rejects on http://www.bilbotel.fr - any idea why Nillecram?

In short yes, although you might have to wait a while... Payments are made when the pool mines a block - it does not wait for confirmations, it becomes part of the coinbase of the mined block itself.  Due to the decaying block reward it is never possible to pay all miners in any given block.  So instead the pool prioritises payments by balance outstanding, paying the highest first, until a block is full.  If the balances dont add up to a full block reward we will fill it up with any smaller due payments to fill up the block, meaning that sometimes much lower outstanding balances get included.  So with this in mind, if you have a larger outstanding balance of say 1.5-2 NXS then you will be paid out relatively soon, whereas if you have a smaller balance you will likely have to wait until your payment fits into a block.
 

Are you sure?  We have > 190 connections and don't appear to have had any downtime since I brought it online.  Check out the WPS graph on the homepage.

The Prime channel mining pool nexusminingpool.com is now back up and running!!!

I've maintained all user balances from before the old server died, but unfortunately I have lost the statistics in the web front end.  Stats might look a little funny until we find the first block

Let me know if you have any trouble!

Update on the state of the nexusminingpool.com prime channel pool....

I have finally had confirmation from my hosting company that both drives in my raid array are faulty and need to be replaced.  I do have a backup of all of the account data and blocks, but at this stage I don't know how complete that backup is to know whether all balances will be maintained.  I believe they will which means that all unpaid earnings will be maintained when I get the new server up.   Unfortunately what I do know is that the server statistics database has been lost (the statistics that drive the web front end such as the connection history, payment & earnings history), as I have verified that my last backup is corrupt.  That's a bit frustrating, but not the end of the world. 

Apologies again for the long downtime.  I'll be working to get it back up ASAP, and will then look to integrate @a.kubrakov's GPU pool code into it too once he makes the source public. 

- Paul

The new miner for the Prime channel is now out!!

I have just uploaded the new Windows binaries, and these can now be found here http://www.nexusminingpool.com/downloads/PrimePoolMiner.zip. I will get them moved onto the nexusearth site shortly.  The source code is in the main Nexus git repo here https://github.com/Nexusoft/PrimePoolMiner. 

This miner is running around 4-5x faster than the old one, so a significant improvement indeed.  Those compiling on linux are currently getting around 15% better speed than those using Windows, as it is using some assembler code to optimize part of the prime checks, and this code does not currently compile on Windows. 

You will notice that the PPS metric has now disappeared, and has been replaced by a bunch of other metrics to help you tune the miner.  I won't go into the details here, but the key metric to note is the ShrVal/h, or share value per hour.  This is the best indicator of the "worth" your miner is producing and what you should ultimately use to gauge the performance.  As such I have replaced PPS with ShrVal/h on the nexusminingpool.com front end (in your own stats).  WPS is still useful as an indicator, especially over shorter runs of minutes to hours, so we are leaving that in for now.

The new miner is very sensitive to the number of threads allocated to  the "sieve_threads" and "ptest_threads" values in the config file.  The aim is to tweak these values so that the Siv/s and Tst/s metrics in the out out are as close as possible to each other.  In our testing we have found that values of sieve_threads = 5 and ptest_threads = 8 works well as a starting point on many 8-core systems.   As with the previous miner, the "bit_array_size" should ideally be tweaked so that the *value / 8* fits into your CPU L3 cache

This miner can also be used for SOLO mining, for those with enough power at home to warrant doing so, and enjoy the same speed improvements as pool miners.  There are example .conf files for both pool and solo mining.

For more help with the config or any other questions you have, please come and ask in the #mining channel in slack.

Lastly, we have to thank @mumus for his excellent work in developing this update.  He has done this work for free, so I do encourage you to throw some tips his way!

The ones with the very small nonces are likely to be proof-of-stake blocks.  Don't forget that these are also in the mix and will account for the short block time you are referring to.   

To be truthful I did this a long time ago on CentOS and don't even have that server anymore.  But I get the exact same issue trying to compile using either cygwin or mingw, I forget which it was, and I also get it when compiling the CPU pool miner under these.  The fix is always the same, wherever the #define __STDC_FORMAT_MACROS 1 is inside another #ifdef then move it outside.  Just do a find-in-files for it.  In the latest code there is only one in /src/core/core.h.  I think it is safe to move it outside of the #ifdef WIN32 for all builds...  <<< physicsdude

The fix that physicsdude suggested works for me on CentOS...
Move the
#define __STDC_FORMAT_MACROS 1
define out of the #ifdef WIN32 and also I think above any other #includes
I might have had to change this in a few places.