Website is temporarily offline while I do some major updates to how the site stores the 24-hour/72-hour/1-week charts.  Mining is unaffected, the website is only turned off to prevent people from accessing the database tables while they are being heavily trimmed.


UPDATE:  Website back online, sorry it took a little longer than expected.

To avoid confusion:  I've been changing how many shifts are used in the average displayed on the PPLNS Stats page.  This stat used to be 100 shifts, which was approximately 48-50 hours worth of time.  With the increase to shift sizes to reduce per-shift variance, and ASICMINER moving ~50% of their hashpower to solo mining, this was ending up closer to 96 hours.  Currently it is at 50 shifts, which is roughly 2 days.

Later this evening it will be adjusted to show approximate 24, 48, and 96 hour averages.  Please note that the averages will tend to be much higher than PPS Rates after a difficulty change since they are mixing the current difficulty and previous difficulty.  As usual when looking at past reward averages:  Past results are not an indicator of future performance.

I'm the enemy now?  Guess I'll just keep all these cookies for myself then

I responded in your mining support thread (stumbled upon it yesterday).  Your account (assuming its the same as your forum name) has never set a wallet address to send funds to.  Go to your settings page to set one.

The automatic payout warning is likely because you're trying to use a value that rounds down to 0 (you have to use multiples of 0.01, it will floor the value to the nearest 0.01 if it contains extra decimals).  Since you're already set at 0 by default, the server doesn't see anything change in the database, thus there was an error updating it.

Thank you .  I've been lucky recently that the pool has been very stable, so while you don't see many positive comments, the pool thread has not had many negative comments either [aside from the luck based posts].

I've also updated the News section on the website to give a little more detail on what occurred.  It isn't significantly more than what was on the forum, but it is more than originally showed up on the news section.

Luckily the duration of this double awarding was not very long (~8 hours).  As a result, even the most harshly affected (payout requested JUST before it was caught) shouldn't require more than half a day to rebuild their balance.

Three was a bug in PPLNS earnings calculations earlier.  I'm looking into it now to determine how much has been overpaid and whether or not it is enough that it requires correction.  Site temporarily unavailable while this is going on (shouldn't be more than 10 minutes).



UPDATE:  PPLNS shifts 6393 - 6403 had received multiple payouts from the same block(s) last night due to some problem with database load.  Some shifts received roughly double what they should have.  Since this affected so many shifts, the amount of coins being overpaid was too high to ignore.  The shifts rewards have been corrected, with ~1 BTC extra thrown in across the shifts to round up the rewards.  Some accounts may show a negative balance if they requested payouts that were only possible due to the excess rewards.  As usual, you can either mine back the difference (you were paid more than you should have been owed), or make a new account.


After seeing this bug, I'm now adding a new sanity check to the PPLNS reward allocation script to make sure it does not repeat itself in the future.

Pool servers are being restarted due to a problem with the database server.  While I could have left the pool servers online, I felt safer letting miners hit backup pools rather than potentially lose share submissions.

UPDATE:  Pool servers are back online.  Sorry for the inconvenience.  Worker speeds will be slightly inaccurate for a few more minutes.

Didn't see the question show up in the pool thread, but did stumble upon this one (I rarely visit the Mining support forum).

As the error states:  You don't have a valid wallet on the account.  You need to add a wallet to your account before you can receive payouts.

The auto payout error is likely because you're trying to set a value that is too low and it's getting rounded down 0, thus when the script executes it doesn't see any rows in the database change, thus assuming there was an error updating the information.

Actually, I was saying your logic was incorrect.  Because of how p2pool works, it's less about your absolute reject rate (15%) and more about your relative reject % compared to others in the pool.  If everybody was having the same reject rate as you, you *should* earn the same as you would on a pool with a 0% reject rate.  However, I think 15% is probably way too high even for p2pool (I have never mined on p2pool, so i can't comment on what a "good" reject rate is).

The drop is entirely ASICMINER.  As of this post, we are at 31,600 GH/s, with ASICMINER at 7,600 GH/s.  Our peak speed was roughly 39,000 GH/s, with ASICMINER at 14,500 GH/s.  So ASICMINER is down 7,000 GH/s, and the pool is down ~7,000 GH/s from peak speed.



I can't say for sure.  Normally PPLNS should not be vastly different, but in a 24-hour window many things can happen.  As I've stated earlier, we have had two extremes in the last month.  One day where PPS was earning roughly 60% of what you'd get at neutral luck (so -40%), and another day where you were getting roughly 50% more than what you'd get at neutral luck.  Both of those are quite rare occurrences, and daily variance should *normally* be much lower, but I'm not confident enough to give a hard percentage for "average" 24-hour variance.

Yep.  Like I've said in the past, 24-hour earnings with PPLNS is time-delayed ~6 hours due to the mature time on PPLNS.  Actually, it's closer to a 10-hour delay now that ASICMINER is moving more into solo mining.  Still very short (shorter than any other PPLNS pool I think).  Luck did bounce back fairly well, though we're still going to need more of this type of luck to make up for the negative trend the pool has been on.


Very likely going to get into merged mining testing next weekend.  If I can figure out a good way to implement it in the pool software, I will probably go with multiple altcoins similar to what bitparking does.  Hopefully that will keep people excited even when luck is sour.

Because of P2Pool's...p2p nature, the reject rates are higher than you will see on any pool.  It's just the way it works due to the share chain which moves 60 times faster than the bitcoin block chain.  However, this high reject rate affects all users.  This means your real goal is to have your reject rate equal to or lower than most other users.

There was one user that came back to an account of 80~90 BTC during the >$100 rally.  I bet that made them pretty happy .

All the data is still in place if the user ever returns.  Users have come back after over a year of inactivity and found hundreds (or thousands) of dollars worth of coins waiting for them.  Forcing payouts to the last address on file has been suggested in the past, my only concern about that is that for inactive accounts, a SIGNIFICANT number of users back then were using e-wallet services or one-time exchange addresses.  As a result, these addresses simply can't be accessed by the actual owner of the account anymore (theft/stolen/no longer valid).

My policy so far has been that if BTC Guild ever needs to close its doors, I will leave the site open at least 6 months in a withdrawal-only mode for users to reclaim whatever was left in the accounts.  A withdrawal-only website would not be costly to keep online for quite some time.

I'm doing some background work right now.  Back in June of 2012, I "pruned" the database of users that hadn't logged in since the change to PPS.  Since then, user accounts and pool workers have mostly been accumulating rapidly for almost a year.  Many accounts have not logged in since early 2012.

I'm currently in the process of pruning the database of any users who have not logged in for 1 year.  This is a complete removal from all active database tables.  A full backup was done prior to starting this obviously.  The criteria for being pruned is as follows:

1) The account has not been logged into for 12 months.
2) The account has not had any mining done for 6 months.
Both of these must be true for an account to be pruned.

My hope is this will speed up certain scripts, specifically the graph generation script and the automatic payouts.  Users who try to log in after their account has been pruned will receive a notice of what happened, and told to email me to begin an account restoration.  All data being removed is fully recoverable if the user ever decides to return.

NMC merged mining is still only available on one getwork server (mergedmining.btcguild.com:8332).  I've purposely hid it in the past because I want to get rid of getwork.  Recently I have given *some* thought to adding merged mining of the various altcoins that support it, but too early to tell.  I've been getting bit by the coding bug recently, and last time that happened I created a new mining protocol+pool server...then replaced that mining protocol with Stratum to avoid a protocol war.

I've fixed a bug that was affecting users that have NMC displayed.  Due to changes in how PPLNS shifts are recorded/cleaned up, and an oversight on the Dashboard, users with NMC displayed were seeing their 'Current Shares' stat reset constantly.  This didn't actually affect their shares being included on PPLNS, it was just an error in displaying the shares in the current shift until it was completed.

This bug has been around a while, but probably wasn't noticed/reported due to the fact that until recently it was not possible to merged mine with PPLNS as the payment method.


As an aside:  Yay for blocks getting solved!

Double posting just because I've been staring at this for so long that I'm actually feeling like I'm going through depression.  But thinking more clearly:

Just a few days ago, we had some VERY good luck.  A day or two before that, we had almost 20 hours straight of having shifts end between 10 and 60% above PPS.  Absolutely NOTHING has changed on the servers since that time aside from rolling the one server (which only has ~7% of the pool speed) back to 0.8.1 from 0.8.2.  So for it to be a software glitch causing the unusual bad luck we're having right now, you would have to expect that we should have had -even better- than that luck just a few days ago.

As I posted earlier, there were two "glitches" in this last week.  One was affecting many pools:  There has been a spam/dust "DoS" attack on the network that has been drastically slowing down bitcoind nodes.  BTC Guild does not currenlty use "empty" templates as a base when a new block is found, because the idea of making blocks with 0 transactions is just wrong.  However, as a result, this last week many of the pools were stuck for 4-6 seconds after each new block.  Many updates were being done to try to fix this, and recently sipa released a patch to drastically speed up creating new proper blocks.

The other glitch was one server [no others were found to be doing this] was crashing when submitting blocks.  I have not yet found out why it was doing this, but I rolled the bitcoind software back and it has not happened since.  That would not be a huge impact though, but it would contribute to the last few days of luck (5-10% maybe).



Very little has changed on the server side recently to cause any kind of software glitch (aside from the server that was updated to 0.8.2).  I'm actually starting to wonder if perhaps the problem lies outside the pool, possibly in the Avalon implementation of cgminer.  The luck has been trending negative since the time Batch 1 started showing up in large amounts.  I'm fairly certain BTC Guild has the highest % of Avalon users as a portion of the overall pool speed as well.