Topic: Pooled mining: how is a share value computed? (Read 1257 times)
Thank you!
If my understanding is correct, this implies the exceeding difficulty bits are effectively not counted or, in other words, a share "value" is always considered to be the target diff or, in other words, that pool is rewarding in a "binary" way exactly like network.
Right.
H = hash(header)
(H < T) means it is a valid bitcoin block header (and can be broadcast to the network)
Share target is N * T.
(H < N*T) means that it is a valid share.
The miner gets credit for the share (worth 1/N of a block), but otherwise, the pool throws away shares (unless they are also valid bitcoin headers).
Different miners can have different N values. A powerful miner would have low N (so harder shares). This means that they submit fewer shares to the pool and use less bandwidth. Each of those shares would be worth a larger fraction of a block.
If my understanding is correct, this implies the exceeding difficulty bits are effectively not counted or, in other words, a share "value" is always considered to be the target diff or, in other words, that pool is rewarding in a "binary" way exactly like network.
This would definitely explain why miner would compute work utility based on the difficulty target only and it sure simplifies a few things.
Would consider the "true" share difficulty make any sense?
This would definitely explain why miner would compute work utility based on the difficulty target only and it sure simplifies a few things.
Would consider the "true" share difficulty make any sense?
For each potential share, a block header is created. The hash of the header is converted into a number from 0 to 2256-1. These numbers are effectively random numbers. There is no way to work out what they will be other than just running the hash function over and over.
In most cases, for each new potential share, you just need to increment the 4 byte "nonce" field in the header you used for the previous attempt. When you hit the max value, you need to generate a whole new header. You do this by changing the coinbase transaction and recomputing the merkle root in the header.
With stratum, all this can be done by the miner itself. The pool tells your computer how to generate new headers, and for each one, you can make 232 attempts at creating a share.
In order for the share to be a valid bitcoin block, the value of the hash must be less than the target value. The target is determined by the bitcoin network so that one block is created every 10 mins or so.
The problem is that this could take ages and miners would rarely get paid.
The solution is to prove to a pool that you are mining their headers. These headers pay the pool, so you are doing work for the pool's benefit.
In order to prove to the pool that you are doing work for them, they increase the acceptable target.
If the share target is 1000 times higher than the bitcoin target, then it is 1000 times easier to find a valid share than to find a valid bitcoin block.
For every 1000 shares the pool receives, they will get around 1 valid block. They don't actually combine the shares at all. It is just that there is a 0.1% chance that a share will end up being a valid block.
The pool can adjust how easy they make the shares. If shares are to easy, then miners would waste bandwidth sending in lots of low value shares. OTOH, if they are to difficult, then it might take miners days to get even one share. Pools have to find a middle ground when they are deciding how difficult to make the shares.
If shares are N times easier to get, then each share is 'worth' one Nth of a block.
In most cases, for each new potential share, you just need to increment the 4 byte "nonce" field in the header you used for the previous attempt. When you hit the max value, you need to generate a whole new header. You do this by changing the coinbase transaction and recomputing the merkle root in the header.
With stratum, all this can be done by the miner itself. The pool tells your computer how to generate new headers, and for each one, you can make 232 attempts at creating a share.
In order for the share to be a valid bitcoin block, the value of the hash must be less than the target value. The target is determined by the bitcoin network so that one block is created every 10 mins or so.
The problem is that this could take ages and miners would rarely get paid.
The solution is to prove to a pool that you are mining their headers. These headers pay the pool, so you are doing work for the pool's benefit.
In order to prove to the pool that you are doing work for them, they increase the acceptable target.
If the share target is 1000 times higher than the bitcoin target, then it is 1000 times easier to find a valid share than to find a valid bitcoin block.
For every 1000 shares the pool receives, they will get around 1 valid block. They don't actually combine the shares at all. It is just that there is a 0.1% chance that a share will end up being a valid block.
The pool can adjust how easy they make the shares. If shares are to easy, then miners would waste bandwidth sending in lots of low value shares. OTOH, if they are to difficult, then it might take miners days to get even one share. Pools have to find a middle ground when they are deciding how difficult to make the shares.
If shares are N times easier to get, then each share is 'worth' one Nth of a block.
Not to be confused with: how shares are paid, which is another issue.
I've been trying to understand this whole share difficulty thing. The way open source miners (cgminer derivatives) compute this is a bit hard to follow due to the code being quite sparse but what doesn't make any sense to me is the way the effective numbers are produced.
This discussion is related to the "work utility" concept.
My understanding is that pools allow low-hash miners to work by
My understanding is that the hash produced by the candidate nonce is interpreted as a number. This is considered valid if exceeding the target. In direct network mining, nothing else would be relevant as the network either gives you a reward or not.
In stratum mining instead, everything goes on difficulty, and the candidate nonce is sent if it exceeds the server difficulty. Miners usually pull a message such as
Now, when I looked at sgminer data to work utility computations it appeared to just consider the base server difficulty. That is, the above share would have difficulty 2. It seemed like the "extra" difficulty to not count.
This is a bit broken in my opinion but I have no idea how the servers really add up those values either. Can you elaborate?
I've been trying to understand this whole share difficulty thing. The way open source miners (cgminer derivatives) compute this is a bit hard to follow due to the code being quite sparse but what doesn't make any sense to me is the way the effective numbers are produced.
This discussion is related to the "work utility" concept.
My understanding is that pools allow low-hash miners to work by
- Using a lower difficulty for magic number submission
- Allowing miners to build a "share" out of multiple submissions (it is unclear to me if this is still lower than real network diff, seems so; I haven't fully understood the way stratum miners compute network difficulty)
My understanding is that the hash produced by the candidate nonce is interpreted as a number. This is considered valid if exceeding the target. In direct network mining, nothing else would be relevant as the network either gives you a reward or not.
In stratum mining instead, everything goes on difficulty, and the candidate nonce is sent if it exceeds the server difficulty. Miners usually pull a message such as
Code:
Accepted 2922e87f Diff 6.223/2.000 GPU 0
^^^^^^^^^^^
Now, when I looked at sgminer data to work utility computations it appeared to just consider the base server difficulty. That is, the above share would have difficulty 2. It seemed like the "extra" difficulty to not count.
This is a bit broken in my opinion but I have no idea how the servers really add up those values either. Can you elaborate?
Jump to: