# Hashes found is much lower vs the coinhive pool

[boid-com]

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

{hashesPerSecond: 13.718362027573901, hashes: 10, job_id: "kZ9rvR46lf3pQmEwRT7CJR3HzCwB", nonce: "5c446222", result: "89556e5ce76259de720850ad198d2b6f45be15a6b33ff23d65904dca42e60f00"}
App.vue?38cc:92 {hashes: 1}
App.vue?38cc:92 {hashesPerSecond: 14.961996528816833, hashes: 10, job_id: "kZ9rvR46lf3pQmEwRT7CJR3HzCwB", nonce: "73d844fc", result: "2099963f8f8621ee917795d71c40691784fcd12b8d5ecd5d3ff71a978f9c1300"}
App.vue?38cc:92 {hashes: 2}
App.vue?38cc:92 {hashesPerSecond: 15.367356660980754, hashes: 5, job_id: "kZ9rvR46lf3pQmEwRT7CJR3HzCwB", nonce: "0e6652fc", result: "f9ef8f544d8e438e91b5431b49b24d54abb898b0d3532756fbc0760f95b41900"}
App.vue?38cc:92 {hashes: 3}

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?

{hashesPerSecond: 11.960220307258039, hashes: 10, job_id: "145395418838597", nonce: "70608e3e", result: "15a2c0d08a1ef28f93c0323b0f325d5f611a87c54f758e0010566f154943c000"}
App.vue?3495:91 {hashes: 256}
App.vue?3495:91 {hashesPerSecond: 11.642121194481575, hashes: 1, job_id: "145395418838597", nonce: "5222c37b", result: "9cfc053106ad3a451157a19c1f0e5465b1531e5af51b2acb2cbdcfa839b1a000"}
App.vue?3495:91 {hashes: 512}
App.vue?3495:91 {hashesPerSecond: 15.35194330015601, hashes: 3, job_id: "145395418838597", nonce: "d23184a7", result: "919c1d9e6fbcd18b2e5c5ccf04a9dafe55e1ac26426f3df12f76bc33a6c84700"}
App.vue?3495:91 {hashes: 768}
App.vue?3495:91 {hashesPerSecond: 14.31147494060757, hashes: 5, job_id: "145395418838597", nonce: "da4126b2", result: "a62b05802102abd09a0d9163fa034fd85a8d3530d81b4da774acd546740c0700"}
App.vue?3495:91 {hashes: 1024}
App.vue?3495:91 {hashesPerSecond: 13.838196882945791, hashes: 4, job_id: "308118890388868", nonce: "03ee4880", result: "a687e1cc195ed34b4410812a5ea8bcbec571cf3ecc0a91d336edcb0daa589300"}
App.vue?3495:91 {hashes: 1280}hashes: 1280__proto__: Object
App.vue?3495:91 {hashesPerSecond: 14.908843073777344, hashes: 7, job_id: "308118890388868", nonce: "873b42af", result: "fcf14f439b867c3fecc8519dc87389c27e3cda3409de6f3e931997d8c4d14100"}
App.vue?3495:91 {hashes: 1536}
App.vue?3495:91 {hashesPerSecond: 13.362731342286779, hashes: 5, job_id: "308118890388868", nonce: "ddba7158", result: "2b3d3ae28b10ea6bf58d58eb8c0961e9357b34425de19c297702d9f150b8cd00"}
App.vue?3495:91 {hashes: 1792}
App.vue?3495:91 {hashesPerSecond: 14.917665959033595, hashes: 13, job_id: "308118890388868", nonce: "1bbf3976", result: "5b428f6b2c4e83430f871c512ba015030e6936fa897d1c9a716038836e0bd900"}
App.vue?3495:91 {hashes: 2048}

[sunk818]

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.

[Edgy1337]

Its like this,
1000 coin hive shares is 1 coin-hive-stratum share

[vphelipe]

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!

[sunk818]

Your hash rate does not change. Pools calculate by accepted hashes. The rate fluctuates but doesn't increase your hash rate long term.

[cazala]

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)

[cazala]

tl;dr: difficulty doesn't impact on profits or hashrate

[cazala]

