Bitcoin Forum
January 21, 2018, 03:25:13 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Poll
Question: What type of pool payouts do you prefer?
Bitcoins - 3210 (80.4%)
Bank transfer / USD - 410 (10.3%)
Gold/silver coins and bars - 371 (9.3%)
Total Voters: 3989

Pages: « 1 ... 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 [776] 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 ... 1132 »
  Print  
Author Topic: [150+ PH] SlushPool (slushpool.com); World's First Mining Pool  (Read 4322211 times)
KNK
Hero Member
*****
Offline Offline

Activity: 667


View Profile
February 26, 2014, 08:18:00 PM
 #15501

Unfortunately there is no relation between the pool size and the luck in the direction you want. It's the opposite ...
When the luck increases - more people are joining, but then it should go down to compensate it and it look like the higher hashrate is causing the bad luck, but it is not. If no new miners join the pool a 12h block will actually take 13h

Why 'unfortunately'? Because if it was true, then a solo miner with CPU, would have much more luck and much bigger reward, then no one would need to join a pool at all.

BTC tips: 1KNK1akhpethhtcyhKTF2d3PWTQDUWUzHE
1516505113
Hero Member
*
Offline Offline

Posts: 1516505113

View Profile Personal Message (Offline)

Ignore
1516505113
Reply with quote  #2

1516505113
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1516505113
Hero Member
*
Offline Offline

Posts: 1516505113

View Profile Personal Message (Offline)

Ignore
1516505113
Reply with quote  #2

1516505113
Report to moderator
anthem
Member
**
Offline Offline

Activity: 70


View Profile
February 26, 2014, 08:40:18 PM
 #15502

Unfortunately there is no relation between the pool size and the luck in the direction you want. It's the opposite ...
When the luck increases - more people are joining, but then it should go down to compensate it and it look like the higher hashrate is causing the bad luck, but it is not. If no new miners join the pool a 12h block will actually take 13h

Why 'unfortunately'? Because if it was true, then a solo miner with CPU, would have much more luck and much bigger reward, then no one would need to join a pool at all.

actually not totally true. .  luck will change regardless of whether people are joining or leaving. . .  agree that higher hash rate is not causing bad luck (or good luck). . .  over time "luck" should be 100 over time. .   However, when you're talking 6 or so samples per day, its possible to have luck be good or bad and not come back to the average for long periods of time. . .  Its not unheard of to have good luck for 25 days or bad luck for 25 days because the sample sizes are too small. ..
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 2044


Poor impulse control.


View Profile WWW
February 26, 2014, 09:07:02 PM
 #15503

Unfortunately there is no relation between the pool size and the luck in the direction you want. It's the opposite ...
When the luck increases - more people are joining, but then it should go down to compensate it and it look like the higher hashrate is causing the bad luck, but it is not. If no new miners join the pool a 12h block will actually take 13h

Why 'unfortunately'? Because if it was true, then a solo miner with CPU, would have much more luck and much bigger reward, then no one would need to join a pool at all.

actually not totally true. .  luck will change regardless of whether people are joining or leaving. . .  agree that higher hash rate is not causing bad luck (or good luck). . .  over time "luck" should be 100 over time. .   However, when you're talking 6 or so samples per day, its possible to have luck be good or bad and not come back to the average for long periods of time. . .  Its not unheard of to have good luck for 25 days or bad luck for 25 days because the sample sizes are too small. ..

Here's how you should calculate and interpret luck: https://bitcointalk.org/index.php?topic=1976.msg5071405#msg5071405


Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
dlefevre
Newbie
*
Offline Offline

Activity: 20


View Profile
February 26, 2014, 11:00:18 PM
 #15504

oh what the fuck.
divinesnail01
Newbie
*
Offline Offline

Activity: 19


View Profile
February 26, 2014, 11:38:14 PM
 #15505

