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

[TechByPC]

Does anyone know if BTCGuild and Scryptguild is affected by the OpenSSL vulnerability?

That's only a problem if the Bitcond is using SSL/TLS right?  We are not mining against BTC Guilds Bitcoind via SSL/TLS so it shouldn't be an issue, as far as I know?!?

Right. The fix for bitcoind would harden them from an internal attacker, but they'd already be compromised at that point.

Now the SSL on the website is a different story, but that's also trivial to fix, and logging there would likely show some patterns of attack.

This whole thing is serious, but there are also people looking to make some cash on the fear mongering.

[1714027506]

1714027506

[eleuthria]

Does anyone know if BTCGuild and Scryptguild is affected by the OpenSSL vulnerability?

Pool mining and the bitcoind's were not affected since they do not use SSL.  The website was not affected because it is served via Cloudflare, which patched this vulnerability a week before it was announced (they were one of the companies which were notified before it was disclosed publicly).

[os2sam]

and logging there would likely show some patterns of attack.

That's the problem with this SSL/TLS vulnerability, there would be no logging, as it can't be detected when the exposed data is captured.

Glad to hear BTC Guild is on top of it, as usual.

[TechByPC]

and logging there would likely show some patterns of attack.

That's the problem with this SSL/TLS vulnerability, there would be no logging, as it can't be detected when the exposed data is captured.

Glad to hear BTC Guild is on top of it, as usual.

What I meant was that there would be logs on the server indicating https traffic. In the case of bitcoind rpc traffic there is not. You wouldn't have direct evidence that https was compromised but you would have more than with bitcoind.

[hurricandave]

   Why does it seem like the length of time for each shift to be completed has begun to vary from shift to shift and has become less consistent for the last 24 hours ? I seem to remember something about the shift ends when a certain amount of work is submitted but lately the amount of time involved has had more variance than usual. At least that's my twisted perception.

[hurricandave]

oh, and the pool speed is above 8,000 TH/s already with average shift time at 52 minutes and falling.

[eleuthria]

  Why does it seem like the length of time for each shift to be completed has begun to vary from shift to shift and has become less consistent for the last 24 hours ? I seem to remember something about the shift ends when a certain amount of work is submitted but lately the amount of time involved has had more variance than usual. At least that's my twisted perception.

Shifts are based on # of shares submitted, not a length of time.  So it will always fluctuate (and always has).  The number of shares per shift is also routinely increased as pool speed increases, to keep the length of shifts in the 50-60 minute range while maintaining an 'N value' of at least 10x the current difficulty.  It was actually increased recently (from 5.5b to 6b) due to the rise from 6000-6500 TH/s to 7100-7200.  But there seems to have been a huge spike the hash rate in the last few hours.  If the hash rate remains high the shares per shift will be increased again.

The time a shift lasts is irrelevant.  The expected block solves per shift is entirely based on the # of shares per shift, which is why BTC Guild uses a Share Count instead of a Time Frame for closing shifts, in order to keep the expected block solves per shift high (which reduces per-shift variance).

[hurricandave]

   I'm not increasing/decreasing my worker speed but the difference in shares submitted per shift by my worker is decreasing in a significant way when you compare how many I submit in 58 minute shift to a 52 minutes shift. I would say the difference is a little more than 1000 shares per shift with 15.3 Gh/s combined device speed. But the pool has so far had a consistency in shift length that varies over days time not the current hour by hour that is happening right now. The 50 minute mark is what I was unsure of as the minimum target thanks for reposting that.
   I believe we are starting to see a significant number of batch 1 Antminer S2's and the beginning of batch 2 deliveries beginning to come online. I think it will be difficult to keep up with adjusting the shift size if these miners keep jumping pools looking for the "Lucky" at the moment most profitable pool, and the impact of increasing/decreasing shift time variance on a per shift level that has an over all affect of +-7 minutes from just a handful of workers.

[eleuthria]

  I'm not increasing/decreasing my worker speed but the difference in shares submitted per shift by my worker is decreasing in a significant way when you compare how many I submit in 58 minute shift to a 52 minutes shift. I would say the difference is a little more than 1000 shares per shift with 15.3 Gh/s combined device speed. But the pool has so far had a consistency in shift length that varies over days time not the current hour by hour that is happening right now. The 50 minute mark is what I was unsure of as the minimum target thanks for reposting that.
   I believe we are starting to see a significant number of batch 1 Antminer S2's and the beginning of batch 2 deliveries beginning to come online. I think it will be difficult to keep up with adjusting the shift size if these miners keep jumping pools looking for the "Lucky" at the moment most profitable pool, and the impact of increasing/decreasing shift time variance on a per shift level that has an over all affect of +-7 minutes from just a handful of workers.

Again...you are NOT affected by shifts getting shorter.  Your shares per shift goes down.  That means *nothing* because you are completing more shifts in the same time frame.  The expected blocks per shift is the same whether the shifts complete in 5 minutes or 5 hours (as long as they're based on share count).  The per shift variance is the same in BOTH cases.

This would be the same as complaining that a pool grew too much and now it finds blocks too fast.  Yes, you get a lower reward per block (in this case, per shift).  But you complete more blocks (shifts) in a larger time frame (24 hours for example), and the net effect is less variance overall with the same expected reward.

[hurricandave]

   Well, I'm not trying to argue but changes in pool behavior are sometimes what it takes to relearn what I've got wrong and possibly get it right.

[w5pn73]

Shifts are based on # of shares submitted, not a length of time.  So it will always fluctuate (and always has).  The number of shares per shift is also routinely increased as pool speed increases, to keep the length of shifts in the 50-60 minute range while maintaining an 'N value' of at least 10x the current difficulty.  It was actually increased recently (from 5.5b to 6b) due to the rise from 6000-6500 TH/s to 7100-7200.  But there seems to have been a huge spike the hash rate in the last few hours.  If the hash rate remains high the shares per shift will be increased again.

I was wondering, the ScryptGuild counterpart has fixed time shifts, is there a reason why the BTC side has fixed number of shares ? In other words, wouldn't it be an advantage to have fixed time shifts in BTC Guild too ? At least it should be transparent to hash rate variations.

[Taugeran]

Sooooooo.... We just gained 1.5 Petahash over night. While I'd love to say it was me, sadly it is not

[casinocoin]

Sooooooo.... We just gained 1.5 Petahash over night. While I'd love to say it was me, sadly it is not

Noticed that as well, jesus...
Could be all the s2's are now shipped and running but doubt that.
Haven't seen this team before.. Arendelle

[eleuthria]

Shifts are based on # of shares submitted, not a length of time.  So it will always fluctuate (and always has).  The number of shares per shift is also routinely increased as pool speed increases, to keep the length of shifts in the 50-60 minute range while maintaining an 'N value' of at least 10x the current difficulty.  It was actually increased recently (from 5.5b to 6b) due to the rise from 6000-6500 TH/s to 7100-7200.  But there seems to have been a huge spike the hash rate in the last few hours.  If the hash rate remains high the shares per shift will be increased again.

I was wondering, the ScryptGuild counterpart has fixed time shifts, is there a reason why the BTC side has fixed number of shares ? In other words, wouldn't it be an advantage to have fixed time shifts in BTC Guild too ? At least it should be transparent to hash rate variations.

The reason ScryptGuild is fixed time and BTC Guild is share count based is due to variance and also time delay effects on a pool that is essentially a hopper in itself (ScryptGuild).

The biggest complaint against traditional PPLNS systems is that if the pool has very bad luck, your work can go *completely* unpaid.  BTC Guild uses the highest 'N value' of any PPLNS pool, generally 10-15x the current network difficulty (and when we were a huge part of the network it was ~20x network difficulty).  This extremely high N value means that an individual share is more likely to get it's expected value by the time it is moved out of the open shifts.

Obviously, very bad luck will strike at times, and similarly a huge spike in blocks can also happen.  But with a huge N value, it *generally* falls close to neutral.  Even with BTC Guild's bad luck the last month, your average *per share* variation was almost always +/- 25% of neutral.  In a round based system, your per share variation will generally be much further from neutral (in the end it still averages out of course) on a per share basis.  With the PPLNS on BitMinter and GHash.io, it is possible, and does happen, for a share to go completely unpaid because no block is found before it's shift is closed.  Again, in the long run they all average out, but it's nice to not have a period of mining go *completely* unpaid if the pool finds no blocks.


So BTC Guild is focused on variance, and it's manually adjusted via share count to keep it in the sweet spot of maturation time (time before a share gets completely paid) and share variance.  ScryptGuild on the other hand isn't really capable of focusing on share variance due to the nature of multicoin hopping, so it uses a consistent shift time in order to keep maturation of shares relatively short (5 hours).

[ivankoh]

Sooooooo.... We just gained 1.5 Petahash over night. While I'd love to say it was me, sadly it is not

Noticed that as well, jesus...
Could be all the s2's are now shipped and running but doubt that.
Haven't seen this team before.. Arendelle

I belive many ppl from eligius switch over due to the pool problem. if you see their hashrate drop alot

[Taugeran]

Must. Join. Arendelle

[navigator]

I've been trying other pools and keep coming back to btcguild. Eligius just doesnt have all the stats I want. I gave ghash a try over the last 48hrs or so. On my chart page at ghash the lines showing hashrate are labeled 208.78 and the line below it is 178.89, who makes a chart like that? I can't tell if my antminers are close to 200gh or not. Bad chart labeling. I also can't see the shares produced by each miner. There is no top users list, which I used to gauge how fast the big guys are growing. I also didn't know cex.io and ghash were the same thing til I went to sign up. When browsing the ghash.io site, if I want to goto my balance page I have to sign into cex.io too. And it ask to setup 2fa everytime I login. I don't want or need 2fa on my mining account. It begs for your phone number also. I always setup my mining to give a daily payout so if anything ever happens, I'm only out a day mining at most. I set my difficulty to 128 at ghash, but noticed today my miners are saying 256. I prefer 128 for my antminers. I tried to point my miners to their US server, but most of them are connecting to the UK one. Without doing a bunch of manual calculating, I can't tell how much I've made in the last 24hrs are ghash. At btcguild, the last share time comes in handy sometimes when messing with miners. Overall, btcguild displays the stats I need + want and make it easy to understand what my miners are doing.

I pointed everything back to btcguild. My main pool since 2011

[crilleaz]

This is still the best pool out there.
Been on and off for two years now, will never leave BTCGuild.

[eleuthria]

I belive many ppl from eligius switch over due to the pool problem. if you see their hashrate drop alot

Yes, quite a few Eligius users have BTC Guild for their failover.  I know they've been under attack a lot recently, though for the last few weeks it hasn't affected the mining pool itself.  Not quite sure exactly where this 1-1.3 PH/s came from other than a huge growth from Team "Arendelle".

[Taugeran]

ok ive racked my brains both in searching for my answer and trying to recreate it just from memory.  

in the recent past i came across a thread where someone had used JustGage.js(based on Raphael.js) on jsfiddle.net to create a speedometer style graph of your hashrate, given your accounts api_key.

i cannot for the life of me find the post. the fiddle in my web history(going back over 2 years, well before i started bitcoining) or use jquery on jsfiddle to retrieve my api stats into a json object i can traverse for the stats i desire.

help me... maybeh?

also i think there should be an available link somewhere on the site for https://www.btcguild.com/new_protocol.php

only way i found it was thanks to the ckolivas