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

[philipma1957]

I had a lot of things I needed to do today so the planned changes are a bit behind schedule.

All changes except the 1% fee are in effect. Fee will be set up in a moment.

 thanks doc I just checked my donations.

 I am at 1.5 % for both name and bit.   So this gets me the min fee and the perks. Correct? 

 I was giving 2.5% for both coins for the last 5 months. So this is a pay raise for me.  Or a fee cut. My donation page reads both perks are on.

It is sad that so many were taking a free ride.   Thanks for running a good pool. phil

[DrHaribo]

The donations are in addition to the fee. The donation page has a new sentence in bold type to make this more clear.

Fee coming up, just running some tests.

Edit: 1% fee now in effect.

[Zubilica]

Code:

Quote from: Inaba on Today at 04:34:19 AM
Yes, Conman and Kano should be getting their units next week as well as Bitminter, among a number of others.

Incoming feedback .. in 3.. ...2....

[Newar]

Something seems off with the perks. I've had the perks for BTC API and BTC prepay enabled. Now after the change it says for API 0.5% and for prepay 1.5%. However the donation slider is at 1.5% at the moment.

On the other hand the slider for NMC is at 1.5% as well, API perk enabled, but when I try to enabled the NMC prepay it won't allow it (as it should).

I hope you understand what I'm trying to say.

[DrHaribo]

Something seems off with the perks. I've had the perks for BTC API and BTC prepay enabled. Now after the change it says for API 0.5% and for prepay 1.5%. However the donation slider is at 1.5% at the moment.

On the other hand the slider for NMC is at 1.5% as well, API perk enabled, but when I try to enabled the NMC prepay it won't allow it (as it should).

I hope you understand what I'm trying to say.

A problem caused a delay between reducing perk costs and reducing donation for those using the prepay perks. Those who adjusted down their donations manually in the meantime are now donating 1.5% for 2.0% worth of perks. If you would increase your donation yourself that would be appreciated.

The cost for the API perk will be going down soon and more perks will be added.

[Newar]

Something seems off with the perks. I've had the perks for BTC API and BTC prepay enabled. Now after the change it says for API 0.5% and for prepay 1.5%. However the donation slider is at 1.5% at the moment.

On the other hand the slider for NMC is at 1.5% as well, API perk enabled, but when I try to enabled the NMC prepay it won't allow it (as it should).

I hope you understand what I'm trying to say.

A problem caused a delay between reducing perk costs and reducing donation for those using the prepay perks. Those who adjusted down their donations manually in the meantime are now donating 1.5% for 2.0% worth of perks. If you would increase your donation yourself that would be appreciated.

Done. Looking forward to the new perks!

[zinko]

The website is coming down intermittently, serving up a CloudFare page. Miners mostly still connected, though I'm seeing some timeouts.

[aggietallboy]

Looks like it's getting hit with a DDOS... ugh getting tired of whomever thinks these are fun :S

[PCMiner]

I was wondering, for sciences sake, if you could add a overall average time to find a block listing somewhere on the website.  I know the actual times can greatly vary, (1 min to sometimes 10+ hours) but it would be nice to see what the bitminter pool average "Find a block" time is over a the course of a week, or a month, etc...
Can't be that hard to get the average.

[organofcorti]

I was wondering, for sciences sake, if you could add a overall average time to find a block listing somewhere on the website.  I know the actual times can greatly vary, (1 min to sometimes 10+ hours) but it would be nice to see what the bitminter pool average "Find a block" time is over a the course of a week, or a month, etc...
Can't be that hard to get the average.

The average time is dependant on hashrate and difficulty. Averaging past a retarget wouldn't make sense.

[philipma1957]

I was wondering, for sciences sake, if you could add a overall average time to find a block listing somewhere on the website.  I know the actual times can greatly vary, (1 min to sometimes 10+ hours) but it would be nice to see what the bitminter pool average "Find a block" time is over a the course of a week, or a month, etc...
Can't be that hard to get the average.

this chart can help you get an estimate

http://bitcoincharts.com/     the rate for blocks per hour FOR THE WHOLE NETWORK is on the upper right corner.


 today it is 6.71 blocks per hour.    multiply by 24 = 161 blocks per day  for the entire network.      so use 161      multiply by bit minters hash rate 6.05 = 974.292 divide by network hash rate 71.858 = 13.55 blocks per day 0r about 1 block every hour and 47 minutes.  


   THIS is in constant flux why our rate of 6.05 Th  and the network rate of 71.588  changes minute by minute.   So you get a rough estimate you can do this calculation 24 times a day on every hour and add it then divide  by 24.  more samples are more accurate but always reflect the past history not the present.   Lets say asic miner decides to move all of its 8Th to bitminter in 1 hour from now .  We jump to 14Th not 6Th and even though we were at the 1 block every 1 hour and 46 minutes for 20 days in a row we now jump to 1 block every 50 or 45 minutes in an instant. 

My math could be off a bit but I am pretty sure theory is correct.. In a way this is a more complicated answer with more detail then PCMiner but essentially the same answer.

[kano]

No, the network hash rate doesn't affect the pool block rate.
You seem to have added that in and then removed it in your calculations.
Your answer is correct, but the calculation is adding then removing variables.
The network difficulty it what matters.