... I kind of like the roller coaster myself. Brings out the good and bad in everyone like a Bitcoin mining soap opera. Over time it's all the same IMHO. There's no magic pool or else everyone would be there.

+1
MrTeal
Legendary
*
Offline Offline

Activity: 1274


View Profile
February 27, 2014, 12:59:49 AM
 #15506

Or you could all just go look at organofcorti's excellent weekly blog post, which lists the luck for most of the major pools.
PostMixer
Jr. Member
*
Offline Offline

Activity: 53


View Profile
February 27, 2014, 04:40:46 AM
 #15507

Or you could all just go look at organofcorti's excellent weekly blog post, which lists the luck for most of the major pools.

+10

I won't ask for donations but I will ask for help. And I won't give donations but I will help if I can.
necro_nemesis
Full Member
***
Offline Offline

Activity: 224


View Profile
February 27, 2014, 05:12:30 AM
 #15508

Trying to chase luck makes about as much sense as granny tiltin' her chair on the slot she's been dropping nickels in because someone else might cash in.
bspurloc
Hero Member
*****
Offline Offline

Activity: 569


View Profile
February 27, 2014, 06:47:08 AM
 #15509

Or you could all just go look at organofcorti's excellent weekly blog post, which lists the luck for most of the major pools.


at least we got 2nd place in orphaned blocks.
binja9
Newbie
*
Offline Offline

Activity: 27


View Profile
February 27, 2014, 07:30:41 AM
 #15510

Unfortunately there is no relation between the pool size and the luck in the direction you want. It's the opposite ...
When the luck increases - more people are joining, but then it should go down to compensate it and it look like the higher hashrate is causing the bad luck, but it is not. If no new miners join the pool a 12h block will actually take 13h

Why 'unfortunately'? Because if it was true, then a solo miner with CPU, would have much more luck and much bigger reward, then no one would need to join a pool at all.


I'm also afraid to tell you that 'luck' does not exist - you can calculate probability but not luck (unless someone could post the calculation for the likelihood of luck existing)...

One certainty is that as the pool grows then so does the traffic into servers and it doesn't matter how much hashing goes on, it has to get to a server and 800-825TH seems to be the current 'lucky' number range.
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 2044


Poor impulse control.


View Profile WWW
February 27, 2014, 08:06:55 AM
 #15511

I'm also afraid to tell you that 'luck' does not exist - you can calculate probability but not luck (unless someone could post the calculation for the likelihood of luck existing)...

'Luck' exists, silly! If you earned more than expected, you've had good 'luck'. If you earned less than expected, you had bad 'luck'.

One certainty is that as the pool grows then so does the traffic into servers and it doesn't matter how much hashing goes on, it has to get to a server and 800-825TH seems to be the current 'lucky' number range.

No, the traffic problem is what vardiff solves.

Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
KNK
Hero Member
*****
Offline Offline

Activity: 667


View Profile
February 27, 2014, 09:06:04 AM
 #15512

One certainty is that as the pool grows then so does the traffic into servers and it doesn't matter how much hashing goes on, it has to get to a server and 800-825TH seems to be the current 'lucky' number range.

No, the traffic problem is what vardiff solves.
True, but binja9 is also right - vardiff solves the problem for a single miner and his hashrate, but more miners means more traffic.
If a single miner points more of his equipment at Slush, the pool will change his vardiff and the traffic and server load will remain the same.
If 1000 miners point 1Gh at the pool they will increase the traffic and the server load for just 1Th increase.

Still the pool hashrate is not related to the load it takes to serve it.

I am sure in such cases Slush just starts an additional stratum back-end (or adds a CPU to the virtual server instance) to take the load. With getwork the load was many times more than with stratum, so we are far from the limit. I also have a reason to believe that most of the processing is done in the startum back end servers, so adding another one scales almost linearly.

BTC tips: 1KNK1akhpethhtcyhKTF2d3PWTQDUWUzHE
binja9
Newbie
*
Offline Offline

