Topic: [CLOSED] BTC Guild - Pays TxFees+NMC, Stratum, VarDiff, Private Servers - page 153. (Read 903163 times)

I've been asked a few times, so here's a breakdown of what this latest round of updates to backend code will result in for the end user:

1) Improved server responsiveness due to load splitting across cores.  This should result in a marginal decrease in stales across the board.  While the majority of stales are due to latency between the pool and the miner (and additionally the hardware), there is always a marginal chance of stales due to increased processing time when new blocks hit.

2) Faster block notification from bitcoind to the pool server.  This will reduce the time the pool spends working on an old block.  The current system polls bitcoind very rapidly to find out about new blocks.  The new system uses bitcoind's blocknotify to send a signal to the pool process.  This should reduce the time from an average of ~15ms between notifications to 1ms or so.  Similar to the drop in stale rate, the actual timing difference is somewhat difficult to measure, though definitely an improvement.

3) Uniform worker names.  BTC Guild uses '_' to separate the username and worker name sections.  Some pools use '.' and some pools don't use anything.  I have had quite a few people coming from pools that use a '.' emailing me/PM'ing me on IRC with issues where the problem was a '.' instead of a '_' in their miner settings.  The new pool server will rewrite this change so that either one will work.  Additionally,  if you fail to specify a worker and only use your pool username, it will automatically default to the '_1' worker.

4) [Future Benefit] Additional merged mining coins will almost definitely be added in the month of January.  This will likely be the full suite of merged-minable coins (NMC, IXC, DVC, I0C, Groupcoin).

5) [Possible Future Expansion] There is a chance with this new server that the frontend will be rewritten in how it interacts with the pool servers, specifically for estimating worker speeds and whether or not a worker is idle.  This possible change will be first tested on Scrypt Guild since there is no existing framework already in place for those two functions for Scrypt Guild.

=== Scrypt Guild Benefits ===
All of the above will apply to ScryptGuild as well, since the core for both systems will be the same.  On top of the above, this new code is being written with the assumption that it is possible to run multiple types of coins in a single system.  This will allow Scrypt Guild to have user-selectable coins via the web interface.  Eventually this can also be expanded to profit switching based on coin profitability.




Just thought I'd clarify the above since a few people have asked what all this means for the end user.  While my focus in previous mentions of this work have all been about server stability/efficiency, it isn't always clear how much, if any, of that will end up being visible for the miners.

Depressing... 

Difficulty adjustment ETA: <30minutes

The US stratum server (frontend/initial server) is now running the new codebase.  Had an eventful day of bug chasing as little quirks showed up on the live deployment that weren't present when testing it in a development environment.  So far things are looking excellent, and the known issues have been ironed out. CPU usage on the server which is almost always being slammed by botnets is only 1-3% per core, a huge improvement in general efficiency (using all cores) and overall efficiency (less total CPU).

The backend servers will likely be updated to the new codebase over the next two days.  Scrypt Guild will begin development once that deployment is done and confirmed to be functioning as expected.

Website errors like the ones posted above are on Cloudflare's end, not BTC Guild's.  Unfortunately, I can't do anything about them.  The benefits gained from using Cloudflare outweigh the cost of the occasional certificate error message.  Luckily they are (normally) region based, rather than affecting all users at once.

its back again.

certificate-server seems to be down.

you can dissable ocsp temporarely.
https://support.mozilla.org/en-US/kb/The%20OCSP%20server%20has%20no%20status%20for%20the%20certificate

I cant get on btcguild website:(Errorcode: sec_error_ocsp_unknown_cert)

The problem with botnets is that outright banning them turns their zombie PCs into a non-stop DDoS as they spam reconnects with the mining software.  Blocking them upstream isn't exactly viable given how many of them there are.  Not many places will let you setup a deny list with hundreds of thousands of individual IPs, with constant updates required.

The validation server acts as a tarpit, keeping the botnets stuck while letting good miners through.  It's not perfect, and it has ended up making some legitimate mining software not work (GUIMiner).  But the good has outweighed the cost.  The few botnets that get through I'm able to identify after the fact, add them to a block list, and then the next time their zombies connect to the validation server they're stuck there instead of getting passed through like good traffic.

Sadly that doesn't quite work for things like spambots.



UPDATE:  Validation server is back to the old code for the night.  There's a few tweaks to be made for tomorrow.  Probably won't be going live on the backends tomorrow just because I don't want to have it running for only a few hours before I get some sleep tomorrow night.  Would prefer to launch it first thing in the morning Monday so I can watch it the entire day.

Just out of curiosity, how do you filter out the botnet connections? On second thought, this is probably something you don't want to disclose publicly. And it's just an intellectual curiosity on my part. I run a forum (unrelated to Bitcoin) and botnet countermeasures (to combat forum spam) have become something of a sport for me, so I'm always eager to hear how other people have solved similar problems.

Well, it took a few hours of debugging little issues, but the US validation server is now running the new Stratum code, and hasn't crashed in the last 10 minutes.  Not much better you can do in terms of stress testing than putting it up against the server that is constantly being spammed by botnets.


This is going to be left up for the next few hours, then I'll swap it back to the old one when I head to sleep for the night (just to be safe).  Tomorrow's work will be focused on adding in the few pieces that are needed to put this up for the real backend servers.  The new server is showing fairly significant performance increases thanks to the much improved threading model.

If anybody is having problems starting up their miners, let me know!  I've tested it myself with my little USB Block Erupter, but there's a lot of software/hardware variants out there.

Users restarting their miners or new users first connecting might experience intermittent connection drops over the next few hours.  They're spaced far enough apart for any average miner to get a share in easily and get redirected to the appropriate backends, at which point they're safe from the drop.

The new Stratum code is getting its first deployment on the botnet/ddos validation frontend (stratum.btcguild.com).  Since this server is only actually used by users for a few seconds (time to get one share submission), it's the safest place to give this new code a live test against the onslaught of botnet miners always trying to access the pool.


Sorry if anybody here is affected by it, but like I stated above, this server shouldn't actually affect anybody unless they just happened to restart their miners as the server was being swapped between the old and new server processes.




99.7% acceptance rate is pretty good.  My general target for users is 99.5% or better before there may be a problem (and in some cases that problem is just the firmware/hardware they're using and the reject rate will follow them on any pool).

Hi

Could someone let me know if these stats are okay or is there something out of whack? I'm just not sure what the normal rates are.

Total shares 2032928 (99.70)
Stale 6048
Dupe 672

And as stated above "If you dont pay for a product, you are the product."

I mined with eligius when I first started but someone else posted the above and I've never looked back. Thanks for the great service and product.

if he took xGh/sec from all his miners - THATS A FEE.


// update: ......aaaand someone was quicker.. aaaaaaaaahrg  

There's no difference between giving a pool operator 1% of your hashrate or paying a 1% fee.

Or the operator can take %1 of all our hashing power and put it into his own account? He would make a lot more money. Right now with all the users that are here, I can guess that a pool operator with these fees probably brings in $80-$100k/year. If he took 1GH/sec from all his miners, he'd make a whole lot more money and we'd pay less fees, right?

the fact that the pool takes fees is just a nother phrase for the fact that your bitcoins are safe* in the pool and are likely to be send to you.

if the fees are to low for the pool to operate the pool (and your btc) will be gone one day**
OR
the money hav to come from somewhere else.

If you dont pay for a product, you are the product.


_____
*yes even from a thechnical perspective.
if the poolowner makes money, he is likley more motivatet to spend a lot of recources at security.

**50btc, anyone?

Unlikely.

is this the greedy beggar thread?

Donations?