[DOWN] Bitlc.net - P2SH, No invalid blocks, Custom payouts, EU, 0% fee, LP

[deepceleron]

No, its been at least two weeks.  I switched my main pool two weeks ago and switched again a few days ago, and have been monitoring them all to see if I made the right decision.  MtRed has consistently made more than bitcoins.lc would have for me up from the time i switched until a few days ago, and now deepbit is doing the same.  Bitcoins.lc before that point was making me a LOT more than I would have made at other pools.  I would be right back to bitcoins.lc as I really liked the pool except for the no full payout thing if it was earning me the most for my mining.  The best day bitcoins.lc had in the last 2 weeks was the 13th, and I would have made ~.45btc.  Instead I was mining at deepbit and mined .47BTC.  Every other day pretty much I would have been off by at LEAST .1 BTC mining at bitcoins.lc, which is 20%, save for the 5th of july.  On the fifth of july I was able to mine half at MtRed and half at bitcoins.lc and really made a fairly good gain, even though I would have been better off probably just staying at bitcoins.lc for that one day.

This post documents a basic misunderstanding of the variance of Bitcoin. The past luckiness of a pool, or even how long the current round is, has nothing to do with how much you will make in future rounds. Every single time your computer trys a block hash, it has a very small chance of solving it that is always the same, a chance that is only based on the difficulty setting of Bitcoin. Your average earnings are completely based on how many shares you submit in a round, which is completely based on your hashrate. Whether you solo mine, or join the biggest pool, your expected earnings from your personal hash rate against this 'difficulty' problem will always average out to be the same. Only pool fees (and rejected shares or downtimes) can affect your expected earnings; and you can buffer against possible pool downtimes by running a second miner per GPU pointed at a different pool.

The same fallacies persist in other games of chance, like how some people think a slot machine (fruit machine) in a casino might be "hot", or "due for a win", when the chance of you winning is purely random, just like every hash the pool trys, and has nothing to do with the past (this inability to recognize bad human intuition and apply logic is a driving factor in gambling addiction, since to even play a game once with losing odds is illogical, and to play more than once only reduces the variance and further guarantees your loss). It would be like if I had a coin flip game where I flip the coin and heads wins. Just because the coin landed on tails four times in a row doesn't mean that going to someone else's coin-flip game is going to get you any more wins in the future. You could make the argument that maybe my coin or dice aren't perfect and favor one side, but bitcoin has perfect dice.

[Jack of Diamonds]

Just because the coin landed on tails four times in a row doesn't mean that going to someone else's coin-flip game is going to get you any more wins in the future. You could make the argument that maybe my coin or dice aren't perfect and favor one side, but bitcoin has perfect dice.

I don't think you understand why pool hopping really is profitable over the long term as
compared to switching roulette tables or slot machines and why gamblers fallacy doesn't apply to block finding probability.

Proportional pool luck is determined by current difficulty factor and hash rate.
There is a certain statistical point at which blocks will be *usually* found given a large enough statistical sample (100, 1000 or more blocks)

A gambler can't *expect* to get a certain amount of heads or tails in a coin flip because the statistical probability
of either one is always 50% (assuming it can't fall on it's side) over the long term.

A miner can expect 95% of blocks to be solved in the long term at 1.56m difficulty and roughly 9½ hours spent at 600ghash/s.

If the occurrence of rounds surpassing 9½ hours becomes significantly more than 5% in the long term (let's say 20%), the miner can expect foul play.
Just as if a coin would consistently fall on the tails side over 1 million throws (let's say to a 70:30 ratio), you could suspect the casino has a weighted/rigged coin.
3-8% would probably pass as variance

[deepceleron]

Just because the coin landed on tails four times in a row doesn't mean that going to someone else's coin-flip game is going to get you any more wins in the future. You could make the argument that maybe my coin or dice aren't perfect and favor one side, but bitcoin has perfect dice.

I don't think you understand why pool hopping really is profitable over the long term as
compared to switching roulette tables or slot machines and why gamblers fallacy doesn't apply to block finding probability.

Proportional pool luck is determined by current difficulty factor and hash rate.
There is a certain statistical point at which blocks will be *usually* found given a large enough statistical sample (100, 1000 or more blocks)

A gambler can't *expect* to get a certain amount of heads or tails in a coin flip because the statistical probability
of either one is always 50% (assuming it can't fall on it's side) over the long term.

A miner can expect 95% of blocks to be solved in the long term at 1.56m difficulty and roughly 9½ hours spent at 600ghash/s.

If the occurrence of rounds surpassing 9½ hours becomes significantly more than 5% in the long term (let's say 20%), the miner can expect foul play.
Just as if a coin would consistently fall on the tails side over 1 million throws (let's say to a 70:30 ratio), you could suspect the casino has a weighted/rigged coin.
3-8% would probably pass as variance

I certainly understand the maths behind pool hopping; if you had five identical proportional pools and just hopped to the next at the start of its new round, hoping to sip the cream from short rounds, you could hope for a significant return above the baseline (at the expense of full-time miners). I do not address the quantum valuation of individual shares; quote: "The past luckiness of a pool, or even how long the current round is, has nothing to do with how much you will make in future rounds". Actually that should be clarified to "how much you make over a period of time in future rounds", for in rounds you simply get your share of 50BTC.

You are saying if some rounds go three times as long as the average (ignoring the ones that are one third length), I should expect foul play?? As my example above, that is like saying if I flip heads three times in a row (87.5% chance of that not happening in three coin flips), then the coin is probably fixed. Your previous posts with some graphs and the statement that a round "already passed 100% probability of hitting block" shows that you are not estimating probability correctly when making your assessments; a statistician can expect an average of 89.753% of rounds to be solved by 9.5 hours at 600Gh/s. Feel free to change to a different proportional pool if you desire, for their past luck does not predict or affect future winnings either (but their fees will..) I would recommend a high hashrate pool, because their 80th percentile variance will be 5 minutes to 2 hours instead of 26 minutes to 9.6 hours, and you might get less bent out of shape. Their pool threads will probably get an earful of "why are my round payments 1/5 as much" though...

[Jack of Diamonds]

Their pool threads will probably get an earful of "why are my round payments 1/5 as much" though...

I have 50% of my miners at btcmine.com which has about the same hashrate as bitcoins.lc, and nearly all of their rounds fall within the average timeframe expected to solve blocks, about 2-3 hours. http://btcmine.com/stats/

Registration being closed or not isn't really relevant for solving blocks (while it does deter new pool hoppers)

It's not temporary either, I have all the pool stats available in an excel table; They don't even have a single round that took more than 15 hours, and very rare ones at 10-11h.

Though, if you read the thread Jine has already given a possible solution, and that is the recent big amount of stales at bitcoins.lc which is stretching rounds.
If you look at the full round history of bitcoins.lc before a week or two ago, you will see a quite natural distribution of blocks for many months.

You are saying if some rounds go three times as long as the average (ignoring the ones that are one third length), I should expect foul play

No, "some rounds" falls within normal variance. Even 10 or 20 unlucky rounds fall within normal variance.
If 95th%+ percentile rounds had a much, much more frequent occurrence than 5% (let's say 20% over the next 1000 blocks), then you could suspect foul play.

As you said, past performance tells nothing about future probability. Therefore, all pools will ultimately have the exact same earnings in the long term, just at different speeds. Unless something is misconfigured, which can be spotted very easily by comparing the earnings of one pool to the other 20 pools in existence over the last 6 months (not over 2 days or even a week)

[pandemic]

Alright, we just had a 22 hour round followed by a 10 hour round. wtf

Call it luck, odds, stats, whatever, this blows.

edit: Site just updated. Before, the previous round was 22 hours and current was 10. Well the current is still 10 but now it shows previous as 3 hours. I was also just paid for blocks 136358, 136379.

[Jack of Diamonds]

It's not bad luck.
I'm 100% confident this was another 'mistake' and in fact many different rounds simply reported as one huge long one.
So there is not a 10+ hour round going on again in fact.

See the payout stats in a few hours if you don't believe me. I've done the math, compared dozens of pools and this is the most likely scenario.

[Jine]

Jack of Diamonds:

You're almost correct, it seems that push03 had some issues which made mysql really, really slow. I restarted it and poff - 3 solved blocks.
I've tried to give my girlfriend a bit of attention today/yesterday, sorry for the late response/noticing of this.

I'm doing the best i can regarding performance, uptime, stability and bugs.
It seems that we've been hunted a bit of nasty issues lately - but I do have today to iron these out.

Regarding "long rounds" etc - I'm not sure how to prove that it's not the case, But i'm open for suggestions.
How would you feel of a "listtransactions"-api? So you actually can see when block are found, and how many - we had one before aswell, but it got heavily used so i had to shut it down.

Now with a bit of more ram since my last upgrade, we can extend the memcache usage and also cache those stats.

[Jine]

We just deployed our latest pushpoold patch to get rid of the rejects.
It looks good so far.

[366.96 Mhash/sec] [124 Accepted] [0 Rejected] [RPC (+LP)]

[Jine]

We now got 6 last balanced pushpoold/bitcoind nodes.


Now it's time for some coding on the new system, I've had to postpone it until now due to the issues, rejected shares and stability issues.
Everything seems to work better now, that's really, really good

I'll keep you guys updated.

[Jine]

I just banned 88.198.142.94 due to SHITLOAD of connections.
It's a webserver, so could the person running this proxy/hopper whatever STOP FUCKING ABUSING OUR SERVICE?

Seriously, it's 1k+ connections per second.

[muyoso]

This post documents a basic misunderstanding of the variance of Bitcoin. The past luckiness of a pool, or even how long the current round is, has nothing to do with how much you will make in future rounds. Every single time your computer trys a block hash, it has a very small chance of solving it that is always the same, a chance that is only based on the difficulty setting of Bitcoin. Your average earnings are completely based on how many shares you submit in a round, which is completely based on your hashrate. Whether you solo mine, or join the biggest pool, your expected earnings from your personal hash rate against this 'difficulty' problem will always average out to be the same. Only pool fees (and rejected shares or downtimes) can affect your expected earnings; and you can buffer against possible pool downtimes by running a second miner per GPU pointed at a different pool.

Your last sentence is kind of a lie.  Pools go through waves of luckiness and unluckiness.  I dont know why this is, but it IS the case.  If you leave unlucky pools and join lucky ones you effect your expected earnings in a positive manner.  For example, deepbit has outperformed bitcoins.lc everyday this week.  If bitcoins.lc outperforms deepbit everyday next week, then someone who stuck with either pool will end up in a wash while someone who was at deepbit this week and bitcoins.lc the next will come out ahead.

Its all a gamble.  When a pool pays me out below what I expect to get paid for my hash rate a couple days in a row, I usually check out the other two pools I am registered in and jump in right after a long round has just finished.  I have noticed very long rounds are very rarely grouped together.  Maybe there is no factual basis to what I do, but it has certainly worked for me as I have mined more bitcoins than all of the calculators told me was possible with my connection consistantly for each difficulty since I started mining.

[Jine]

Everybody that uses a pool proxy, pool-hopper proxy or whatever.
Please, please make it support LP and don't issue 400+ getworks each second.

I'm adding an limiter (per source ip) in a few hours, will destroy it for everybody that uses a proxy (with one outgoing ip) but it's messing up the load balancer (because it only uses one source ip for multiple, possible hundreds of workers).

[padrino]

Everybody that uses a pool proxy, pool-hopper proxy or whatever.
Please, please make it support LP and don't issue 400+ getworks each second.

I'm adding an limiter (per source ip) in a few hours, will destroy it for everybody that uses a proxy (with one outgoing ip) but it's messing up the load balancer (because it only uses one source ip for multiple, possible hundreds of workers).

Is your limit going to be 400 getworks a second? I only ask because I have about 15 workers behind one IP, an aggregate of about 5Gh/s but I do it this way because shrinking down the number of workers still results in a lot of rejected shares. I'm not where near 400 per second but thought I would ask so everyone can gauge whether or not it will be an issue.

[RyNinDaCleM]

plz anyone can told me how to take my ALL BTC with 8 decimal?

PM Jine; he may be able to work something out with you!

Really the only hold up, is that some people still use an old version of bitcoin client, which deletes anything over the second decimal place on payout! So make sure you have the latest client!

[digger]

you site has been included in this site

who find the bitcoin blocks?

http://digbtc.com

have a look at it!

[gellimac]

you site has been included in this site

who find the bitcoin blocks?

http://digbtc.com

have a look at it!

nice site, on my favorit now 

[flower1024]

like it to..

could you provide an json output of this table?
and stats delay info per block.

would be really nice

[Jine]

Me and my girlfriend took a trip to the DC a few hours ago.
Installed a couple of new drives on the node for local storage and bin-logs.

Some fast benchmarks:

root@staging:~# hdparm -tT /dev/xvda1

/dev/xvda:
 Timing buffered disk reads: 652 MB in  3.00 seconds = 217.16 MB/sec
 Timing cached reads:   5302 MB in  1.99 seconds = 2658.56 MB/sec

Eveything seems to run a lot smoother now, with the load balancing up and running and everything working as it should.
We have dropped a lot in hash rate over the few past days, possible due to the extremely long run before.

I hope we gain some more so i can prove that we're a lot faster, stronger and more stable now
Also, the patch for rejected shares seems to have worked out fine:

[16/07/2011 03:19:07] Result: 228e3757 accepted
[16/07/2011 03:19:38] LP: New work pushed
[16/07/2011 03:19:40] Result: 0190214a accepted
[16/07/2011 03:19:40] Result: 1341c3ff accepted
[16/07/2011 03:19:43] Result: 837157d0 accepted
[16/07/2011 03:19:44] Result: 698b286a accepted
[366.86 Mhash/sec] [2136 Accepted] [13 Rejected] [RPC (+LP)]

That's ~0.604% rejected.

[ItsASpork]

Right now I have 3337 accepted and only 40 stale, which works out to 1.198%. Still better than any other pool, with slush I used to get as high as 10% rejects.

[pandemic]

Me and my girlfriend took a trip to the DC a few hours ago.
Installed a couple of new drives on the node for local storage and bin-logs.

Some fast benchmarks:

root@staging:~# hdparm -tT /dev/xvda1

/dev/xvda:
 Timing buffered disk reads: 652 MB in  3.00 seconds = 217.16 MB/sec
 Timing cached reads:   5302 MB in  1.99 seconds = 2658.56 MB/sec

Eveything seems to run a lot smoother now, with the load balancing up and running and everything working as it should.
We have dropped a lot in hash rate over the few past days, possible due to the extremely long run before.

I hope we gain some more so i can prove that we're a lot faster, stronger and more stable now
Also, the patch for rejected shares seems to have worked out fine:

[16/07/2011 03:19:07] Result: 228e3757 accepted
[16/07/2011 03:19:38] LP: New work pushed
[16/07/2011 03:19:40] Result: 0190214a accepted
[16/07/2011 03:19:40] Result: 1341c3ff accepted
[16/07/2011 03:19:43] Result: 837157d0 accepted
[16/07/2011 03:19:44] Result: 698b286a accepted
[366.86 Mhash/sec] [2136 Accepted] [13 Rejected] [RPC (+LP)]

That's ~0.604% rejected.

I'm spooling up my 400mh/s for another mining night. I can only mine at night when it's cool. It gets too hot without mining during the day.

Typically my 5830 gets 2-3% rejected. The other day it was 1.9% which was the lowest ever. Hoping to beat that tonight!
The 4870 normally gets about 5% for some reason. Still have to look into that one


Either way, glad things are getting sorted out. Thanks for your hard work!