Activity: 27


View Profile
February 27, 2014, 10:05:34 AM
 #15513

I'm also afraid to tell you that 'luck' does not exist - you can calculate probability but not luck (unless someone could post the calculation for the likelihood of luck existing)...

'Luck' exists, silly! If you earned more than expected, you've had good 'luck'. If you earned less than expected, you had bad 'luck'.

One certainty is that as the pool grows then so does the traffic into servers and it doesn't matter how much hashing goes on, it has to get to a server and 800-825TH seems to be the current 'lucky' number range.

No, the traffic problem is what vardiff solves.

Of course luck doesn't exist it is a convenient word to cover bad judgement, calculations or events we choose not to understand or have control of.

If you expect to earn  X and you earn Y then a force has acted upon X to move its value to Y - an event, not luck.
Either way your expectation/calculation was wrong.

binja9
Newbie
*
Offline Offline

Activity: 27


View Profile
February 27, 2014, 10:14:40 AM
 #15514

One certainty is that as the pool grows then so does the traffic into servers and it doesn't matter how much hashing goes on, it has to get to a server and 800-825TH seems to be the current 'lucky' number range.

No, the traffic problem is what vardiff solves.
True, but binja9 is also right - vardiff solves the problem for a single miner and his hashrate, but more miners means more traffic.
If a single miner points more of his equipment at Slush, the pool will change his vardiff and the traffic and server load will remain the same.
If 1000 miners point 1Gh at the pool they will increase the traffic and the server load for just 1Th increase.

Still the pool hashrate is not related to the load it takes to serve it.

I am sure in such cases Slush just starts an additional stratum back-end (or adds a CPU to the virtual server instance) to take the load. With getwork the load was many times more than with stratum, so we are far from the limit. I also have a reason to believe that most of the processing is done in the startum back end servers, so adding another one scales almost linearly.

Thanks for that clarity - well put

organofcorti
Donator
Legendary
*
Offline Offline

Activity: 2044


Poor impulse control.


View Profile WWW
February 27, 2014, 10:45:13 AM
 #15515

I'm also afraid to tell you that 'luck' does not exist - you can calculate probability but not luck (unless someone could post the calculation for the likelihood of luck existing)...

'Luck' exists, silly! If you earned more than expected, you've had good 'luck'. If you earned less than expected, you had bad 'luck'.


Of course luck doesn't exist it is a convenient word to cover bad judgement, calculations or events we choose not to understand or have control of.

If you expect to earn  X and you earn Y then a force has acted upon X to move its value to Y - an event, not luck.
Either way your expectation/calculation was wrong.


That calls for an "Argh".  You seem to have some math knowledge, but then you confound "expectation" in a mathematical sense, with "expectation" in some other sense.

Your expected income per difficulty 1 share is (Bitcoin reward per block) / (network difficulty). If you earn more than this per share, you've had good luck. Less than this is bad luck.

Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 2044


Poor impulse control.


View Profile WWW
February 27, 2014, 11:01:17 AM
 #15516

One certainty is that as the pool grows then so does the traffic into servers and it doesn't matter how much hashing goes on, it has to get to a server and 800-825TH seems to be the current 'lucky' number range.

No, the traffic problem is what vardiff solves.
True, but binja9 is also right - vardiff solves the problem for a single miner and his hashrate, but more miners means more traffic.
If a single miner points more of his equipment at Slush, the pool will change his vardiff and the traffic and server load will remain the same.
If 1000 miners point 1Gh at the pool they will increase the traffic and the server load for just 1Th increase.

Still the pool hashrate is not related to the load it takes to serve it.

I am sure in such cases Slush just starts an additional stratum back-end (or adds a CPU to the virtual server instance) to take the load. With getwork the load was many times more than with stratum, so we are far from the limit. I also have a reason to believe that most of the processing is done in the startum back end servers, so adding another one scales almost linearly.

