Topic: How do pools ensure participants return their successful hashes? (Read 964 times)
The calculated Hash hashes also the transaction to the pool address. If you change the pool address, the Hash will change.
[/quote]
Well, what if you generate a hash that meets the difficulty criteria but by that time the pool's closed? Does that mean the coins go to a dead address and are lost forever?
[/quote]
No, nothing happens.
[/quote]
Because the pool only gets the reward if it publishes the calculations?
What happens if a poolmember doesn't finish it share of calculations?
Beeing to slow or offline?
What will happen then?
Will the calculation become assigned to another poolmember?
Thanks!
Is this because the pool's address is already included in the block of data for which a hash is being generated?
Is this because the pool's address is already included in the block of data for which a hash is being generated?
I'm not familiar with the internals, but the solution you find will only work for the pool, yes.
Thats the exact reason, right.
The calculated Hash hashes also the transaction to the pool address. If you change the pool address, the Hash will change.
Well, what if you generate a hash that meets the difficulty criteria but by that time the pool's closed? Does that mean the coins go to a dead address and are lost forever?
No, nothing happens.
Thanks!
Is this because the pool's address is already included in the block of data for which a hash is being generated?
Is this because the pool's address is already included in the block of data for which a hash is being generated?
I'm not familiar with the internals, but the solution you find will only work for the pool, yes.
Thats the exact reason, right.
The calculated Hash hashes also the transaction to the pool address. If you change the pool address, the Hash will change.
Well, what if you generate a hash that meets the difficulty criteria but by that time the pool's closed? Does that mean the coins go to a dead address and are lost forever?
Thanks!
Is this because the pool's address is already included in the block of data for which a hash is being generated?
The pool already has the transactions it wants to perform ready and will pay you to validate them. The pool only sends you a hashed version of them. You need to know the exact set and order of transactions the pool has in mind to use the solution for yourself. Is this because the pool's address is already included in the block of data for which a hash is being generated?
Thanks!
Is this because the pool's address is already included in the block of data for which a hash is being generated?
Is this because the pool's address is already included in the block of data for which a hash is being generated?
I'm not familiar with the internals, but the solution you find will only work for the pool, yes.
Thats the exact reason, right.
The calculated Hash hashes also the transaction to the pool address. If you change the pool address, the Hash will change.
Thanks!
Is this because the pool's address is already included in the block of data for which a hash is being generated?
Is this because the pool's address is already included in the block of data for which a hash is being generated?
I'm not familiar with the internals, but the solution you find will only work for the pool, yes.
Thanks!
Is this because the pool's address is already included in the block of data for which a hash is being generated?
Is this because the pool's address is already included in the block of data for which a hash is being generated?
My understanding is that pools pay participants based on the number of "near misses" they submit while the pool itself is only able to post a successful block if one of the participants submits a hash that meets the current difficulty level.
What's to stop a peer from reporting all of its near misses but keeping the winning hash for itself if it happens to find one? This seems like an ideal strategy since the peer is guaranteed a payout from the pool for all the blocks it doesn't get based on its share, but will also get the full payout for the few blocks it does happen to get.
What's to stop a peer from reporting all of its near misses but keeping the winning hash for itself if it happens to find one? This seems like an ideal strategy since the peer is guaranteed a payout from the pool for all the blocks it doesn't get based on its share, but will also get the full payout for the few blocks it does happen to get.
If you contribute a pool, you can withhold shares that meet the difficulty criteria, yes. But you cannot use them to win the 50 BTC only for you : the solution only works for the pool.
This is not really a problem on proportional-type pool, it just makes the round longer. But it is very dangerous on pay-per-share-type pools : by withholding solutions, it's like the pool is always having "bad luck", and the pool operator always pays more than 50 BTC per round.
My understanding is that pools pay participants based on the number of "near misses" they submit while the pool itself is only able to post a successful block if one of the participants submits a hash that meets the current difficulty level.
What's to stop a peer from reporting all of its near misses but keeping the winning hash for itself if it happens to find one? This seems like an ideal strategy since the peer is guaranteed a payout from the pool for all the blocks it doesn't get based on its share, but will also get the full payout for the few blocks it does happen to get.
What's to stop a peer from reporting all of its near misses but keeping the winning hash for itself if it happens to find one? This seems like an ideal strategy since the peer is guaranteed a payout from the pool for all the blocks it doesn't get based on its share, but will also get the full payout for the few blocks it does happen to get.
Jump to: