[~1000 GH/sec] BTC Guild - 0% Fee Pool, LP, SSL, Full Precision, and More

[Nesetalis]

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.

[TheMalon]

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.

Can you confirm that on SMPPS model too?

[os2sam]

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 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

[Hotdog453]

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

[eleuthria]

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).

[sirky]

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.

[cosurgi]

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

https://bitcointalk.org/index.php?topic=48889.0

[eleuthria]

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.

[cosurgi]

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.

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.

[eleuthria]

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.

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.

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.

[TheMalon]

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.

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.

[eleuthria]

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.

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.

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.

[superman3486]

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

[eleuthria]

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.

[eleuthria]

No ETA on pool stability at this time, losing 40% of our public facing servers has caused some major issues.  Everything seems to work fine an hour or so but then it comes crashing down.

[eleuthria]

I have made a post on the front page of the website, identifying the current plan for future steps with BTC Guild.

Until the change is made, the pool will continue to operate normally (as best as it can).  I simply am not willing to continue to invest money buying new servers to fix the current temporary stability issues.

[kripz]

Website is down, can you post here?

[Iyeman]

Website is down, can you post here?

Not down for me but here is what it says

BTC Guild started on May 9th, 2011. In that time it went from a small pool on my home connection, to a dedicated server in a DDoS resilient ISP, to 9 servers spread across the globe, and then consolidated multiple times to try new technologies/scaling methods.

From day 1, it was my goal to run this pool on a donation based model. Bitcoin was growing, not only in price, but in visible support as new people become aware of it. However, in the last three months, the number of botnets has continued to plague this pool, and constantly grows even though I have attempted many ways of banning them. Attempts to ban them have lead to two specifically targetted DDoSes which lasted 3 days each, and other DDoSes that have hit all three of the largest pools (and some which hit smaller ones).



Paired with the sinking price of Bitcoins, the not shrinking price of my servers, and the excessive amount of time spent trying to keep the pool online during attacks, continuing to run as a 0% pool is not viable.



In the next week, the pool will be transitioning from a 0% proportional bitcoin pool, to a fixed fee pure pay per share pool that includes merged mining. This will be similar to the current PPS Guild beta. I expect many users will leave, but those who stay will likely experience a truly stable pool, with no variance.

PPS Guild has been up and running for over 1 month straight, and has required no intervention. It has had some of the lowest stales of any pool, truly instantaneous rewards, and simple to use interface. I want to bring that simplicity and stability to all the users who decide to remain with us after the transition.

The fee of the new pool (with PURE PPS) will not be as high as the current PPS beta, due to the addition of merged mining, which adds a second luck factor to help balance us towards neutrality.

[eleuthria]

Fixed the blocks that were stuck waiting on confirmation.  Got my nulled servers back and was able to turn the bitcoind back on.

[Tim the Magician]

In the next week, the pool will be transitioning from a 0% proportional bitcoin pool, to a fixed fee pure pay per share pool that includes merged mining. This will be similar to the current PPS Guild beta. I expect many users will leave, but those who stay will likely experience a truly stable pool, with no variance.

Is there anything members have to change? or will our workers just be converted over when the pool changes?