[1050 TH] BitMinter.com [1% PPLNS,Pays TxFees +MergedMining,Stratum,GBT,vardiff]

[Littleshop]

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.

He never said that.  On a PPS pool they can do that and still collect the PPS.  On a non PPS pool they also can do it, but they do not collect.  It still is an attack, it is just costly. 

[1714186074]

1714186074

[organofcorti]

Would love to see a gh/s breakdown by worker on the stats page

Your wish is my etc.

from http://organofcorti.blogspot.com.au/2013/05/122-pool-and-network-miner-hashrate_3.html





or you could just use the api:

/api/pool/top50

[philipma1957]

Half hour downtime...

 yeah and this down time does not get shown correctly for luck.  for instance today we mined 20 blocks which is a great day.    so if you add the hash rates at the 20 blocks which is 20 samples of hash rate for a 24 hour day then divide by 20 you get  an average hash of 8,739.616 Gh/s     even with 20 samples from today that number is high since we had a half hour down time.      remember if the server is down or ddos attack we can not earn a block so the zero samples do not get averaged in.   so if we were down for .5 hours  23.5/24 = 96.04 percent  the hash rate would need to be multiplied by that so   we were more like 8,393.527   not 8,739.616  

so  we mined 20    if you use the calculator

https://bitclockers.com/calc   it shows we should have mined 17.448 blocks   but that has not been lowered b down time today the correct number of should mined was 16.757 blocks  and we did 20.    so if you defied 16.757 into 20 you get 1.193 or 19.3 percent better then normal.   some will insist pools should have 0 done time and have  20 divided by the un adjusted 17.448 blocks.    this comes to 1.146 or 14.6 percent better then normal.

 either way it was a good day.   do not forget we also got nmc 8 percent extra is normal so today was close to a 1.27 or 1.28 rather then 1 or 28% extra.    

It's possible you are correct.  Bitminter should show daily earnings like other pools do.  This gives you a clear indicator that can be compared with expected earnings for your hashrate and the day's luck.

But Bitminter isn't down 10% of the time, so there has to be more to it if there is soley a miscalculation going on.  And any pool that is down 10% is one to avoid, failover to backup pools costs significant transition time.

I have an idea that should be easy to do. I will get back with results in 5 days.

[organofcorti]

But Bitminter isn't down 10% of the time, so there has to be more to it if there is soley a miscalculation going on.  And any pool that is down 10% is one to avoid, failover to backup pools costs significant transition time.

Can you show me your calculations for the 10% figure?

[redtwitz]

Call me greedy, but are there any plans to add further altcoins? IXC and DVC together seem to make almost as much as NMC...

[candoo]

Whats wrong with the pool? Someone stealing blocks?

[organofcorti]

Whats wrong with the pool? Someone stealing blocks?

[....]

No.

[Newar]

Whats wrong with the pool? Someone stealing blocks?
[...]

Read the last few pages.

[philipma1957]

Whats wrong with the pool? Someone stealing blocks?

where did these come from?  while they look nice where  did the data come from to show this.    the problem is you need to show your sampling of how you get the pools hash rate. if you take your data from when a block is made it leaves out all down time and can be very misleading. remember no blocks are made when a pool goes down.  so any true hash rate must account for down time.

 by the way I have figured out a very good way to test the idea out that coins are too low for luck to be accountable.       I have a method that solves the problem of hash rate calculation. the pools hash rate is not important for my method .  in fact all that matters is If I run at least one worker 24/7 .  I can give 1 day result  a 2 day result a 3 day result a 4 day result and a 5 day result.

[philipma1957]

I am about 8 hours and 35 minutes into my test.   start time was 1:34

[organofcorti]

[....]
where did these come from?  while they look nice where  did the data come from to show this.    the problem is you need to show your sampling of how you get the pools hash rate. if you take your data from when a block is made it leaves out all down time and can be very misleading. remember no blocks are made when a pool goes down.  so any true hash rate must account for down time.

 by the way I have figured out a very good way to test the idea out that coins are too low for luck to be accountable.       I have a method that solves the problem of hash rate calculation. the pools hash rate is not important for my method .  in fact all that matters is If I run at least one worker 24/7 .  I can give 1 day result  a 2 day result a 3 day result a 4 day result and a 5 day result.

Not quite. Unless you derive confidence interval for the data, you're only showing the variance.

[luffy]

bad luck will not last forever! just enjoy this great pool 
i would like to see also all the other merging capable coins, i wish PPC would be amongst them 

[philipma1957]

[....]
where did these come from?  while they look nice where  did the data come from to show this.    the problem is you need to show your sampling of how you get the pools hash rate. if you take your data from when a block is made it leaves out all down time and can be very misleading. remember no blocks are made when a pool goes down.  so any true hash rate must account for down time.

 by the way I have figured out a very good way to test the idea out that coins are too low for luck to be accountable.       I have a method that solves the problem of hash rate calculation. the pools hash rate is not important for my method .  in fact all that matters is If I run at least one worker 24/7 .  I can give 1 day result  a 2 day result a 3 day result a 4 day result and a 5 day result.

Not quite. Unless you derive confidence interval for the data, you're only showing the variance.

true . but my method is not about btc real earnings vs btc projected earnings. 

my method has constants that do not vary but rather show a parallel ratio that should be consistent.

 if not consistent it would indicate a flaw and or a bug or a very clever manipulation of the pool.

 frankly  I have done this method a few times and never had any large problem (ie variance) 


 which is why I feel that this pool is run well and that the so called bad luck is not 10%.

[organofcorti]

[....]
where did these come from?  while they look nice where  did the data come from to show this.    the problem is you need to show your sampling of how you get the pools hash rate. if you take your data from when a block is made it leaves out all down time and can be very misleading. remember no blocks are made when a pool goes down.  so any true hash rate must account for down time.

 by the way I have figured out a very good way to test the idea out that coins are too low for luck to be accountable.       I have a method that solves the problem of hash rate calculation. the pools hash rate is not important for my method .  in fact all that matters is If I run at least one worker 24/7 .  I can give 1 day result  a 2 day result a 3 day result a 4 day result and a 5 day result.

Not quite. Unless you derive confidence interval for the data, you're only showing the variance.

true . but my method is not about btc real earnings vs btc projected earnings. 

my method has constants that do not vary but rather show a parallel ratio that should be consistent.

 if not consistent it would indicate a flaw and or a bug or a very clever manipulation of the pool.

 frankly  I have done this method a few times and never had any large problem (ie variance) 


 which is why I feel that this pool is run well and that the so called bad luck is not 10%.

You're a mysterious one!

When you're done, can you post your method and the reason for it along with the results?

[philipma1957]

[....]
where did these come from?  while they look nice where  did the data come from to show this.    the problem is you need to show your sampling of how you get the pools hash rate. if you take your data from when a block is made it leaves out all down time and can be very misleading. remember no blocks are made when a pool goes down.  so any true hash rate must account for down time.

 by the way I have figured out a very good way to test the idea out that coins are too low for luck to be accountable.       I have a method that solves the problem of hash rate calculation. the pools hash rate is not important for my method .  in fact all that matters is If I run at least one worker 24/7 .  I can give 1 day result  a 2 day result a 3 day result a 4 day result and a 5 day result.

Not quite. Unless you derive confidence interval for the data, you're only showing the variance.

true . but my method is not about btc real earnings vs btc projected earnings. 

my method has constants that do not vary but rather show a parallel ratio that should be consistent.

 if not consistent it would indicate a flaw and or a bug or a very clever manipulation of the pool.

 frankly  I have done this method a few times and never had any large problem (ie variance) 


 which is why I feel that this pool is run well and that the so called bad luck is not 10%.

You're a mysterious one!

When you're done, can you post your method and the reason for it along with the results?

yes I will.

 It is quite simple but I want to post it after 5 days showing the 1 day the 2 day 3 day 4 day 5 day results.

After I post the first 5 days I will continue to track the pool. Frankly I do not expect to have a  large 10% issue that has been mentioned.

More like plus or minus 1 or 2 %.

[Jcw188]

How many rigs does realasicminer have?  He is now at 4.3 Thps.  Anyone know who this is?  Or could it be BFL mining with the gear they're supposed to be shipping to customers? :-)

[PCMiner]

How many rigs does realasicminer have?  He is now at 4.3 Thps.  Anyone know who this is?  Or could it be BFL mining with the gear they're supposed to be shipping to customers? :-)

Its ASICMiner.  They have some of their machines on bitminter for awhile while they are getting them setup.  The plan I believe is to eventually move them to solo mining.  So enjoy it while it lasts on Bitminter.

[DrHaribo]

There is some confusion lately that having big miners in the pool means the smaller miners get paid less. That's not how it works. Your average payout is determined by your hashrate, the difficulty, and fees/donations. Other people's hashrate does not influence this at all.

If someone joins the pool with 10% of the hashrate, then the pool will be pulling in 10% more bitcoins, the new user will be doing 10% of the work, and the new user will get 10% of the payouts. You don't make more coins by mining in a big/small pool, and you don't make less money mining in a big/small pool.

But a higher pool hashrate reduces variance for everyone in the pool. That means you will have smaller variations than before in your daily payouts.

[kano]

There is some confusion lately that having big miners in the pool means the smaller miners get paid less. That's not how it works. Your average payout is determined by your hashrate, the difficulty, and fees/donations. Other people's hashrate does not influence this at all.

If someone joins the pool with 10% of the hashrate, then the pool will be pulling in 10% more bitcoins, the new user will be doing 10% of the work, and the new user will get 10% of the payouts. You don't make more coins by mining in a big/small pool, and you don't make less money mining in a big/small pool.

But a higher pool hashrate reduces variance for everyone in the pool. That means you will have smaller variations than before in your daily payouts.

However, that depends on the order you send LP messages.
If you order them higher hash rate first (like slush does) then those with a lower hash rate will get their LP that tiny bit later, if there are more higher hashing people on the pool. Of course this only means a small drop if it is the case.

Also of course without the source code one can't verify how the pool prioritises responses to miners.
But since you have to pay for the miner (it isn't free), I'd guess no one else has the source code

[DrHaribo]

However, that depends on the order you send LP messages.
If you order them higher hash rate first (like slush does) then those with a lower hash rate will get their LP that tiny bit later, if there are more higher hashing people on the pool. Of course this only means a small drop if it is the case.

Ok, true, more users in the pool affects your work reject ratio, but the difference will be tiny.

The BitMinter server orders long pollers by hashrate for getwork and getblocktemplate (GBT). For Stratum there is no ordering when pushing work (at least not yet).

Currently at each block change work is pushed to 7000-8000 Stratum connections in 0.01-0.03 seconds. 8000-9000 long pollers (getwork/GBT) are notified in 1.5-1.8 seconds. A few more ASICs running Stratum won't really make any difference.

Also of course without the source code one can't verify how the pool prioritises responses to miners.
But since you have to pay for the miner (it isn't free), I'd guess no one else has the source code

Yes, the server software is closed source. And it wouldn't make much difference if it was open source, because you would never know if the source code I gave you is what I was running on the server.

Not sure what you mean having to pay for the miner. There's no extra fee for using BitMinter client over other mining clients.