Topic: [~1000 GH/sec] BTC Guild - 0% Fee Pool, LP, SSL, Full Precision, and More - page 3. (Read 379035 times)

Copied from my post on Slush's thread:

Better yet, everybody should hop to a small pool during major outages/downtime.  Everybody jumping to BTC Guild ends up screwing over our regular users.  I've been removing servers from our clusters the last month due to shrinking speeds/profits.  We cannot handle 2+ TH/sec like we used to, because it isn't worth keeping up the hardware at this time.  That's why I'm looking at cancelling signups (private pool) or a major payout structure change:  Get the botnets off and keep our regular users with a stable pool.

So please:  If you mine on Slush, Deepbit, or BTC Guild, set your backup to a SMALL pool.  Not only is it more reliable (the major pool outages are often related), but it avoids putting unexpected heavier load on an already large pool.  And of course it's safer for the network to have the hash split between a larger number of nodes.

just switched pools and now is the same thing happening  that happened to Deepbit today?

It means I would provide 500 BTC so the pool has a sufficient buffer to start.  If the pool had good luck and built up some good luck after the switch I would slowly pull out the initial funds used to start the buffer.

I've not yet posted the poll.  I've been working overtime this week so I only have a few hours each night to get any other work done.  I have been in conversations with some of our oldest (and some of the largest) miners at BTC Guild before I open up any polls.

What does that means?
The pool starts with 500BTC buffer (you are going to provide the BTC) OR the first 10 rounds don't get payed?
If you plan to provide 500BTC ... i would say it's a bad idea ... start the pool with 0 buffer and let the "fortune" to fill it.

There is nothing wrong.  Hasn't been outside of the one problem I edited into my post, and its affect on our total luck has been negligible.  Play around with standard deviation all you want, it doesn't provide anything other than a benchmark.

Edit for clarification from one response in IRC:
DDoS's don't affect our luck.  Botnets don't affect our luck.  Anytime the pool is down, it means that there are no shares being counted, so it doesn't affect the end total on the round.  If the network connectivity is bad, at worse it will increase the frequency of invalid blocks, but the shares/round data will still reflect "actual" luck.

yes, but with 3500 rounds you have only 1.8% standard deviation, while luke with 770 rounds has 4% standard deviation.
So you don't fit in standard deviation Maybe you should check if your mini-pools could have some communication problems, or something else.

I like how your same stats show Eligius having the opposite (4% positive vs 4% negative).  People seem to think luck can only be positive and never negative unless there is either a technical problem or sinister force at work.

The only technical issues which had a negative effect on luck were about 3 months ago, where for about 1 week there was a period where work was being accepted on multiple servers as valid, even though it could not solve the block unless it went to the original server (so multiple shares being counted).  Maybe a fraction of a percent effect over the course of the pool.

I did some analysis, and I need your help to find out why BTCGuild has 4% luck problems.......

https://bitcointalksearch.org/topic/btc-guild-has-4-efficiencystalesfee-problem-48889

Not that my 1 GH/s matters, but if there was a switch to PPLNS, I will move back to BTC Guild. I would love to combine by far the best pool UI with the simplest pool hopper proof payout structure.

The poll will be up tonight.  It will be a separate page, not a simple poll.  The options will be randomly ordered on each page to escape the problem where people tend to pick the first option.  The page will offer details on exactly how each system works.  The following is a brief summary to get some more conversation going on in this thread.  Obviously the poll on the website will not be the sole determining factor of which system we use, but it will weigh heavily on the final decision.



SMPPS (Shared Maximum PPS):  It's basically PPS, but capped at what the pool has earned to date.  When the pool has good luck, the extra BTC is added to a buffer.  When the pool has bad luck, it continues to pay PPS rates as long as the buffer has any balance remaining.

SMPPS is basically no variance, unless the pool experiences significant bad luck streaks without any good luck streaks to rebuild the buffer.  I will set the initial buffer to 500 BTC.  Details on the buffer will be visible on the stats page if this is the system we end up using.




PPLNS (Pay Per Last N Shares):  It's much more like proportional rewards.  On any block solve, the last N shares submitted are allocated rewards proportionally.  This is completely hop proof, and the rewards fluctuate with luck.  During periods of good luck, you may see the following:

N = 1,000,000
You submit Share #900,000.  A block is solved at #1,100,000.  Shares #100,001 through 1,100,000 get paid just like a proportional pool.  Then another block gets solved at #1,200,000.  The previous 1 million shares get paid out.  Since 1m shares have not elapsed since the last block, Shares #200,001 through 1,100,000 get paid a second time.  A higher value for N means each share is paid less, but it has a higher chance of being double paid, and a lower chance of not being paid at all (if a block lasts more than N shares, some shares are not paid). 

In the end, a 24/7 miner would see essentially no change from proportional.  A part-time miner will see more variance (since it's possible to get paid many times for 1 share, or not at all, depending on luck after you turned your miner off).

Moved 14k MH/s over here this morning. Let's hope for stability! Yeeee haw.

That was just an example.  My dedicated machine has a 5830 and 5770, but the same scenario could happen because of network congestion or other hiccups out of my control.
Sam

Can you confirm that on SMPPS model too?

personally i like pay per share. And I agree, when you have a slow miner, you get screwed out of your shares on many pools.

That's all well and good.  But what is the exact explanation as to what these payment methods are?  All I ever hear anyone saying is the N stands for the amount of time you are in that round.  How is that variable measured?

I have a non dedicated machine with a low end GPU mining 24/7 and the pools often say the miner is not active because it may not submit a share for 2 or 3 minutes, just now it took 10 minutes to submit shares but it is still churning away at 34.5Mhs.  So do I get dinged for that? do I get banned for pool hopping?

I think we needlessly over complicate things sometimes.  I'll just wait to see what Eleuthria's explanation is when he posts his poll, I guess.
Sam

   Aye, I can verify about a 20% loss in expected earnings on days I stay solely at Prop pools.....   SMPPS variant ftw..

They make the pool less attractive to pool hoppers and trust me people are hopping the living shit out of BTC-Guild.  You short blocks get split many way and your long blocks get split few ways.  If you tallied your total shares contributed and total earnings you will find you made significantly less than "expected value".

I say use the KISS method (Keep It Simple Stupid).  Straight Proportional w/2% fee and PPS.

These other payment methods seem to try to reduce flexibility of the miner and are hard to verify.  But of course I haven't seen a good explanation of them either.
Sam

Aside: I LOL at the "Invalid Protection" 'issue'

No.  I'm hoping to get it on the PPS pool this week/weekend.