To get the network difficulty use getinfo on bitcoind or http://blockchain.info/q/getdifficulty - call that D
If the pool hash rate is X TH/s

Then the expected average time for the pool to find a block is:

(D * 2^32) / (X * 10^12) seconds (i.e. a simple 2 number division of D and X)

So assuming the pool hash rate is 6.05TH/s

(8974296.01488785 * 2^32) / (6.05 * 10 ^ 12) = ~6371s or ~1hr 46min

[Jcw188]

Two stale blocks today?  Is something wrong, how often does this happen?  What a waste of mining...

[Jcw188]

Sorry didn't mean to be rude but I was confused. Last block not showing as stale anymore but there is still one stale. How often does that happen?

[dtown]

Speaking of API, I noticed there are some JSON fields available on the web site when you are logged in.  For example, on the shifts json, when logged in you get access to your_score, your_rejected and your_accepted. 

Any chance you can add the headers API key support to the shifts JSON to allow visibility to user specific data without actually having to log in?  Doing the same for the blocks JSON for block level reward data would be amazing too.

Thanks for your hard work! 

[philipma1957]

No, the network hash rate doesn't affect the pool block rate.
You seem to have added that in and then removed it in your calculations.
Your answer is correct, but the calculation is adding then removing variables.
The network difficulty it what matters.

To get the network difficulty use getinfo on bitcoind or http://blockchain.info/q/getdifficulty - call that D
If the pool hash rate is X TH/s

Then the expected average time for the pool to find a block is:

(D * 2^32) / (X * 10^12) seconds (i.e. a simple 2 number division of D and X)

So assuming the pool hash rate is 6.05TH/s

(8974296.01488785 * 2^32) / (6.05 * 10 ^ 12) = ~6371s or ~1hr 46min

Okay I know that difficulty  should be used not hashrate of the network ,but and here is my problem with using difficulty lets say the network hashrate is 71Th and difficulty  is 8974296.  Lets say 30 percent of the network drops off  but that bitminter has 0 dropoff.  This has happened more then once.  During the 30 percent dropoff  bitminter has 6Th out of 50Th I would think we get more blocks during the 30% drop off. I realize that difficulty stays stable for about 11 days while bitminter hash and network hash are in a flux state.  
 

So my logic was the current hashrate ratio of bitminter to network is more important then using the 11 day constant difficulty number.  My best case real world example is BTC guild is huge 30 out of 71 Th  lets say all of asicminers 8Th is with BTC guild and all is well.

 Bitminter is at 6Th the network is at 71Th.
.

 Our percent is 6/71 or 8.4 percent.  lets say asic miner's gear drops off do to a power issue since it is all with BTC guild Bitminter stays the same  6Th but the network drops off to 63Th  our percent is 6/63 or 9.5 percent.  So if asicminer was down for 1 day difficulty stays set at 8,974,296  but for practical purposes our network share rose from 8.4 to 9.5 percent.

 For instance Network  Hash  is   the following on :
April 19Th 58Th  
Apr 20Th 58Th    
Apr 21St 65Th  
April 22nd 80Th
 April 23rd 70Th
 April 24Th 75Th

Difficulty was constant .  For the sake of argument lets say bitminter's  hashrate flux was + or - 2%  while the network had larger swings due to Asicminer turning its gear on and off. Asicminer has about 8Th and I see big quick drops close to 8Th in the network.

 My method is never going to be exact since I am using 2 changing variables bitminer hashrate and network hashrate.  And I am not using the difficulty which is an eleven day(IIRC) constant. But my method should reflect the real share of blocks better if  bitminer's hashrate is more stable then the network's hashrate during the time sampled.

[kano]

No, the network hash rate doesn't affect the pool block rate.
You seem to have added that in and then removed it in your calculations.
Your answer is correct, but the calculation is adding then removing variables.
The network difficulty it what matters.

To get the network difficulty use getinfo on bitcoind or http://blockchain.info/q/getdifficulty - call that D
If the pool hash rate is X TH/s

Then the expected average time for the pool to find a block is:

(D * 2^32) / (X * 10^12) seconds (i.e. a simple 2 number division of D and X)

So assuming the pool hash rate is 6.05TH/s

(8974296.01488785 * 2^32) / (6.05 * 10 ^ 12) = ~6371s or ~1hr 46min

Okay I know that difficulty  should be used not hashrate of the network ,but and here is my problem with using difficulty lets say the network hashrate is 71Th and difficulty  is 8974296.  Lets say 30 percent of the network drops off  but that bitminter has 0 dropoff.  This has happened more then once.  During the 30 percent dropoff  bitminter has 6Th out of 50Th I would think we get more blocks during the 30% drop off. I realize
...

No, you will not expect to find more blocks.
The ability to find a block is directly related to the difficulty, the network hash rate is not relevant.
If you happen to find some correlation, it's purely coincidental.

[Jcw188]

what's going on now, just really bad luck?  block has been 10 hours

[mdude77]

what's going on now, just really bad luck?  block has been 10 hours

If pool hash rate doesn't increase proportionally to difficulty increases, there will be longer and longer blocks.

M

[Jcw188]

ever hit 100% before on the CDF?