Bitcoin Forum
May 18, 2021, 09:48:34 PM *
News: Latest Bitcoin Core release: 0.21.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 [142] 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 ... 371 »
  Print  
Author Topic: [1050 TH] BitMinter.com [1% PPLNS,Pays TxFees +MergedMining,Stratum,GBT,vardiff]  (Read 836745 times)
willphase
Hero Member
*****
Offline Offline

Activity: 768
Merit: 500


View Profile
May 02, 2013, 07:21:56 PM
 #2821

Could anyone with more PPLNS experience than me tell us about how unlucky the pool has been over the last few days? Is this usual variance or not, and should we expect the "actual" rewards graph line to cross the "expected" line anytime soon?

Go to https://bitminter.com/stats/rewards and then scroll down and look at the graph at the bottom.

If the green line is below the yellow line, then the pool is currently unlucky.  If the green line is above the yellow line, then the pool is currently lucky.

Will

1621374514
Hero Member
*
Offline Offline

Posts: 1621374514

View Profile Personal Message (Offline)

Ignore
1621374514
Reply with quote  #2

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

Activity: 98
Merit: 10



View Profile
May 02, 2013, 07:59:34 PM
 #2822

If you scroll down that page further, a second chart shows cumulative payout. Seems like there is a huge variance in terms of expected avg payout and actual (4940 vs 4463 at the time of this post). That's nearly 10% below average!

Also note that the payout is hardly ever above average, and the rare times it is, does not appear to be 10% above.

I don't know half of you half as well as I should like; and I like less than half of you half as well as you deserve.
Ƀ:17wbDetEw2aESM5oWXbm5ih9NSdDruyWNT
DrHaribo
Legendary
*
Offline Offline

Activity: 2716
Merit: 1034


Bitminter.com Operator


View Profile WWW
May 02, 2013, 08:18:21 PM
 #2823

Also note that the payout is hardly ever above average, and the rare times it is, does not appear to be 10% above.

This page only shows the last 500 shifts. Payouts have sometimes been much higher than average. I have on my TODO list to make it possible to go back in time on that graph, but I haven't had time to add it yet.

▶▶▶ Bitminter.com 2011-2020
philipma1957
Legendary
*
Offline Offline

Activity: 3024
Merit: 3258



View Profile
May 02, 2013, 09:11:08 PM
 #2824

We had 22 blocks In a day about 2x normal.  That is about best I can remember . The best thing to do is go on this site.


https://bitclockers.com/calc 

wait for the difficulty to change it did on tue this week so  put in your hash and see what you should get 10 days in a row. My hash is 9Gh/s today I should earn .44919 coins. ship your coins off and set to 0.  then set your coins at 10x or in my case 4.4919  . 

 check every day  same time.


 after 24 hours your should be at .44919
 after 48 hours you should be at .89839   

 once the ten days are up see how close you are to the calculator..  then multiply by 1.1 why the nmc you earn are worth 10% more.  so if you earned 4.3 coins in 10 days and said damn I am short multiply by 1.1 and you are at 4.73 coins and that my friend would be a good 10 days. most pools charge more then bitminter.

i do advise you to put some money in asicminer if you can't get an asic you can get a share for about 1.2 btc   

most of my money is in gpu farms...... 7k
  then some in bfl .......................... 1.6k
then some in asicminer shares.............  0.5k  total of 9k invested . 

I have collected about 11k in coins.

I see BTC as the super highway and alt coins as taxis and trucks needed to move transactions.
Jcw188
Hero Member
*****
Offline Offline

Activity: 532
Merit: 500

Carpe Diem


View Profile
May 02, 2013, 10:29:42 PM
 #2825

Entropy, is that true, has it been some months of lower than expected payout?  I was wondering why bitminter can do merged mining but slush can't on stratum...
DrHaribo
Legendary
*
Offline Offline

Activity: 2716
Merit: 1034


Bitminter.com Operator


View Profile WWW
May 02, 2013, 10:30:50 PM
 #2826

How do you get NMC merged mining to work with stratum?

You'll have to ask other pools why they don't. There is nothing in the Stratum protocol to make merged mining any more difficult than it is with getwork and getblocktemplate. When I added Stratum and getblocktemplate I just didn't turn off merged mining.

Not all pools have their own software. Some run one mining server software they found on the net 2 years ago that supported getwork and merged mining, but isn't maintained anymore. Then they found a new one that does Stratum but not merged mining, and they installed that too. The result is a patchwork of unmaintained outdated software and a random feature set. Other pools do have their own software and just left out merged mining because the mergeable coins looked dead. That was a pretty good assessment too, until someone suddenly started buying very large amounts of namecoins, pushing the price higher than it had ever been before.

Do you send restart messages every time a new NMC block is created?

New work is pushed on Stratum when there is a new BTC or NMC block. New work is also pushed every 30 seconds to include new transactions.

That does not imply a restart, however, as there is no progress when mining. If you lost the lottery every week for 10 years it doesn't mean that your chances of winning are now magically higher.

I have often wondered if there is some correlation between that and the lower than expected payout that has plagued this pool for some months.

I didn't have the impression we have been plagued with bad luck for months. I don't see that when I look at organofcorti's weekly pool stats.

And no, changing the data to be hashed does not cause bad luck. That's what your Stratum miner does when it creates new work anyway, it creates new data to be hashed. It doesn't even matter whether you change the entire merkle root or just 1 bit in the timestamp to create new work. Changing just 1 bit in the data being hashed will cause many changes in the resulting hash. This is called the avalanche effect.

Let me put it this way: if you can find a way to generate new work in a way that affects your success rate when mining, then you have found a loop hole in SHA-256 and you'll be a rich miner.

I'm not saying it's impossible that we randomly bumped into a weakness in SHA-256. But I don't think it's likely. It's not time to call Bruce Schneier just yet.  Wink

▶▶▶ Bitminter.com 2011-2020
willphase
Hero Member
*****
Offline Offline

Activity: 768
Merit: 500


View Profile
May 02, 2013, 10:46:52 PM
 #2827

If you scroll down that page further, a second chart shows cumulative payout. Seems like there is a huge variance in terms of expected avg payout and actual (4940 vs 4463 at the time of this post). That's nearly 10% below average!

Also note that the payout is hardly ever above average, and the rare times it is, does not appear to be 10% above.

Indeed - that's the graph I was pointing at (the one at the top is too confusing and doesn't really allow any meaningful interpretation) - that bottom graph is only last 500 shifts so maybe last 14-15 days worth, and I agree that right now the luck of the pool is bad.  Remember even if the pool is 10% more unlucky than average at the moment, you still get the +9% from namecoin, and over time (longer than two weeks) the luck all evens out.

Will

GuiltySpark343
Member
**
Offline Offline

Activity: 98
Merit: 10



View Profile
May 03, 2013, 12:29:06 AM
 #2828

On a separate topic ... any advantages of using BitMinter's Javascript client miner, versus BFGMiner on stratum?

I don't know half of you half as well as I should like; and I like less than half of you half as well as you deserve.
Ƀ:17wbDetEw2aESM5oWXbm5ih9NSdDruyWNT
matt4054
Legendary
*
Offline Offline

Activity: 1750
Merit: 1012


BitcoinQueue.com


View Profile WWW
May 03, 2013, 05:36:25 AM
 #2829

Here are some figures that I get from the 2nd graph on the rewards page, and from the table on the shifts page.

As I write this, the graph starts at shift 14348, that was on 2013-04-17 11:05 i.e. 15 days ago.

The pool has never quite been lucky since then.

Starting at shift 14670, 2013-04-27 04:23 i.e. about a week ago, the pool has started running unlucky, more than I have ever seen in the past (but I have only joined about 2 months ago). That is why I asked the question about variance and expected "recovery" time before the actual rewards catch up with the expected ones.

I think that the theoretical, correct answer to the question "how long before we catch up" is: you cannot know when, you can only know that it *will* happen in the future. So maybe I should rephrase the question:

From our current "unlucky" status, how long would it take before we have statistically more than 50% probability to catch up with the expected rewards? I believe this question can be (formally) answered. I'm not really expecting it, but if someone is both able and willing to calculate or even approximate it, I would find it useful and appreciate it :-)
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 2058
Merit: 1007


Poor impulse control.


View Profile WWW
May 03, 2013, 05:42:09 AM
 #2830

Here are some figures that I get from the 2nd graph on the rewards page, and from the table on the shifts page.

As I write this, the graph starts at shift 14348, that was on 2013-04-17 11:05 i.e. 15 days ago.

The pool has never quite been lucky since then.

Starting at shift 14670, 2013-04-27 04:23 i.e. about a week ago, the pool has run unlucky, more than I ever saw in the past (but I have only joined about 2 month ago), that is why I asked the question about variance and expected "recovery" time before the actual rewards catch up with the expected ones.

I think that the theoretical, correct answer to the question "how long before we catch up" is: you cannot know when, you can only know that it *will* catch up, at some point. So maybe I should rephrase the question:

From our current "unlucky" status, how long would it take before we have statistically more than 50% chance to catch up with the expected rewards? I believe this question can be (formally) answered. I'm not really expecting it, but if someone is both able and willing to calculate or even approximate it, I would find it useful and appreciate it :-)

Need some figures if I'm going to help - number of blocks in the time period, the number of shares per block, and difficulty of each block. Or I'll do it tonight when I get home.

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

Activity: 231
Merit: 100


View Profile
May 03, 2013, 03:47:05 PM
 #2831

From our current "unlucky" status, how long would it take before we have statistically more than 50% probability to catch up with the expected rewards? I believe this question can be (formally) answered. I'm not really expecting it, but if someone is both able and willing to calculate or even approximate it, I would find it useful and appreciate it :-)

There will never be more than 50% probability of being lucky, just as there's never more than 50% of probability of being unlucky.

Past luck doesn't affect future luck. It doesn't matter if the pool was lucky or unlucky recently; the probability of finding a block after n times difficulty shares is always the same.

While there's certainly a possibility of evening out the past bad luck or even surpassing the expected rewards in the long haul, this cannot be the likely (p > 0.5) scenario.

My inability to find a simple explanation of why actual payouts have been below expected caused me to move most of my pool work elsewhere.

Luck is just that: luck. There's no explanation for it. You either have bad luck or you don't.

Taking the last 100, 250 and 500 blocks from the statistics, I found that the mean of the required shares to solve a block was 1.216005475, 1.0990548393 and 1.0534418012 times difficulty, respectively.

Assuming a normal distribution and estimating the standard error from the respective samples (0.1262058917, 0.0744550916 and 0.0485402741 respectively), there's a chance of 4.36%, 9.18% and 13.57%, respectively, that a given pool would be that unlucky.

4.36% sounds pretty low, but since there are more than 23 mining pools, chances are that it happens to one of them...
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 2058
Merit: 1007


Poor impulse control.


View Profile WWW
May 03, 2013, 04:14:11 PM
 #2832

Taking the last 100, 250 and 500 blocks from the statistics, I found that the mean of the required shares to solve a block was 1.216005475, 1.0990548393 and 1.0534418012 times difficulty, respectively.

Assuming a normal distribution and estimating the standard error from the respective samples (0.1262058917, 0.0744550916 and 0.0485402741 respectively), there's a chance of 4.36%, 9.18% and 13.57%, respectively, that a given pool would be that unlucky.

4.36% sounds pretty low, but since there are more than 23 mining pools, chances are that it happens to one of them...

Shares per round / D is erlang distributed, so the lower tail CDF for the data you provided (100 @ 1.216005475, 250 @ 1.0990548393, 500 @ 1.0534418012) is 0.9800301, 0.9379993, and 0.8828175 - or 2.00%,  6.20% and 11.72%. So for example, in 100 repeats of 100 blocks, you'd expected to get an average that large or greater 2% of the time. As you say, hardly unusual.

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

Activity: 1750
Merit: 1012


BitcoinQueue.com


View Profile WWW
May 03, 2013, 04:16:08 PM
 #2833

Luck is just that: luck. There's no explanation for it. You either have bad luck or you don't.

(...)

Assuming a normal distribution and estimating the standard error from the respective samples (0.1262058917, 0.0744550916 and 0.0485402741 respectively), there's a chance of 4.36%, 9.18% and 13.57%, respectively, that a given pool would be that unlucky.

4.36% sounds pretty low, but since there are more than 23 mining pools, chances are that it happens to one of them...

Thanks for your post. It helps me clear things a bit between probability and the normal distribution function. I guess that the fact that luck "is not stateful over time" is counterintuitive to me. Fortunately I'm not gambling ;-)

However, I think PPLNS supporters aren't always very clear about the fact that there is a risk of earning less EVEN IN THE LONG RUN than pure PPS. That's the part that I had missed. Even if one risks just as much losing than winning, the risk is still here compared to PPS. Or am I wrong again?
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 2058
Merit: 1007


Poor impulse control.


View Profile WWW
May 03, 2013, 04:26:33 PM
 #2834

Luck is just that: luck. There's no explanation for it. You either have bad luck or you don't.

(...)

Assuming a normal distribution and estimating the standard error from the respective samples (0.1262058917, 0.0744550916 and 0.0485402741 respectively), there's a chance of 4.36%, 9.18% and 13.57%, respectively, that a given pool would be that unlucky.

4.36% sounds pretty low, but since there are more than 23 mining pools, chances are that it happens to one of them...

Thanks for your post. It helps me clear things a bit between probability and the normal distribution function. I guess that the fact that luck "is not stateful over time" is counterintuitive to me. Fortunately I'm not gambling ;-)

It may have sounded counterintuitive because redtwitz was assuming a normal distribution in a situation where that assumption can't be made without significant loss of accuracy.

However, I think PPLNS supporters aren't always very clear about the fact that there is a risk of earning less EVEN IN THE LONG RUN than pure PPS. That's the part that I had missed. Even if one risks just as much losing than winning, the risk is still here compared to PPS. Or am I wrong again?

If a PPLNS pool has lower fees than a PPS pool, then eventually then probability that you earn more on a PPLNS pool will approach 1.0 over time.

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

Activity: 2058
Merit: 1007


Poor impulse control.


View Profile WWW
May 03, 2013, 04:29:48 PM
 #2835

Luck is a factor for days, or even weeks.  I am talking about months of below expected results.

And luck is bi-directional.  Except for Bitminter where the payout graph hasn't gone over the expect line for more than a year.

Put that in your probability calculator and write a little lecture about it.

I do pool audits for US$120 (1.29 btc). PM me if you'r really interesting in knowing for sure if there's a problem or not.

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

Activity: 1358
Merit: 1000


AKA: gigavps


View Profile
May 03, 2013, 07:20:06 PM
 #2836

Another explanation is that some party is conducting a block withholding attack on the pool.  That is:

They direct hashpower at the pool but modify their mining software to not submit shares with a target value greater than X where X is less than the current difficulty.

The result is that they collect coins without every contributing to the pool. 

Such a strategy would be a very viable attack on competing pools.

I can think of several easy mechanisms to address such an attack, but I doubt that any pools do so today.

This is patently false. Please think about what you are saying before you start typing such things.

There is no way to perform a MITM attack or block withholding attack where the miner withholding receives the coins instead of the pool.
gyverlb
Hero Member
*****
Offline Offline

Activity: 896
Merit: 1000



View Profile
May 03, 2013, 07:30:21 PM
 #2837

Another explanation is that some party is conducting a block withholding attack on the pool.  That is:

They direct hashpower at the pool but modify their mining software to not submit shares with a target value greater than X where X is less than the current difficulty.

The result is that they collect coins without every contributing to the pool. 

Such a strategy would be a very viable attack on competing pools.

I can think of several easy mechanisms to address such an attack, but I doubt that any pools do so today.

This is patently false. Please think about what you are saying before you start typing such things.

There is no way to perform a MITM attack or block withholding attack where the miner withholding receives the coins instead of the pool.

This is not what he wrote about. The coins received are not the coins from the withholded blocks but the coins from the usual payout (for share submission).

P2pool tuning guide
Trade BTC for €/$ at bitcoin.de (referral), it's cheaper and faster (acts as escrow and lets the buyers do bank transfers).
Tip: 17bdPfKXXvr7zETKRkPG14dEjfgBt5k2dd
Epoch
Legendary
*
Offline Offline

Activity: 922
Merit: 1003



View Profile
May 03, 2013, 07:34:25 PM
Last edit: May 04, 2013, 01:10:48 AM by Epoch
 #2838

Another explanation is that some party is conducting a block withholding attack on the pool.  That is:

They direct hashpower at the pool but modify their mining software to not submit shares with a target value greater than X where X is less than the current difficulty.
The result is that they collect coins without every contributing to the pool.  
Such a strategy would be a very viable attack on competing pools.
I can think of several easy mechanisms to address such an attack, but I doubt that any pools do so today.
This is patently false. Please think about what you are saying before you start typing such things.
There is no way to perform a MITM attack or block withholding attack where the miner withholding receives the coins instead of the pool.
I thought Entropy-uc's post was pretty clear, and mentions nothing about a Man-In-The-Middle attack. Let's put it this way:

1) I direct my hashpower at a pool.
2) when my (custom) mining software detects that I have found a block, it does not submit it.
3) when someone else finds a block at the pool, I get paid my share just like all the other miners.

So, I have contributed nothing (and never will), I have performed a 'block withholding attack', and I still get coins. Granted, there is no direct benefit to me by doing this (and even my rewards are lower because of it). But if I point enough hashpower at the pool, it is possible to 'discredit' the pool's rep by imposing what appears to be an ongoing (and perhaps never-ending) run of bad luck because of my block withholding attack.

I'm not suggesting this is what is happening. I merely point out that I don't see anything 'patently false' about Entropy-uc's post.
WhitePhantom
Sr. Member
****
Offline Offline

Activity: 348
Merit: 250


View Profile
May 03, 2013, 10:03:18 PM
 #2839

Another explanation is that some party is conducting a block withholding attack on the pool.  That is:

They direct hashpower at the pool but modify their mining software to not submit shares with a target value greater than X where X is less than the current difficulty.
The result is that they collect coins without every contributing to the pool. 
Such a strategy would be a very viable attack on competing pools.
I can think of several easy mechanisms to address such an attack, but I doubt that any pools do so today.
This is patently false. Please think about what you are saying before you start typing such things.
There is no way to perform a MITM attack or block withholding attack where the miner withholding receives the coins instead of the pool.
I thought Entropy-uc's post was pretty clear, and mentions nothing about a Man-In-The-Middle attack. Let's put it this way:

1) I direct my hashpower at a pool.
2) when my (custom) mining software detects that I have found a block, it does not submit it.
3) when someone else finds a block at the pool, I get paid my share just like all the other miners.

So, I have contributed nothing (and never will), I have performed a 'block withholding attack', and I still get coins. Granted, there is no direct benefit to me by doing this (and even my rewards are lower because of it). But if I point enough hashpower at the pool, it is possible to 'discredit' the pool's rep by imposing what appears to be an ongoing (and perhaps never-ending) run of bad luck because of my block withholding attack.

I'm not suggesting this is what is happening. I merely point out that I don't see anything 'patently false' about Entroy-uc's post.

Thank you.  I don't have any reason to know it is happening either.

But it is a possible attack, there are people with motive to conduct such an attack, and there is enough misfortune appearing for many different pools lately to move my threat indicator from 'coincidence' to 'enemy action'.
Perhaps an analysis should be done on whether any high hash users are finding no blocks for the pool or perhaps far fewer blocks than is statistically likely.
FanDjangoBTC
Newbie
*
Offline Offline

Activity: 46
Merit: 0



View Profile
May 03, 2013, 10:37:00 PM
 #2840

Speculations on the motive of such an attack, only destruction if no personal profit possible?
Pages: « 1 ... 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 [142] 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 ... 371 »
  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!