Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 754. (Read 5805728 times)

Are you telling me a pool can universally throw out enough work for every single miner working for it in the microsecond after sending out a longpoll at a rate fast enough to guarantee their GPUs don't go idle? Let's close the discussion before I get more annoyed.

I can't think of a scenario where a longpoll should make a miner wait for work.

Waiting for work DOES hurt the miner. That's why cgminer tries to tell if some of the work shouldn't actually be discarded by determining if it's from the valid next block and should only throw out work that's from the previous block. However you dress it up for me to support your pool better, there is likely to be more downtime waiting for work by blindly supporting LP for this shit. Admittedly since every pool has taken a hashrate hit lately, none are close to capacity any more, but one day they will be again.

Throwing out work doesn't/shouldn't hurt miners. Issuing more work than necessary hurts the pool (CPU time), but in this case the pool has already taken the hit.

That's not true. cgminer can detect block changes before it receives a longpoll, especially when mining on multiple pools at once. Thus it will have already thrown out the work. Getting a longpoll again after that will make cgminer throw out yet more work. Why do you think I've been resisting dealing with this fucking issue?

This is not correct. Eligius does not longpoll for NMC block changes, but it does for other unrelated purposes. That being said, ignoring those will not hurt the miner (at least right now) who is only interested in obtaining bitcoins (though it can harm the bitcoin network).
There is no benefit to ignoring longpoll results.

The data clearly does not support your claim. Hell, we have basically half our hash power on a pool without (disclosed) merged mining.

Hmm yep oh well I looked at http://blockexplorer.sytes.net/
Which is wrong. Thanks for the link with the correct value

I'm loathe to adding yet more confusing command line options when many people mine blindly with defaults.
I'm also unhappy about throwing out work blindly whenever a LP comes without it actually being a real block change.
I'm most unhappy going out of my way to support another network, whatever it is.
However, having sane defaults and the most efficient mining on BTC are my desired endpoints.
If someone is merged mining, they will receive a lot more longpolls if I'm not mistaken.
If they're not merged mining the longpolls should match block changes and whatever other reasons the pools actually use - It's my impression that they're all theoretical arguments and non merged-mining pools ONLY use longpoll for a block change.
Therefore, throwing out work blindly with a longpoll that doesn't have a corresponding detected block change, without adding any more command line options, is the most unobtrusive change that I can think of and I will do so in the next version.

Merged mining discussion is now closed. Thank you all for your prompt submissions.

1) A LP doesn't cause a stale.  Stales are determined by the pool.  If the block is still valid for BTC the pool shouldn't consider it stale.  The pool may improperly consider the BTC share stale but that will happen no matter what cgminer does.  If cgminer ignores the LP and keeps mining the pool will still consider the share invalid if its stale logic is flawed.

As a practical example though, Sush pool doesn't consider a share to be stale even if it is invalid for the current NMC block as long as it is valid for the BTC block.  So regardless of if cgminer ignores the LP or not the share would be considered valid however if it ignores the LP it is no longer working on valid NMC hashes.  Now currently Slush doesn't have seperate stale count for NMC shares so they are considered valid BUT it lowers the overall pool efficiency because all those shares after the LP and before next getwork() can't produce valid NMC blocks.

2) NMC difficulty is currently ~156K and rising fast.  

Current ratio is ~9:1
On 10/31 it will be ~7:1
On 11/03 it will be ~5:1

It is likely more pools will adopt merged mining.  BTC Guild is looking into merged mining so when they implement it that single pool is >1GH which would put the hashrate ratio ~3:1 (although it will take at least one diff adj for ratio to catch up).  Ultimately if NMC hashrate ever reached 51%+ of BTC then the number of NMC : BTC blocks would be <2:1.

http://dot-bit.org/tools/nextDifficulty.php

Firstly to both of you.
Look at the output of your miner.
Where do stales occur?


Secondly: no that 15 times was based of the current blocks when I typed it.
I'll do it again:
BTC difficulty = 1468195.4272208 (and will be for about another 2 days)
NMC difficulty = 94037.337 (block 24191)

1468195.4272208 / 94037.337 = 15.61...

Edit: and the obvious: an LP and a work request are two completely different things.

No it doesn't.  There is no lost work, prior work has absolutely no value.  You either have a solution or you have nothing.


Most miners get new work many times per minute even w/o LP.  My rigs are 2GH/s and I pull 20+ getworks per minute.  A few more LP is insignificant.  Also it is closer to 9NMC blocks per BTC block now.  As NMC hash rate continues to climb and the cost to merged mine drops the # of NMC blocks per BTC will decline likely in the future become <2 NMC : 1 BTC.

Wrong, stales happen because you DONT throw the work away fast enough. Namecoin through merged mining can't generate stales.

... hmm that's an interesting argument against merged mining
An LP represents a loss of work.
Throw away your incomplete work (or stop it and throw it away) and start new work.
This is where most stales occur and thus the related issues.

So merged mining adds many more of these
Actually a lot more since one will occur every namecoin block which is currently 15 times per bitcoin block
Hmm yep so I'd expect a 15 times increase in bitcoin stales due to merged mining if you force people bitcoin mining to take notice of namecoin mining block changes.

LP is used to indicate a change in block for miner to hash.

There are many reasons this can be used.
1) New block has been found
2) New transactions have been added to block
3) Merged Mining hash has changed
4) As a countermeasure against "block withholding attack"
5) ... (any other reason pool determines block header should change)

The most common reason for LP is because a new block has been found but that isn't the only reason.  Even without merged mining it is very likely pools will have reason to indicate a block change.  As block rewards decline and transaction fees hopefully increase pools will need to maximize transaction fee value and may indicate a change in block because they hashed in a high fee transaction.

The threat of "block withholding" may become more prevalent in the future.  A countermeasure for that is for the pool to issue a found block to pool members and if they "fail to find the hash" then flag them as potential attackers.  If cgminer doesn't properly respond to blocks changes via LP it would improperly make it look like those miners are withholding blocks.

Lastly there may be as of yet unknown reasons why pool may need to change the block that miners in the pool are working on.  Regardless of the reason the miner should change when given new block data.

Even if merged mining didn't exist the proper response to a miner receiving an updated block via LP is to work on that block.  If your hatred of merged mining didn't blind you then you would see cgminer's response is flawed and should be fixed regardless.

https://deepbit.com/longpolling.php

You don't see the problem there ... ?

Show me the documentation ...

So why not implement a new notification rather than mess up LP so it no longer does what it was designed to do ....

Well yes even the people who documented it didn't even get it right ... but when asked to correct it they wont.
However ... "save any software bugs that crop up while adding the feature" is probably the whole point of this discussion
So fobbing it of as something minor shows a lack of understanding of the whole discussion ...

Namecoin is ONLY leveraging off Bitcoin - there is no such hyperthetical other way around.
As I said before, if not for merged mining, namecoin would die since most people don't want it.
If enough people wanted it, then it wouldn't have been dying in the first place.

The same is true of Bitcoin itself.
If most people don't want it and use it, it will die.
Simple.
Unfortunate for those who want it and use it, but if there aren't enough to keep it alive, it dies.
At the moment it is staying alive - good for everyone here and myself.
If people don't back it and use it, but instead leverage off it and take away it's value by trying to keep alive something that most people don't want, then that will hurt Bitcoin exactly as do scamcoins.

The code commit to add merged mining also allows for EXACTLY this you are saying is bad. EXACTLY this.

That's a strange argument in favour of it
Basically saying that if (though it wont happen) Namecoin reaches Bitcoin then ...
So you are arguing against Bitcoin

Simple: It takes it from Bitcoin.
They are free coins thus with no value - where do they get value? By taking it from Bitcoin.

Again, this is exactly what the commit that went into Bitcoin to allow for merged mining to work with the base code also allows to occur with the base Bitcoin code.

They never do. It is impossible to detect merged mining on the miner end.
No, the definition of LP is to notify miners of new blocks, which could have the "prevblock" header changed-- or might not. As others have noted, there are plenty of other reasons a pool might do a longpoll without changing "prevblock". When receiving a LP response, miners are supposed to discard their old work (it's "stale", which is a term defined by your particular pool) and start working on the new work provided. Not doing so is a bug. Since most miners don't have this bug, it would fit in the "makes cgminer not the best bitcoin miner" category.

There is no such thing as a bad NMC hash in relation to this.
It has nothing to do with hashing.
It has to do with the pool sending back information about different chains ...

The definition of LP is to notify of a block change - LP in itself is badly implemented but that is how it has been done.
How this hack has been added on top of LP ... well I wonder if it is even works properly ...