Bitcoin Forum
November 10, 2024, 02:43:39 PM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: How do pools ensure participants return their successful hashes?  (Read 964 times)
bitcredit (OP)
Member
**
Offline Offline

Activity: 78
Merit: 10


View Profile
June 12, 2011, 07:53:12 AM
 #1

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.
Artefact2
Full Member
***
Offline Offline

Activity: 123
Merit: 100


View Profile WWW
June 12, 2011, 07:56:03 AM
 #2

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.

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.

A pool-biased blockchain representation, by me: pident (WTFPL)
bitcredit (OP)
Member
**
Offline Offline

Activity: 78
Merit: 10


View Profile
June 12, 2011, 07:57:56 AM
 #3

Thanks!

Is this because the pool's address is already included in the block of data for which a hash is being generated?
Artefact2
Full Member
***
Offline Offline

Activity: 123
Merit: 100


View Profile WWW
June 12, 2011, 08:02:20 AM
 #4

Thanks!

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.

A pool-biased blockchain representation, by me: pident (WTFPL)
Mike 71
Newbie
*
Offline Offline

Activity: 46
Merit: 0


View Profile
June 12, 2011, 08:04:30 AM
 #5

Thanks!

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.
BombaUcigasa
Legendary
*
Offline Offline

Activity: 1442
Merit: 1005



View Profile
June 12, 2011, 08:05:10 AM
 #6

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.
bitcredit (OP)
Member
**
Offline Offline

Activity: 78
Merit: 10


View Profile
June 12, 2011, 08:07:38 AM
 #7

Thanks!

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?
Artefact2
Full Member
***
Offline Offline

Activity: 123
Merit: 100


View Profile WWW
June 12, 2011, 08:09:19 AM
 #8

Thanks!

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.

A pool-biased blockchain representation, by me: pident (WTFPL)
bitsalat
Newbie
*
Offline Offline

Activity: 2
Merit: 0


View Profile
September 25, 2013, 09:57:02 AM
 #9


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?
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!