-
Notifications
You must be signed in to change notification settings - Fork 463
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
# Hashes found is much lower vs the coinhive pool #83
Comments
This is working as expected. CoinHive accepts all hashes (share difficulty 1) and credits you for each hash in groups of 256. Other pools only accept submissions that meet the share difficulty. Even though the hash rate is the same for both pools, how the acceptance rate is calculated differs. CoinHive expects browsers to hit it and quit it, so you can't have the same pool model as minexmr. I think CoinHive's acceptance method is most fair for low hash rate and potentially short visitors. |
Its like this, |
That's the big problem with this stratum, it only works well with the supportxmr.com pool, where the initial difficulty is 1000, too high for that purpose. By my test a good difficulty is below 500. Cazala informed me that he is trying to correct this pool problem, and I believe that soon we can work with pool that offer a lower difficulty and thus we can increase the hashrate! |
Your hash rate does not change. Pools calculate by accepted hashes. The rate fluctuates but doesn't increase your hash rate long term. |
I'll quote what I said on an earlier issue: a lower difficulty won't mean higher hashrate, only higher job submission rate. the hashrate is the amount of job submissions times the difficulty. so if you mine on a pool with a difficulty of 256, you will send for example 20 jobs per minute, and if you mine on a pool with a difficulty of 1000 you will send 5 jobs per minute. 4 times less, because the diff is 4 times higher, but also your jobs will give you 4 times more shares than the ones from the pool with lower difficulty. 20 jobs at difficulty 256 in 1 minute means: 20 * 256 = 5000 shares: 5000hash / 60sec = 83.33 h/s 5 jobs at difficulty 1000 in 1 minute means: 5 * 1000 = 5000 shares, again: 5000hash / 60sec = 83.33 h/s Of course when doing webmining you want to submit jobs fast, because your user might not stay that long in each page, and you want the miners to be able to submit jobs in that short span of time, but in my experience i've gotten the best results mining on supportxmr.com (difficulty 1000) |
tl;dr: difficulty doesn't impact on profits or hashrate |
regarding the issue with There are plenty of pools that work: nanopool.org, minexmr.com, supportxmr.com, usxmrpool.com, and so forth. If you really need your miners to submit jobs fast (faster than the 1000 difficulty of supportxmr.com) because your users stay in your page for very short timespans (like ~10 seconds or less) you still have options:
|
regarding this:
when using
but since the proxy doesn't know the difficulty where you are mining on, I can't hardcode a That's why I left it like just What you need to care about is how much XMR you are getting paid in the end, and so far I've gotten the best results in supportxmr.com |
tl;dr: don't look at the miner's stats, look at the pool's stats |
Great, thanks for the explanation everyone. Thanks for this useful tool. |
|
yes, it's true, you need to be able to submit at least one job before the block is found, but comparing a 256 diff against a 1000 diff the profits should be the same |
What about this config param from the readme, would this override the difficulty from the connected pool? |
No. Most pools offer variable difficulty (vardiff) with a specific port for starting difficulty. Some offer fixed difficulty option but you need to do your research. Usually it is appended to end of Monero address... Even then there's an acceptable fixed minimum (e.g. 2000). I don't understand how xmr-node-proxy (@Snipa22) works exactly, but they claim to somehow submit lower share difficulty through their proxy. Doesn't make sense to me, but they claim it is possible. |
Snippa's proxy does work, I have it up and running myself and the installation can be done with a simple curl + configuring a config.json file. I have set it to 256 and it works like CoinHive (I wouldn't be surprise if that's actually what CoinHive uses to allow that low diff) |
I followed your advice and installed Snippa's proxy on my server, the idea is very good but the hashrate decreases by 20% using Snippa's proxy. Pool: pool.elitexmr.com I set up for automatic payments when I reach the minimum of 0.3. |
@vphelipe We are working on a own pool at this moment. |
@CineXMike Ok, I just wanted to help people with the same problems as me. |
@CineXMike censoring is not the way to go. There will always be other pools. Users must have the choice to join the one that better suits their needs, otherwise we are no better than CoinHive. I'm restoring @vphelipe comment. |
can anyone else comfirm 20% lower hash rates adding a node proxy to the architecture? |
so what if this is the total hashes 78 accepted hashes 256 |
I ran coinhive while connected to the stratum proxy configured like this:
host: "pool.supportxmr.com",
port: 3333
running stratum programmatically as nodejs project on Heroku
logs from client look like this after about 3 minutes running on two cores
When connected directly to the default coinhive pool, 'found' and 'accepted' events seem to come much more frequently and at much higher numbers, yet the "hashes per second" is reported as about the same. Is this just due to difficulty differences or is there something wrong here?
The text was updated successfully, but these errors were encountered: