Author

Topic: [4+ EH] Slush Pool (slushpool.com); Overt AsicBoost; World First Mining Pool - page 494. (Read 4382714 times)

newbie
Activity: 42
Merit: 0
How long till the end of maintanance?
full member
Activity: 206
Merit: 100
legendary
Activity: 1750
Merit: 1007
Did Slush stop NMC support?

Yes, Slush never added NMC to his stratum implementation.  For a while getwork still mined NMC blocks, but since getwork shutdown Slush has not done any NMC merged mining.
full member
Activity: 206
Merit: 100
Did Slush stop NMC support?
sr. member
Activity: 311
Merit: 250
The hashes a miner calculates are exactly the same no matter what diff.
The only difference is, that _after_ the calculations, the mining software compares the _result_ of the calculation to the diff, and decides whether to send it or not. For the slow miner in the example, the software will send all hashes with diff at least one. For the fast miner, it will send all hashes with diff at least 16.

The 609482679 does not concern your miners at all. If they find a share with diff higher or equal to that, it will be send to the server, since its higher than 16 or 1. The server will see its high enough to satisfy current network diff, and publish it as new block found. You can enjoy a warm feeling, cause it was your miner who found the share. Thats all.

Maybe one should add that there's only 1 to 232 probability that the hash just calculated is of difficulty one (or higher).
member
Activity: 93
Merit: 10
Great, now I understand. Cheesy

Thanks a lot.
hero member
Activity: 707
Merit: 500
Now the slower miner will transmit nounces, which would be dropped by the faster miner.

Thats correct.
If the slow miner calculates a hash with diff 10, this will be submitted.
If the fast miner does, it will be dropped, and only hashes with diff >= 16 will be submitted.

Will the vardiff just be added to the difficulty? So the faster miner would get 609482679 + 15?

No.
A miner does not "get" a difficulty.
The hashes a miner calculates are exactly the same no matter what diff.
The only difference is, that _after_ the calculations, the mining software compares the _result_ of the calculation to the diff, and decides whether to send it or not. For the slow miner in the example, the software will send all hashes with diff at least one. For the fast miner, it will send all hashes with diff at least 16.

The 609482679 does not concern your miners at all. If they find a share with diff higher or equal to that, it will be send to the server, since its higher than 16 or 1. The server will see its high enough to satisfy current network diff, and publish it as new block found. You can enjoy a warm feeling, cause it was your miner who found the share. Thats all.

If you were to mine solo, not using a pool, its a little different. Your mining software would not drop all shares below 16, but all below 609482679. Those above would not be send to the pool server, but get published directly to the network, and your warm feeling for finding the hash would be worth 25 BTC plus block fees. But in this case, you would get _nothing_ for all the other shares, whereas you get still paid for all the actually useless shares below 609482679 when mining with a pool, since they proof you tried to find the winning one for the pool.
member
Activity: 93
Merit: 10
Yes, I don't understand these. Thank you for your help, hope I will get it soon  Wink

As Example, there are 2 miners, one is slow and gets vardiff 1 and the other is faster with vardiff 16.
The difficulty is 609482679

Both get the same input (hash, data and midstate) but a different target due to the different vardiff.

Now the slower miner will transmit nounces, which would be dropped by the faster miner.
Will the vardiff just be added to the difficulty? So the faster miner would get 609482679 + 15?



hero member
Activity: 707
Merit: 500
Thank you for your explanation. I understand, that the mining will be calculated with a higher difficulty than the actual difficulty.
Nonces will be dropped, if the hash result fullfill the actual difficulty, but not the increased vardiff.
But one of these dropped nounces may solve the block. Since they are not transmitted, it will not be checked.
Yes, there is a bunch of valid nounces, so the block will still be solved, but later.


Ah, i guess i see where you misunderstood something.
But the terms to address several difficulties are a bit confusing.

We have minimum diff, thats 1.
We have the current network diff, thats the diff a hash has to fulfill to solve a block, currently some 600 million.
And there's your workers vardiff set by the pool, 16 for example.

The nounces getting dropped can never ever solve a block, cause their diff is somewhere between 1 and 16.
Those nounces submitted to the pool as share have any diff higher than 16.
Eventually, one of those billions and billions of shares will have a diff not only higher than 16, but also higher than 600 million.
That one solves the block, and we move to the next pool round.

member
Activity: 93
Merit: 10
There is nothing like "the golden nounce" which could accidentally get skipped.
Theres a bunch of nounces who satisfy given network diff for the actual block with given transactions to be included in the block.
Which nounce solves the block changes all the time, as new transactions get included in the data we are hashing.

As for slush, you can no longer set the diff manually, the server sets your workers diff based on the workers speed.
Workers are not working with/on/for a special diff value, because the diff is per design something which can only be known _after_ the hash is calculated - thats the trick, after all, you cant decide which diff your result should fulfill, you have to try until you find one fitting your needs.

Your worker-specific diff value just does two things:
Tell your mining software, which shares to send to the server (all with diff equal or higher to your userdiff) and which to drop (all with lower diff).
Tell the server, how high your score for each share should be, the higher your diff, the higher the score.

That way, with higher diff you send less shares to the server but get higher score for each, and with lower diff you send more shares but get lower score. Over some time, this equals out. Higher diff is a little more variance, but a little less traffic to the server, so what the pool does by setting your diff is forcing you to accept a marginal higher variance in your earnings, which will still equal out quite fast, but reducing the server load at the same time, cause the pool will no longer get flooded with low diff shares by miner which hash too fast.

Thank you for your explanation. I understand, that the mining will be calculated with a higher difficulty than the actual difficulty.
Nonces will be dropped, if the hash result fullfill the actual difficulty, but not the increased vardiff.
But one of these dropped nounces may solve the block. Since they are not transmitted, it will not be checked.
Yes, there is a bunch of valid nounces, so the block will still be solved, but later.

hero member
Activity: 707
Merit: 500
There is nothing like "the golden nounce" which could accidentally get skipped.
Theres a bunch of nounces who satisfy given network diff for the actual block with given transactions to be included in the block.
Which nounce solves the block changes all the time, as new transactions get included in the data we are hashing.

As for slush, you can no longer set the diff manually, the server sets your workers diff based on the workers speed.
Workers are not working with/on/for a special diff value, because the diff is per design something which can only be known _after_ the hash is calculated - thats the trick, after all, you cant decide which diff your result should fulfill, you have to try until you find one fitting your needs.

Your worker-specific diff value just does two things:
Tell your mining software, which shares to send to the server (all with diff equal or higher to your userdiff) and which to drop (all with lower diff).
Tell the server, how high your score for each share should be, the higher your diff, the higher the score.

That way, with higher diff you send less shares to the server but get higher score for each, and with lower diff you send more shares but get lower score. Over some time, this equals out. Higher diff is a little more variance, but a little less traffic to the server, so what the pool does by setting your diff is forcing you to accept a marginal higher variance in your earnings, which will still equal out quite fast, but reducing the server load at the same time, cause the pool will no longer get flooded with low diff shares by miner which hash too fast.
member
Activity: 93
Merit: 10
Hi,
may someone explain to me please, how userdiff/vardiff is working in detail? I know how to calculate the nounces and how they are compared with the actual difficulty for validation before the miner release the nounces to the mining software.

What I don't understand:
- if a miner calculates with a higher difficulty than the actual difficulty, then the golden nounce may be skipped.
- If a miner calculates with a lower difficulty than the actual difficulty, then invalid nounces will be counted as valid.

Maybe someone can explain to me, how to modify the difficulty per miner.

Thank you

sr. member
Activity: 311
Merit: 250
it definitely is "a lot to grasp" but all the info you are looking for has already been published. google it

its like being in the Unix channel asking a question and the grumps telling u to use MAN. all the answers are in MAN! why ask anything

Why ask simple questions that are fully covered in the man there?
hero member
Activity: 569
Merit: 500
Today is making up for the last few. Loving it!

or.....
maybe something is wrong!
hero member
Activity: 569
Merit: 500
it definitely is "a lot to grasp" but all the info you are looking for has already been published. google it

its like being in the Unix channel asking a question and the grumps telling u to use MAN. all the answers are in MAN! why ask anything
sr. member
Activity: 616
Merit: 321
issent it time for the slush pool to join this ? :

Today, BTC Guild has reduced the minimum MANUAL withdrawal level from 0.01 BTC to 0.001 BTC.
However, any payouts under 0.01 BTC will have the transaction fee (0.0005 BTC) deducted from their payout.
 
This is in response to the steady rise of BTC:USD exchange rates,
which have now made amounts as small as 0.002-0.003 useful as they are worth more than $1.

its a win win situation , i mean "low level"  miners wil have some coins earlyer / recular and de pool get some !  Smiley
sr. member
Activity: 251
Merit: 250
If only we could somewhat control our luck?
sr. member
Activity: 251
Merit: 250
Reward payouts not happening again.... now more than 2 hours above the threshold.... Slush, pleaaaaase Cry

What's your threshold set at? I've upped mine a little, not too worried, I know payouts will happen. I'm more worried about the exchange rate though. How long do we think it will keep this up?
hero member
Activity: 616
Merit: 500
Reward payouts not happening again.... now more than 2 hours above the threshold.... Slush, pleaaaaase Cry
full member
Activity: 188
Merit: 100
It doesn't work that way. It didn't take that long to find a specific block, it took that long to find any block. Every time someone else finds a block, we start looking for a new block based on what they found. That's why we call that 12 hours a round, not a block.

So every time you see "stratum detected a new block" in the miner log would indicate that the hashing power is being spent on solving a block rather than looking for a new one? Unless someone solves that block first. But if you don't see a new block detected for a long while, the hashing power is being spent finding a new one?

How is hashing power divided between looking for new blocks vs solving, is there a ratio set by the pool operator depending on how many active blocks have been found?

-noob.


When you see "stratum detected a new block" it means that someone somewhere in the world found a solution for the current block and that a new block is now being worked on. Solving is looking for new blocks. Different names for the same thing.

The thing is that there is more than one right solution for any given block. All the pools and solo people use different inputs than every one else in hopes that their input will find the desired output. Say your hashrate is 5 Gh/s, that means you are checking 5 million different inputs every second looking for the one output that will complete the block.

Ah, so there is only one active (known) block at a time that all miners are working to solve. Once that is solved, the answer leads to the next block? Also I was a bit thrown on the block vs round. I checked the wiki but will do some more looking.

Sorry if my questions are elementary, I am fairly new and I must say it is quite a lot to grasp. Thank you for taking the time out of your day.
Yes, you have got the blocks down. A round is how long it takes for the pool to find a block. If it took 10 hours for the pool to find a block, that is a 10 hour round. A lot of people will call that a 10 hour block, but that is confusing to new people.

Let me see if I get this myself please? A block is worked on by the entire network and pools. Any pool or miner can solve the block, hence ending their round? Correct? Thus, our round continues until we solve one of these blocks? Hence the 'stratum detected new block?'


I hope to clear this once and for all...... There are multiple pools and solo miners all looking for a block.

If you go to the "Stats" page on the Slush's website.... The far left column is the "ROUND" ID Number....This is since the POOL found a block, not since there is a new block

If you look at the "Block #" column... That is the block on the network.  See how they skip a few?  That is because they were found by someone other than us (Slush's Pool)

Jump to: