[CLOSED] BTC Guild - Pays TxFees+NMC, Stratum, VarDiff, Private Servers

[eleuthria]

I've re-enabled a feature that was turned off a year ago when the pool began sending too many emails and ended up being throttled to the point it was unusable.  When changing your email or wallet address from now on, an email will be sent to your current email to confirm the change before it is made active.  It still won't solve the most common attack vector (compromised email + password reset request), but it will prevent a keylogger that only grabbed your pool credentials and not your email credentials.  Just make sure it isn't the same password on both!

btw, where is pool server located for US? my connection isnt great compared to other pools. I'm using stratum.

The servers for 'stratum.btcguild.com' are actually with OVH in Canada now.  I've had to diversify in recent months to make DDoS attacks less effective (no single point of failure for all servers like the previous colocation).  I'm working on diversifying further with colocation in multiple datacenters.  Until recently the pool was not earning enough to pay for multiple colocations, and I had to wait to see if this was going to be another $32-40 bubble followed by another rapid crash before I invested money in buying more hardware and paying the much higher costs to colocate.

@eleuthria,

Slush lost at least 600 BTC from his hot wallet due to what was apparently an attack by an insider at OVH.  
I'd seriously consider changing away from their hosting.  You might want to ask him what HE thinks about OVH these days.

The OVH that had the issue was only in the EU, and it was not an insider.  It was a very targeted attack and a 0-day flaw/exploit aimed at their password reset system not having enough entropy.  I was on OVH for the EU servers when it happened, but I was able to catch the attacks before anything was broken into, and immediately moved off OVH in the EU.  The OVH servers I have in the US are not registered under an email that is public, nor is it even registered in my name to eliminate social engineering attempts, so the same flaw could not affect them.

However, as I mentioned earlier, I'm planning to expand some of the servers I already have in colocation soon after discussing it with some of the staff related to DDoS activity.  The problem with colocated hardware is you can't easily move to a new server when an attack happens.  Leased dedicated servers can just be dropped/added fairly painlessly.  However, after discussing the colocation with both technical and sales staff, my current setup in Chicago is going to be expanded to move all US based pool servers into that facility.

Core systems for BTC Guild (database, hot wallet, and website) are all hosted on hardware that I own and have placed into colocation.  Only the pool servers themselves are run outside of that, with the exception of Cloudflare acting as a large external proxy in front of the website.

[1713435227]

1713435227

[1713435227]

1713435227

[1713435227]

1713435227

[eleuthria]

64.97% for latest luck...   Wow - That was a punch in the face.....  Ouch.

To be fair, we were at ~145% on the ~15 shifts before that [since they're both moving averages it's slightly less obvious now, but they were literally side by side this morning, ~65% and 145%].  If you just average them out it's still ahead.

[eleuthria]

A small update has just happened in the background related to how the PPLNS Shift data is stored for the current shift.  Once the next shift closes and is verified to be correct, I will be preparing one of the Stratum servers to utilize a new method for recording PPLNS data.  This should, in theory, drastically reduce the amount of database activity required to properly run the PPLNS system, which has been one of the biggest strains on the database server as the pool has climbed in speed.

If all goes as expected, this should be completely transparent from an end user perspective until the Stratum servers are updated to reflect the new database system, which should only require a brief restart (~10 seconds of downtime).

[animan]

My Namecoin balance hasn't moved for the last couple of days. Usually it moves at a much brisker pace than Bitcoin balance.
Is there an issue with Namecoins?
Thanks.

[eleuthria]

My Namecoin balance hasn't moved for the last couple of days. Usually it moves at a much brisker pace than Bitcoin balance.
Is there an issue with Namecoins?
Thanks.

NMC balances update every time an NMC block is found, which is about 3 times more frequently than Bitcoin.  However, it will only update if you are mining on the PPLNS system.  If you're set to PPS, you do not earn NMC.

At current network difficulties, you would expect to earn 6 NMC per 1 BTC (3x easier to mine NMC and NMC blocks are worth twice as much).  As of this post, every single NMC block found by the pool has been credited to PPLNS shifts.

[animan]

Ok thanks for the explanation. I was on PPS for the last couple of days. Moved back to PPLNS couple of shifts ago.
Hope to see the Namecoin balance start moving soon.

[xminerx]

The BTC to NMC conversion is currently 0.00476, so factoring in the three time higher frequency and double worth, that would mean the NMC adds roughly 2.9% to our BTC-rate. Sounds good!

I currently have 0.5 NMC. Now just have to find a way to transfer NMC to BTC. BTC-E seems to be the first thing that pops up if you look for such a thing. Any other recommendations?

/edit/ I see Eleuthria himself has recommended BTC-E as a wallet for NMC earlier in the thread! Good to know

Other question --> What's the minimum payout for NMC? 0.01 just as BTC?

/edit/ Ok, so I thought I could transfer my NMC to BTC-E, then convert it to BTC, then send it to my wallet. Turns out the withdrawal fee at BTC-E is 0.001 BTC?! I've only got 0.0025 BTC to send to my wallet! That would be 40%! "Luckily" the minimum amount of BTC to withdraw turns out to be 0.1 BTC... So only a 1% fee... But for me to get 0.1 BTC through NMC, would take quite some time... Seems like the NMC-bonus is mostly interesting for high MHash/s-miners. Too bad.

[os2sam]

Seems like the NMC-bonus is mostly interesting for high MHash/s-miners. Too bad.

Or long term miners.  I set my payout to 1NMC and set the address to graet's.  He can worry about the conversion .

[xminerx]

Seems like the NMC-bonus is mostly interesting for high MHash/s-miners. Too bad.

Or long term miners.  I set my payout to 1NMC and set the address to graet's.  He can worry about the conversion .

Maybe I sounded a bit too negative. Of course one should never look a gift horse in the mouth. But I was a bit disappointed about BTC-E, for my purposes at least. I can mine about 0.01 BTC per day. That would mean I'd make 0.06 NMC per day on the side. That equals to ~0.0003 BTC per day. But BTC-E asks a minimum of 0.1 BTC to witdraw, meaning I'd need nearly a year to be able to withdraw anything And of course, I'll keep making less and less BTC (and NMC) as difficulty increases, so I'll probably actually never reach that 0.1 BTC. Oh well

[gbx]

I'd been mining with Slush primarily for the past couple years.  Great pool and great guy!  It just got a little bumpy lately and I figured I owe it to myself to try another pool.

I do have a few questions.

1.  Is the 24 hour earnings a rolling 24 hour period or midnight to midnight?

2.  Thanks to your pool/worker stats, I did find some miner configuration errors I wouldn't have otherwise noticed.  I reduced my rejects by lowering my queue value in cgminer, but I still get quite a few dupe shares.  What's the cause and how can I reduce this?  On 3.2.2 cgminer.

3.  I noticed my PPLNS shift payments are going down.  Is this because the pool is finding blocks more frequently?  The overall hasrate of the pool hasn't changed significantly that I can see.

4.  Any plans to add google authenticator?  Hate hearing of the brute force attacks...

Thank you!  I like the pool!  Being a geek, I like all the stats you provide!

[eleuthria]

I'd been mining with Slush primarily for the past couple years.  Great pool and great guy!  It just got a little bumpy lately and I figured I owe it to myself to try another pool.

I do have a few questions.

1.  Is the 24 hour earnings a rolling 24 hour period or midnight to midnight?

2.  Thanks to your pool/worker stats, I did find some miner configuration errors I wouldn't have otherwise noticed.  I reduced my rejects by lowering my queue value in cgminer, but I still get quite a few dupe shares.  What's the cause and how can I reduce this?  On 3.2.2 cgminer.

3.  I noticed my PPLNS shift payments are going down.  Is this because the pool is finding blocks more frequently?  The overall hasrate of the pool hasn't changed significantly that I can see.

4.  Any plans to add google authenticator?  Hate hearing of the brute force attacks...

Thank you!  I like the pool!  Being a geek, I like all the stats you provide!

1)  24 hour earnings is an approximate value, and a rolling window.  For PPLNS earnings, it uses the most recent 24 hours worth of closed shifts (so it's not what you earned in the last 24 hours precisely, but what you earned in the last 32 hours, minus the most recent 8 approximately, since they aren't done getting paid yet).  PPS earnings are based on # of shares submitted in the last 24 hours to PPS, multiplied by the CURRENT PPS rate, which means it's a very accurate number except the 24 hours after a difficulty change.

2) I've heard a few people reporting dupe shares on cgminer lately.  I can say without a doubt that dupe share checking is not broken on the server.  The only way for a share to be marked as a duplicate is if you send the same Nonce, ExtraNonce, and nTime twice.

3) Right now we're in a small dry spell, but it fluctuates up/down a lot based on block solves.  When pool speed increases, you'll have fewer shares per shift, and smaller payments per shift, but more shifts will be completed in the same time frame.

4) It's something I'm considering, but there's a lot of other items being worked on right now.  As for brute force attacks, they're completely useless if you don't reuse your username/password from another site.  The brute force attacks on the pool are using a compiled database of dozens/hundreds of leaked databases.  Additionally, locking your wallet makes your account immune to a compromise.   If an attacker got into your account with a locked wallet, they can't obtain anything.

[puiutu]

My Namecoin balance hasn't moved for the last couple of hours, and my miner is on PPLNS, directed to eu-stratum.btcguild.com:3333.
Any tips?
Thanks.

[eleuthria]

My Namecoin balance hasn't moved for the last couple of hours, and my miner is on PPLNS, directed to eu-stratum.btcguild.com:3333.
Any tips?
Thanks.

