We were faced with an easy decision:

1) Stay on the 0.8 chain and anybody that did not immediately upgrade would quickly be ripped off as awareness of the problem grew among the community.  0.7 would NEVER be able to rejoin that chain without upgrading/configuration changes.

2) Go back to the 0.7 chain, which all active nodes would revert to, heavily limiting the potential for any double spend attacks to be successful.


Yes, we would all like to kill off 0.7 and move to 0.8+.  0.8 sped up Bitcoin greatly, making it easier to start up and use.  It made pools faster and more efficient as well.  But the option was to force an unintended hard fork forward, or bring the network back together by downgrading until a patch can be deployed with a that works the constraints of the BerkeleyDB bug until a predetermined time, giving users a chance to upgrade.

In the end, it took under 7 hours for the blockchain to revert back to a universally compatible version (0.7).  It was possible for somebody to have slept through the entire event, it was resolved that quickly.  This could have been a disastrous situation if we tried to keep moving on a hard fork that nobody knew was coming.

In no way is it a "dangerous precedent" that the core developers and pool operators decided (in a crisis situation) to revert versions to keep the network whole.  A dangerous precedent would have been deciding "0.8 is so much better, they should have upgraded already even though they didn't know it was mandatory."

5 days since emails went out, only one user responding positively, one user responding negatively.  I said I would hold off on the name & shame, but as pointed out in previous posts, there's really no other recourse.  There's no specific legal agreement, and even if there was, most of these users are in a country that wouldn't enforce it, so the best I can do is expose the pseudonyms they used on BTC Guild.

Username	Email	Overpaid
uuhym	uuhym@163.com	356 BTC
bigbomb	bigbom@163.com	142 BTC
xxx123	259282008@qq.com	95 BTC
heley	18678989@qq.com	94 BTC
splinter1338	wrathofbong420@gmail.com	94 BTC
vinest	port5222@yahoo.com	94 BTC
QQ421860256	none	47 BTC
hq	307089667@qq.com	47 BTC
NightAss	nightass@gmail.com	47 BTC
n17r0	craxxxxxxxxx@gmail.com	46 BTC
cwetalin	electron@stemacbg.com	45 BTC
cyco	tonyroy@wcksoft.com	23 BTC
classic729	kgvhz@inbox.ru	23 BTC
youdamushi	lll622root1@yahoo.com.cn	23 BTC
goodlivin	frank@gmail.com	23 BTC

Updated after the post:  For the record, the jerk that sent the email I posted on pastebin was NightAss (nightass@gmail.com).

No worries, the hot wallet wasn't bled out again.  Bitcoind crashed on the payout server (damn old versions!).  Restarting it and pushing through any payouts that got stuck.

Just wait until next week when we move back to a 0.8 branch .  It will reduce the internal window where stales can be created by about 90%, which should restrict stales to less than your latency+50ms (or less).  The 0.7 branch sometimes introduces delays up to 400ms+ at generating new work after a block comes out.  0.8 averaged about 30ms.

Sounds good.  I normally would have recommended upgrading cgminer, but from my experience this bug has been floating around since the earliest Stratum support, but since nobody can reliably trigger it, it just kind of pops up from time to time, so I didn't think an upgrade would have solve it.

Sounds like you might be submitting malformed stratum responses, which is a bug that has affected some users.  To date I don't think this bug has ever been resolved within cgminer.  It sends weird binary data instead of proper hex pairs for the share submissions.  Unfortunately I can't confirm if that's the issue, I removed the detailed logging of those types rejects because it spammed my logs with mostly unreadable data.

It's highly likely this is the problem, because the server is set to completely ignore these types of submissions and just send a reject message, not log it to the database.

You could try running your miners through a local stratum proxy to see if that fixes the problem.

I can't answer for that kind of discrepancy with CGMiner's reject display, unless you're running at a very high difficulty and trying to force submit shares that don't match difficulty.  Other includes 2 types of rejects:  Unknown Work (normally the result of a server restart, pretty rare), and Low Difficulty.  Unknown rejects only count as 1 reject each, even if you're mining at high difficulties, while stales/valids count multiple times when running at higher difficulties.  But I also don't think CGMiner adjusts the A/R numbers to match difficulty.

My suggestion would be reset your stats on the dashboard, restart cgminer, and try to catch when the two numbers diverge, if it ever happens again.


EDIT:  Are you running multiple backup pools possibly?

You have something very wrong on your setup if you're seeing that kind of reject rate.  Rejects did go up slightly with the downgrade to 0.7, but anything above 0.10-0.30% points to a likely problem on your end unless you're mining with a latency of 500ms+.  

Please note that BTC Guild does not include Duplicates in your Acceptance Rate %, because those are entirely the fault of the miner, and shouldn't be used against the pool for your performance.  If you're mining with certain FPGAs, it is very likely you will have a large number of duplicates, but they do not hurt your hash rate because it's a problem in the FPGA<->Miner Software interface causing them to be submitted multiple times.  My own ztex chips on most mining software will submit around 9% duplicates.  However, they will still receive their full 200-208 MH/s worth of valid shares (speed estimates and charts only count valid shares).

I've put up a new poll to gauge interest in Litecoin being added as an option for BTC Guild miners.  BTC Guild has always had a decent number of users which hop to altcoins when they're profitable.  Being able to move between coins without leaving the same pool could be convenient.

This wouldn't take significant work to add, so don't think that voting yes means other parts of the pool might be neglected to get it up and running.  I'm actually hoping to test my Stratum pool code against litecoin this weekend.  My hope is it would be as simple as changing a few database table names, and a single line of code which is currently used to determine if shares meet difficulty requirements or not.

Brief outage on the getwork based server.  Should be back up by the time anybody reads this message.  For those still on it:  Upgrade to Stratum already!

beekeeper, please do not bring unwarranted attacks into the ASICMINER thread.  While you have one point (the hot wallet was larger due to ASICMINER's presence), they have helped BTC Guild significantly with their presence.  Since ASICMINER has joined, we've received many new signups, putting the pool's % of network hash rate back to its highest level since July 2011.  Even if ASICMINER left, the pool has received secondary benefits just due to the publicity of the first large scale ASIC operation starting on BTC Guild.  The pool will earn back its losses faster thanks to these facts.

There was a brief (< 60 second) outage on some of the Stratum servers.  I am sorry this was not announced in advance.  I was working on some tweaks to speed up the 0.7 bitcoind, and unfortunately it seems like it killed the process.  Everything is back up and running now.

Some idle warnings may have gone out that should not have been sent.  Working on fixing this script, which is by far one of the most demanding in terms of DB queries.


UPDATE:  Script now executes in about 20 seconds (including the time to forward emails), and doesn't choke the database up as badly while it's executing either.  Definitely some improvements still to be made, this script was written almost 2 years ago, well before I had as much experience in working with a DB schema designed for such a high work load.

Recovering from a cold.  I lease out my spare bedroom and the friend that rents it was sick over the weekend.  The late nights & stress from Saturday -> Monday definitely didn't help my immune system fight it off.

There's a few plans in store for the pool for the rest of March:

1) Updating backend scripts to be less stressful on the database, specifically PPLNS shift closing, automatic payouts, and idle warnings.

2) Re-updating to a 0.8 branch with limits set to make it 0.7 compatible.  Stales are much more noticeable on 0.7 compared to 0.8 due to how much slower the bitcoind backend is at generating work after a new block is announced/verified.  Unfortunately, I'm not comfortable updating until I know 0.8 has had the BDB limits emulated to prevent another fork in case somebody tries to force a bad block through again.

3) Aliases on rankings so you can have a name showup (doesn't have to be your username, for security).

4) Extra pool statistics related to average user speed (not counting extremely slow users).  Once average user speed reaches a certain point, I will likely update Stratum to default the difficulty to 4 or 8.  Variable difficulty will still eventually drop a user lower if required, but this will help users on ASICs who have not set their difficulty higher by default.

Once the average speed of users grows a bit more, I'm looking into a minimum difficulty of 4 or 8 to start miners with on my pool, rather than 1.  It can still be adjusted down with var-diff, but it will help for users who don't set their minimum difficulty adequately for ASICs.

Bitcoinwatch & Bitcoincharts are both showing bad information.  The current network difficulty is 4847647.

Unfortunately no.  Just the one user (CryptoCluster).  The only other user to respond at all was the one I posted earlier.

To expand on Bitcoinin's response.  Miners on pools do not directly participate in the network in the form of selecting transactions to be confirmed in the next block outside of p2pool.  Some miners do function as peers, if they are running the Bitcoin client locally.  Being a peer on the network is simply running bitcoind or Bitcoin-qt (or certain other clients).  Mining is a separate function from the peer to peer relay of blocks and new transactions.

The main thing you lose out on as a pooled miner is you do not have a direct "vote".  You can't choose to prioritize a transaction or reject one (unless you are on GBT, but your vote requires you to join/leave the pool).  Another example is when BIP16 was announced, it required a majority of the network to mine blocks advertising support of P2SH by including '/P2SH/' in their block coinbase.  Since the pools are the ones that generated the coinbase portion that included /P2SH/, miners could not cast a direct vote, only join a pool that supported what they did unless the pool setup separate servers for miners to cast their vote.

With newer protocols such as Stratum and GBT, this ability to vote in the coinbase may be filtered back down to individual miners (even on pools) if the pool and software both support it.

I take responsibility for the mistake, and I've always felt that a pool that charges a fee on top of having a way to automatically donate felt wrong.  The users that donate are almost always the ones who aren't making much to begin with.  The users taking full advantage of the service with extremely high speeds rarely donate, so it's not fair that those users are subsidized by the significantly smaller individuals.  Note, this is going off what happened back in 2011 when BTC Guild was purely donation funded.  Only a handful of the top 25 even donated 0.1%.  I am not implying anything about the current top users, just relating the empirical evidence that I have.

That's why I've kept the donations/please help off the website.  Most users of BTC Guild are using a service that I provide, and just because something went sour in the background, it shouldn't invade their experience.  It took convincing from some long time users of BTC Guild to make me post any kind of donation method here on the forum.  I posted it only on the forums because I think many of the long time users of Guild who are more active and aware of what's going on would be in here.  We've built a relationship over the years as a service provider and consumer, which is why I've tried to keep the event transparent.

5.6 BTC has been mined by users on btcguild_donate  .  3.62 BTC has been donated to 1GuiLdvH3YjJyEExyTmcd7X2nwX7pZvV7a .  So 9.2 BTC has been donated (either directly or as hash power) since it was made available.  We had 3 avalons (I think) mining on btcguild_donate yesterday for a few hours, which really helped out on the recovery.  As of right now the btcguild_donate worker is at ~1.3 GH/s.  Every bit is greatly appreciated.