Bitcoin Forum
May 05, 2024, 01:40:05 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: ELI5: Pool luck rate  (Read 4884 times)
AsdQ89 (OP)
Newbie
*
Offline Offline

Activity: 57
Merit: 0


View Profile
January 16, 2017, 09:59:58 AM
Last edit: January 16, 2017, 02:16:20 PM by AsdQ89
 #1

Ok, so for a newbie in this mining pool buisness, this is what I would love to know:

1) What is Pool luck?
2) How is it calculated?
3) What does it mean for a potential miner/invester in that pool?

Further questions, if any, will be added below.

4) How often should a pool statistically find a block, or how long is the statistic time between each block?
5) How is a pool defined as unlucky/lucky?
Even in the event that an attacker gains more than 50% of the network's computational power, only transactions sent by the attacker could be reversed or double-spent. The network would not be destroyed.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1714916405
Hero Member
*
Offline Offline

Posts: 1714916405

View Profile Personal Message (Offline)

Ignore
1714916405
Reply with quote  #2

1714916405
Report to moderator
xhomerx10
Legendary
*
Offline Offline

Activity: 3836
Merit: 7993



View Profile
January 16, 2017, 01:17:56 PM
 #2

Ok, so for a newbie in this mining pool buisness, this is what I would love to know:

1) What is Pool luck?
2) How is it calculated?
3) What does it mean for a potential miner/invester in that pool?

Further questions, if any, will be added below.

 1) mining is probabilistic in nature, if you find a block earlier than you statistically should on average you are lucky if it takes longer, you are unlucky
 2) not possible to ELI5 - Cumulative Distribution Function requires advanced mathematics
 3) nothing as it is random and unpredictable - though if it is continually unlucky perhaps you should avoid the pool
AsdQ89 (OP)
Newbie
*
Offline Offline

Activity: 57
Merit: 0


View Profile
January 16, 2017, 02:16:09 PM
 #3

Ok, so for a newbie in this mining pool buisness, this is what I would love to know:

1) What is Pool luck?
2) How is it calculated?
3) What does it mean for a potential miner/invester in that pool?

Further questions, if any, will be added below.

 1) mining is probabilistic in nature, if you find a block earlier than you statistically should on average you are lucky if it takes longer, you are unlucky
 2) not possible to ELI5 - Cumulative Distribution Function requires advanced mathematics
 3) nothing as it is random and unpredictable - though if it is continually unlucky perhaps you should avoid the pool


Many thanks for the great reply, already learned alot.

Now for the follow up question:

4) How often should a pool statistically find a block, or how long is the statistic time between each block?
5) How is a pool defined as unlucky/lucky?
xhomerx10
Legendary
*
Offline Offline

Activity: 3836
Merit: 7993



View Profile
January 16, 2017, 06:43:24 PM
Last edit: January 16, 2017, 08:58:09 PM by xhomerx10
 #4

 The probability of mining a block is 1/(232*D) for each hash.  (D is Bitcoin difficulty) so the amount of time is dependent on the hash rate and luck.  Difficulty is currently 336899932796.  Let's invert the equation to see how many hashes are required (on average) to mine a block.

 #hashes = 232*336899932796
 #hashes = 1,446,974,193,383,417,839,616

Let's use Slush's pool.  Their stated hash rate is 154.9 Ph/s so,

 time to block = 1,446,974,193,383,417,839,616/154.9X1015Ph/s
 time to block = 9341.3 seconds (or about 2 hours 35 minutes and 41.3 seconds)

 Now look at a screen capture of Slush's public statistics:



 Compare the actual time taken to find a block (under the reading glasses) with the calculated time of 2:35:41.3 and then check out the associated luck (under the sunglasses).  As you can see, if blocks take longer than determined based on probability to find, the percentage luck is <100% and when the block is found sooner, luck is >100% in the long run though based on the Law of large numbers,  the average time to find a block should be very close to the calculated value.

 If a pool is consistently below 100%, one would consider it unlucky and if it is consistently above 100%, one would consider it lucky.  This can happen for periods of time when a pool has only a small percentage of the total network's hash rate but as I said, in the long run, it should even out.

AsdQ89 (OP)
Newbie
*
Offline Offline

Activity: 57
Merit: 0


View Profile
January 17, 2017, 04:22:45 PM
 #5

First of all, xhomerx10 is my new favorite user OF ALL TIME for using the most legendary reference system EVER!