Pool luck (nmc network luck in general) wasn't too good.  We had a 1 hour gap between NMC blocks, and then an ~45 minute gap before that.  However, the blocks are still all being assigned to PPLNS when they're found.

[eleuthria]

Graphing scripts were updated which did manage to reduce some of the load.  I'm not sure if there will be any additional changes until after new hardware is added to the colocation [nice new server with SSDs slated for the new database server].

[gbx]

Here is a screen shot of a duplicate share in progress.  Maybe the "work restart" request is causing it?  I don't recall seeing those while mining with slush.  Or a defect in the software??

[eleuthria]

Here is a screen shot of a duplicate share in progress.  Maybe the "work restart" request is causing it?  I don't recall seeing those while mining with slush.  Or a defect in the software??

Oddly enough...you can clearly see that's a duplicate share.  The same share (6edd8938) was responded to twice in the same second.

[gbx]

Here is a screen shot of a duplicate share in progress.  Maybe the "work restart" request is causing it?  I don't recall seeing those while mining with slush.  Or a defect in the software??

Oddly enough...you can clearly see that's a duplicate share.  The same share (6edd8938) was responded to twice in the same second.

Yeah, it certainly is.  I just don't know why it's trying to submit a duplicate.  As I say, I don't recall seeing (duplicate) marked shares with Slush's stratum setup and was just curious if you had any insight.  I have "no-stale-submit" on, so the work restart request isn't necessary for me.  I'm just wondering if it's confused about the work restart request and trying to resubmit.

I just set my queue to zero, I'll reset my stats and see if they go away.

[AvL42]

Here is a screen shot of a duplicate share in progress.  Maybe the "work restart" request is causing it?  I don't recall seeing those while mining with slush.  Or a defect in the software??

Oddly enough...you can clearly see that's a duplicate share.  The same share (6edd8938) was responded to twice in the same second.

Yeah, it certainly is.  I just don't know why it's trying to submit a duplicate.  As I say, I don't recall seeing (duplicate) marked shares with Slush's stratum setup and was just curious if you had any insight.  I have "no-stale-submit" on, so the work restart request isn't necessary for me.  I'm just wondering if it's confused about the work restart request and trying to resubmit.

I just set my queue to zero, I'll reset my stats and see if they go away.

For what its worth, I've started mining only a few weeks ago (mostly here), and never had
any "dupes"... until the last few days. I also think that the "stale"-Rejects have raised their
rate of occurrence as well.

Maybe some supposedly harmless change now triggers a bug in cgminer(*)?

Anyway, apart from that ugly "reject"-count, how bad are rejects, actually? Do they make me
appear like a "bad guy" who plays some cheap tricks, and/or do I get "punished" for rejected
shares, or can I safely ignore that for now, as long as the number of rejects stays far behind
the number of accepted ones?

PS: *: (cgminer version 3.2.1 on linux here)

[gbx]

Here is a screen shot of a duplicate share in progress.  Maybe the "work restart" request is causing it?  I don't recall seeing those while mining with slush.  Or a defect in the software??

Oddly enough...you can clearly see that's a duplicate share.  The same share (6edd8938) was responded to twice in the same second.

Yeah, it certainly is.  I just don't know why it's trying to submit a duplicate.  As I say, I don't recall seeing (duplicate) marked shares with Slush's stratum setup and was just curious if you had any insight.  I have "no-stale-submit" on, so the work restart request isn't necessary for me.  I'm just wondering if it's confused about the work restart request and trying to resubmit.

I just set my queue to zero, I'll reset my stats and see if they go away.

For what its worth, I've started mining only a few weeks ago (mostly here), and never had
any "dupes"... until the last few days. I also think that the "stale"-Rejects have raised their
rate of occurrence as well.

Maybe some supposedly harmless change now triggers a bug in cgminer(*)?

Anyway, apart from that ugly "reject"-count, how bad are rejects, actually? Do they make me
appear like a "bad guy" who plays some cheap tricks, and/or do I get "punished" for rejected
shares, or can I safely ignore that for now, as long as the number of rejects stays far behind
the number of accepted ones?

PS: *: (cgminer version 3.2.1 on linux here)

No, just possibly lowered efficiency, although I don't think cgminer resolved that share when resubmitting.  It just restarted what it was doing which was submitting a share..  based on the time stamp anyway.

[eleuthria]

I've pushed a small update which may fix the duplicate issue.  Try resetting your stats and seeing if they continue to show up.  There was a potential race condition in the namecoin thread which may have triggered work to be sent twice, each one with a work restart (and each one identical).  If your miner was lucky enough to find a share in that fraction of a second, it may have been a duplicate.

This doesn't mean that was the cause of any duplicates you may have seen, unfortunately it's very hard to know exactly what happened on your miner without full debug output.