regarding the issue with minergate.com that @vphelipe said, I'll be running tests soon to see what the issue is (during the week I have work + school so I don't have much time, but I'll spend some time on the weekend and fix whatever it is the issue).

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:

• Set un an XNP pointing to any pool, and set up XNP to lower the difficulty to the desired 256.

• Mine ETN, for example in uspool.electroneum.com:3333 it's even faster than CoinHive.

[cazala]

regarding this:

App.vue?38cc:92 {hashes: 1}
App.vue?38cc:92 {hashesPerSecond: 14.961996528816833, hashes: 10, job_id: "kZ9rvR46lf3pQmEwRT7CJR3HzCwB", nonce: "73d844fc", result: "2099963f8f8621ee917795d71c40691784fcd12b8d5ecd5d3ff71a978f9c1300"}
App.vue?38cc:92 {hashes: 2}
App.vue?38cc:92 {hashesPerSecond: 15.367356660980754, hashes: 5, job_id: "kZ9rvR46lf3pQmEwRT7CJR3HzCwB", nonce: "0e6652fc", result: "f9ef8f544d8e438e91b5431b49b24d54abb898b0d3532756fbc0760f95b41900"}
App.vue?38cc:92 {hashes: 3}

when using coin-hive-stratum I don't know what the difficulty of the pool you are mining is, that's why when you submit a job, I only send a +1 to the miners (to let them know the job was accepted), but actually to work in the same way as CoinHive I should add the difficulty (which is 1000 if you mine on suppotxmr.com) so this should look like:

App.vue?38cc:92 {hashes: 1000}
App.vue?38cc:92 {hashesPerSecond: 14.961996528816833, hashes: 1000, job_id: "kZ9rvR46lf3pQmEwRT7CJR3HzCwB", nonce: "73d844fc", result: "2099963f8f8621ee917795d71c40691784fcd12b8d5ecd5d3ff71a978f9c1300"}
App.vue?38cc:92 {hashes: 2000}
App.vue?38cc:92 {hashesPerSecond: 15.367356660980754, hashes: 2000, job_id: "kZ9rvR46lf3pQmEwRT7CJR3HzCwB", nonce: "0e6652fc", result: "f9ef8f544d8e438e91b5431b49b24d54abb898b0d3532756fbc0760f95b41900"}
App.vue?38cc:92 {hashes: 3000}

but since the proxy doesn't know the difficulty where you are mining on, I can't hardcode a +1000 there becuase it won't be accurate on other pools than supportxmr.com

That's why I left it like just +1

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

[cazala]

tl;dr: don't look at the miner's stats, look at the pool's stats

[boid-com]

Great, thanks for the explanation everyone. Thanks for this useful tool.

[sunk818]

tl;dr: difficulty doesn't impact on profits or hashrate
I'll respectfully disagree. I think we have to understand how frequently blocks are found on the network. If the difficulty is set too high, you will not hash fast enough to submit any shares. The block changes and you have to start hashing again. If the blocks change fast enough, you will rarely submit an acceptable share. Difficulty is less of an issue if you can submit at least one share per round. Take your conclusion to its logical end and set your difficulty at 100k. Why doesn't a client that hashes 10 H/s use a difficulty of 100k? At the same time, you don't want to high end client using a fixed difficulty of 256. I think variable difficulty ends up giving you more acceptable hashes overall and keeps bandwidth requirements to a minimum.

[cazala]

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

[boid-com]

What about this config param from the readme, would this override the difficulty from the connected pool?
diff: a fixed difficulty for all the miners.

[sunk818]

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.

[cazala]

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)

[vphelipe]

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.
I believe that coinhive has its own pool as they have a great hashrate.
My idea was as follows, I'm created a pool that accepts multiple connections from miners and have low difficult.

Pool: pool.elitexmr.com
Port: 8080
Difficulty: 100

I set up for automatic payments when I reach the minimum of 0.3.
I hope that anyone who has difficulty with other pool can enjoy with this without problems.

[Edgy1337]

@vphelipe We are working on a own pool at this moment.

[vphelipe]

@CineXMike Ok, I just wanted to help people with the same problems as me.
bye

[cazala]

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

[procloud]

can anyone else comfirm 20% lower hash rates adding a node proxy to the architecture?

[Wellnel]

so what if this is the total hashes 78 accepted hashes 256