Well, the great news first:  The new stratum code has not crashed in the last 3 days while being exposed to the most volatile server (the frontend used for filtering botnets/ddos/validating miners).

Good news:  The new code is also now interacting with the website properly for all Worker management functions (renames/payment method/difficulty).

Bad news:  It hasn't been deployed to backends yet.  I've been spending all day trying to break the new code in a way that would allow a user to get credited for shares they shouldn't.  So far, this hasn't worked (which is good).  Everything used for share validation was copied from the old code, but some changes to the structure of work assigned to miners have required rewrites on areas which I know other pools have screwed up in the past (50BTC accepting lower diff work and crediting it at the adjusted diff, for example).


It's been a long project (2 weeks instead of 1), paired with some downtime from illness, but I think all this time will be worth it in the long run as it expands how much can be done with the pool backends.  ScryptGuild will be expanding on the backend even more, experimenting in some additional interaction between frontend & backend, and the changes which work well will be ported back to the BTC Guild side if they're more efficient or more responsive.

I'm still not a huge fan of NMC itself.  It had a good idea.  It does still work.  But the implementation feels so terribly inefficient for what it's being used for.

However, at least it had a good idea, and does have a purpose outside of market speculation (even if bulk of its price is pure speculation).  DVC/IXC have no such redeeming qualities.

NMC had/has a purpose.  DVC/IXC are just garbage coins.  Big difference.

Sounds like the "Please try again." Solution worked. This is something that will likely be more streamlined in the new stratum back end being deployed. Instead of asking the user to try again it will add failed attempts to a retry queue.

DVC/IXC are likely coming near the end of the month.  Not a high priority (they're essentially worthless).  I've been finishing up the new stratum backend this week, and have now done a full test for share submissions/logging and solving blocks on testnet.  It has also been holding strong on the botnet/ddos filtering server, with very low resource usage.  It will likely be going live on one of the BTC Guild backend servers tomorrow, and once it has solved a few blocks, live on the remaining backends.

EDIT:  Rewritten to reflect updated information


The "Block Rewards" table is a calculated value, since your actual rewards are determined by the shift payments.  It's fairly accurate, usually within a few decimals (normally past the ones displayed since rewards are tracked out to 14 decimals).

It looks like the block in question was recorded twice.  This was likely due to bitcoind being extremely slow (it's time to defrag the payout wallet).  I've tweaked the table where it records blocks to prevent a block from showing up twice.

Since the Block Rewards table is keyed based on the Block #, but the payouts are keyed based on an internal ID, it was looking up the rewards for the block twice (since it was recorded twice), but only used one ID, resulting in only half the reward being displayed.


I've removed the double-payment of that block, and the value in the Block Rewards table should now be showing up correctly.

PM answered.  Clicked it last night and it was on a new page so I missed the previous page of messages.

It wouldn't...either you're comparing bad numbers (one with downtime in the average window), or "much higher" is only a few %, which is standard variance.

p2pool should always beat PPS on BTC Guild in the long run.  That's the trade off you make for PPS:  Steady income at a high fee vs extremely random income at low/no fee.


A much better benchmark is comparing BTC Guild PPLNS to p2pool.  But even then, as zerokwel pointed out, luck is going to be what determines anything.  In the extremely long run, p2pool will win (low fee).  But BTC Guild will be MUCH more steady from week to week.  It's up to miners to determine how much steady income, management interface, email alerts, etc., are worth to them.

Could've been worse.  Try being in my shoes where I was too sick to get out of bed for more than a few minutes at a time, and there weren't any signs of issues I could identify via my phone until a few hours after it started (due to the fact that it was only stopping new/restarted connections).

The private servers have been around with BTC Guild, and actually quite a few other pools have had them as well, for over a year.  Whenever a strong, persistent DDoS hits, one of the first things pools do is try to get a server running and slowly spread the connection information to users with a long history, or a high speed.  BTC Guild pre-emptively gives out this information to high end accounts.  The logic is pretty simple:  The more you have invested, the more downtime hurts you.  Obviously it's in my best interests AND the user's best interest to have a server designated for those types of clients.

There have also been semi-private (designated this way because the criteria for receiving them was not strict) servers distributed during previous attacks, most of which are still online and available to this day.

If some of your miners lost connection, that may have been why.  The frontend server's purpose is to keep the bad traffic from ever reaching the "real" mining servers.  Today that frontend server was rendered almost useless due to the scale of bad traffic hitting it, virtually killing off the ability for any legitimate traffic to get through.

Anybody already connected did not suffer any issues or downtime, since they were no longer connected to that frontend server.  I'm sorry that the downtime for that server was as bad as it was (~6 hours).  I've been spending most the day unable to get out of bed due to illness.  I've been checking my phone every few hours to make sure things were working.  Until recently, there was no visible sign of anything wrong (pool speed was in the 3300-3400 TH/s range through 11:30 PM, which is the expected speed).  It was only when I checked around 1 AM that the pool speed had decreased (from 3360 to 3060).  Since the frontend server is *expected* to have spurts of downtime due to attacks (DDoS, botnet, or other), it doesn't cause the same alarms to trigger that the backend servers do.

However, since the server did have an issue that didn't fix itself as it normally does, it's now set to trigger the standard alarms for the next 24 hours if another event occurs.

The frontend server was getting slammed by a couple of botnets extremely heavily today (ranging from 30,000 to 90,000 stratum connections simultaneously).  It's been restarted and a few new rules added to prevent those connections from ever getting established to the server process and locking things up.

Public and private servers had no problems during this event, which is the entire point of that frontend server.  Only *new* connections (or miners restarting) were affected.

No hop proof method penalizes users for splitting hash rate or stopping mining.  The only one that comes even close to that is slush, where you are penalized if you stop mining before the end of a round.  But even in that case, you end up averaging out the same because while 95% of the time you get screwed, 5% of the time you're rewarded enough to make up for those other times.  For non-slush hop proof methods, there is ZERO penalty for intermittent mining/stopping mining/mining slowly.

The only way to know your hashing rate (and thus adjust your difficulty) is if you're actually submitting shares.  Starting that high would make low hash rate miners virtually unusable on the pool.  Yes, it averages out over time, but most users have no clue how difficulty works in the first place and would just see BTC Guild not giving them any credit for an hour.

It's very quick to adjust a miner UP in difficulty (or they can just set it themself).  It's much harder to know if a miner needs to be adjusted down.

Jupiters (and quite a few other ASICs) experience big issues when mining at low difficulties due to just how rapid they produce shares.  In the case of a Jupiter, at the default difficulty (2), it's producing about 50 shares per second.

BTC Guild adjusts difficulty very rapidly for miners at that speed, to help them get to an appropriate difficulty.  Of course, some miners have problems with the work updates pushed by difficulty increases!  BTC Guild can push those in very rapid succession if you start at the default difficulty on a 400 GH/s+ machine as it tries to get your difficulty to an appropriate level.

Setting a minimum difficulty prevents this entire process from taking place .

Guinea pigs will be hand chosen (AKA:  mass invited) in IRC once it is ready.  I'm going to avoid giving any dates until it's closer though, after the hangups that I hit on the main backend over the weekend (most of which have been resolved).

Primecoin probably won't be added.  My understanding is the proof of work verification for Primecoin is drastically different from the other coins, so it wouldn't be quite as simple to implement (certainly wouldn't work for a multicoin pool).

I'm assuming this already sorted itself out.  The estimated speed has always used a large window to determine the average speed.  If your miners disconnect for a while (restart) and you turn them back on, it will take about an hour before your estimated speed returns to normal, since you have a period of no hashing.

Absolutely *nothing* has changed on the frontend or backend mining servers.  The server currently being used for testing is the validation server, which you're only connected to for a few seconds at most if you're running decent hardware.

Yeah, unfortunately I was overzealous in my original timeline predictions.  It's amazing how many little bugs can slip through internal testing.  As much as I tried to break things on my local testing, it can't compete with the complete onslaught of junk data the live servers receive.  The new backend is *very* close to complete now, and is getting significant live testing for the majority of its functions already.  As soon as the backend is confirmed ready, Scrypt Guild will begin to take shape.

BTC Guild has been mining NMC for months.  It mined it during most of 2011, all of 2012 for users that wanted it.  It was only unavailable for a few months in early 2013 when getwork was shut down and it had not been added to the Stratum code yet.  During the few months it was unavailable, it was virtually worthless.