If the load got too high, then Slush could simply increase the minimum variable difficulty. I don't think that will be a problem though - the pool isn't attracting as many new miners as other pools.

Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
Sir Alan
Full Member
***
Offline Offline

Activity: 221


View Profile
February 27, 2014, 11:05:19 AM
 #15517

I'm also afraid to tell you that 'luck' does not exist
"We must believe in luck. For how else can we explain the success of those we don't like?" - Jean Cocteau

1Eeyore17YeHrbJW5Q3pSdV8sXujkdrrFc
binja9
Newbie
*
Offline Offline

Activity: 27


View Profile
February 27, 2014, 11:49:03 AM
 #15518

I'm also afraid to tell you that 'luck' does not exist - you can calculate probability but not luck (unless someone could post the calculation for the likelihood of luck existing)...

'Luck' exists, silly! If you earned more than expected, you've had good 'luck'. If you earned less than expected, you had bad 'luck'.


Of course luck doesn't exist it is a convenient word to cover bad judgement, calculations or events we choose not to understand or have control of.

If you expect to earn  X and you earn Y then a force has acted upon X to move its value to Y - an event, not luck.
Either way your expectation/calculation was wrong.


That calls for an "Argh".  You seem to have some math knowledge, but then you confound "expectation" in a mathematical sense, with "expectation" in some other sense.

Your expected income per difficulty 1 share is (Bitcoin reward per block) / (network difficulty). If you earn more than this per share, you've had good luck. Less than this is bad luck.

No confusion - Expectation has to be based on some form of calculation applied to factors that you know or think you know.

As per my previous statement - luck is a convenient word to cover bad judgement, bad calculations or events we choose not to understand or have control of. Which is Bitcoin luck do you think.
KNK
Hero Member
*****
Offline Offline

Activity: 667


View Profile
February 27, 2014, 11:51:06 AM
 #15519

One certainty is that as the pool grows then so does the traffic into servers and it doesn't matter how much hashing goes on, it has to get to a server and 800-825TH seems to be the current 'lucky' number range.

No, the traffic problem is what vardiff solves.
True, but binja9 is also right - vardiff solves the problem for a single miner and his hashrate, but more miners means more traffic.
If a single miner points more of his equipment at Slush, the pool will change his vardiff and the traffic and server load will remain the same.
If 1000 miners point 1Gh at the pool they will increase the traffic and the server load for just 1Th increase.

Still the pool hashrate is not related to the load it takes to serve it.

I am sure in such cases Slush just starts an additional stratum back-end (or adds a CPU to the virtual server instance) to take the load. With getwork the load was many times more than with stratum, so we are far from the limit. I also have a reason to believe that most of the processing is done in the startum back end servers, so adding another one scales almost linearly.

If the load got too high, then Slush could simply increase the minimum variable difficulty. I don't think that will be a problem though - the pool isn't attracting as many new miners as other pools.
VarDiff with Slush aims at 15-20 shares per minute. Setting a higher minimum diff will increase the variance for the slower miners and may force them to move away.
If the load is high because of very slow miners not worth the additional server - Yes higher min diff is the solution, but if the load is high because of increased number of 'average speed' miners it is not a solution.

I am sure Slush is smart enough to figure it out when and what to do, when he has much more insight on the load than us - that's why i don't buy the conclusion of pool hashrate being a limiting factor.

BTC tips: 1KNK1akhpethhtcyhKTF2d3PWTQDUWUzHE
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 2044


Poor impulse control.


View Profile WWW
February 27, 2014, 11:53:03 AM
 #15520

am sure Slush is smart enough to figure it out when and what to do, when he has much more insight on the load than us - that's why i don't buy the conclusion of pool hashrate being a limiting factor.

I absolutely agree. Pool hashrate doesn't correlate with "luck", er shares/difficulty.

Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
Pages: « 1 ... 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 [776] 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 ... 1132 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!