Second of all, great explanation. I kinda get how "luck" isn't the traditional luck we all know and associate with four leaf clovers and rabbits feet.

6) Is it correct to define a mining pools luck as: mining pools efficiency in comparison to an ideal hashing of a block?
7) How is blocks allocated to different pools/miners, who/what makes sure that two miners arent hashing the same part of a block?

Sorry for getting a bit more complicated with the questions, but this is really interesting stuff and you guys are great teachers.
xhomerx10
Legendary
*
Offline Offline

Activity: 3836
Merit: 7993



View Profile
January 18, 2017, 03:29:01 AM
 #6

Thanks for the recognition.  I enjoy helping others... but on occasion I enjoy a bit of trolling too  Shocked  You caught me on a good day.

 6) I would say that's exactly it!

 7) The pool decides what transactions will be included in the block it attempts to mine.  Pools will generally select the transactions they want to include in the block based on the fees paid.  Usually there is a large number of unconfirmed transactions on the network to select from so these blocks will be different for each pool.  Even if they were to select exactly the same transactions using the same timestamp, the block will still be different because the first transaction in every block called the coinbase transaction is generated by the pool (or the miner in general) which collects and spends the block reward plus transaction fees.  This transaction will be unique to the pool and generally the coins will go to an address controlled by the pool.  This also prevents pool members from capturing the "winning" result for their own gain.

 From the perspective of the pool, I believe each member of the pool is assigned a different extranonce value (which is part of the coinbase transaction) to prevent duplication of work among pool members.  It's a little more complicated than that because as miners got faster, it was possible to hash the block with all 232 nonce values in milliseconds.  I believe this is why Slush developed the Stratum mining protocol.
AsdQ89 (OP)
Newbie
*
Offline Offline

Activity: 57
Merit: 0


View Profile
January 18, 2017, 07:55:53 AM
 #7

Wow interesting.

I think we misunderstood each other a bit in question 7), but your answer just taught me soo much more than I had expected. I think the misunderstand is caused by my idea that blocks were gathered and controlled by the coinbase and not by the pool, so this brings up a couple of more questions. Again thanks for the help:

8 ) So is it correct that the individual pool (or in solo mining cases, the miner) that gathers each transaction in to blocks and then hashes that block for the block reward and transaction fee?
9) If each pool/miner chooses what transactions to put in their blocks (ofcourse prioritizing those with the highest fees attached to them), are there then a large "sea" of unconfirmed transactions with too low fees?
10) Is it correct to assume that a block must contain 232*D hashes of transactions before it can be hashed, or what controls that each block contains the necessary amount of transactions in order to claim the block reward?

I will now roll the dice and hope that the troll will continue to sleep soundly in his cave.
xhomerx10
Legendary
*
Offline Offline

Activity: 3836
Merit: 7993



View Profile
January 19, 2017, 05:44:31 PM
 #8

Wow interesting.

I think we misunderstood each other a bit in question 7), but your answer just taught me soo much more than I had expected. I think the misunderstand is caused by my idea that blocks were gathered and controlled by the coinbase and not by the pool, so this brings up a couple of more questions. Again thanks for the help:

8 ) So is it correct that the individual pool (or in solo mining cases, the miner) that gathers each transaction in to blocks and then hashes that block for the block reward and transaction fee?
9) If each pool/miner chooses what transactions to put in their blocks (ofcourse prioritizing those with the highest fees attached to them), are there then a large "sea" of unconfirmed transactions with too low fees?
10) Is it correct to assume that a block must contain 232*D hashes of transactions before it can be hashed, or what controls that each block contains the necessary amount of transactions in order to claim the block reward?

I will now roll the dice and hope that the troll will continue to sleep soundly in his cave.

 Cool Yes.  That is exactly what the miners (pool or solo) do.
 9)The number of unconfirmed transactions varies but there are usually some unconfirmed transactions on the network.  It could be a large amount but not necessarily.   You can check that number here.  Blockchain.info has many Bitcoin queries available online - https://blockchain.info/q

10) No.  The block only needs to contain one transaction called the coinbase transaction.  The data within the block of transactions gets hashed (it's a little complicated) into a what's called a merkle root.  This hash is added to the block header which contains specific information about the block including the winning hash of the previous block and its nonce in order to secure it into the block chain.  Now that block header gets hashed while incrementing the nonce on each successive attempt until the miner obtains a number less than the current target.  This would be a winning hash and the miner that finds it gets the reward. In order to do that, billions of hashes are required but not stored.
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!