Any Eligius fans (I'm one) have any thoughts about the Ghash.io share of hashrate atm? I know they have bumped against the 50% ceiling and backed down in the past, but this seems to be a recurring issue that will not go away.
It won't go away. GHash.io's private farm alone is larger than any other pool as is, and they continue to expand it. |
|
|
|
Ghas.io was closer to 51% than this, and they stopped accepting new miners to prevent 51% happening. And as saomeone else said before me, why would they destroy something that's making them shitload of money.
FYI: That never happened. At no point in GHash's history have they halted registrations to prevent a 51% hash rate. The only pool to ever do so was BTC Guild, and it did so at 45% of the network. And the difference there was 100% of BTC Guild's hash rate was public, no private mining farm. GHash.io continues to control a private mining farm of 40-50% of it's pool speed if not more, while trying to get more people to join their pool which has 0 economic sense behind it unless they plan on double spending or stealing from users (they're literally throwing money away to operate a public pool, spending time supporting people, and paying for servers, and gaining NOTHING from it). |
|
|
|
Will ghash.io take any action to prevent itself from reaching 51%?
not sure about this. seems nobody are aware of the growing hashpower of ghash.io. They're quite aware. The problem is Ghash.io will always be the dominant pool because their private farm is as fast or faster than any other pool out there *before* counting the public miners. The problem here is, GHash.io includes the largest concentration of privately owned mining power in the world, so there is no way that anybody can even attempt to challenge them, even if there was a massive public outcry. The largest pools have always gained a larger than proportional share of new mining power. |
|
|
|
Deepbit had controlling share in the network a couple of times and we survived. They won't do anything because it's in their best interest to play nice. Think about it a minute. They're holding a mass of btc profit from running a successful pool. They could continue making more money but instead they decide to make their holdings worthless by fucking with the network. Yeah, that makes sense. Calm down people, the sky isn't falling.
Their "mass of BTC profit" isn't from their pool. Their pool costs them money, it makes them nothing. It has, from day 1, made absolutely no economic sense for their pool to exist at all. Their private farm is as large or larger than any other pool as is, so the argument of letting others join them to reduce their variance is moot. They're too large for variance to make an impact on their monthly revenues. They're paying to run servers for people for nothing, unless they're skimming from the top. |
|
|
|
Also, from the website, doesn't mention the tcp thing at all.
CGMiner is one of the most advanced and full feature miners available. It runs in a command line, but allows configuration while running using the keyboard. After launching cgminer, you will be prompted with the following:
URL: stratum.btcguild.com:3333
Username: username_workername (example: MoreBloodWine_1)
Password: 123 (or leave blank, it does not matter)
-------
Miner Connection Details
Stratum Servers
Host (USA) stratum.btcguild.com:3333
Host (EU) eu-stratum.btcguild.com:3333
Username MoreBloodWine_1
Password (anything)
Because the website doesn't go into explaining how to setup config files, since most users that need to know how to connect a miner have no interest or understanding of how to do it. If you just type in stratum.btcguild.com/eu-stratum.btcguild.com:3333 into the prompt, it works fine. You only need stratum+tcp:// when working directly in the config file (and I'm not even positive if it's required there). |
|
|
|
Know this is off topic, but FYI:
Ordered a BFL Imperial Monarch (1TH/s version) on 03-04-2014.
BFL promised shipping by mid May (in writing).
Now 06-07-2014 no card in hand.
Asked for refund, turned down.
Hate getting stiffed for $3K.
Nothing changes with BFL. I'd say you'll be lucky to receive it this year. M And good luck getting it in the form factor promised. It'll change from a GPU design to a shuttle PC case by the time they're done adding a larger power supply and adequate cooling. |
|
|
|
I never gave much thought to it since it's always worked. but I was bored and started looking through the config file trying to figure something out and got side tracked by the URL for BTCGuild.
I mean why not use this which is what my backup URL's for stratum look like.
stratum+tcp://btcguild.com:3333
btcguild.com points to the web server. So that wouldn't work obviously. Or say even use this...
stratum.btcguild.com:3333
If you were entering the URL when prompted instead of a config file, stratum.btcguild.com:3333 works, but I think the config file requires the full stratum+tcp:// which identifies the protocol to connect with. The reason you have the "redundant" stratum (stratum+tcp:// and stratum.btcguild.com) is because stratum.btcguild.com is a subdomain which points to the pool servers, while stratum+tcp:// is used to let the miner know to connect with the stratum protocol over a persistent TCP connection. |
|
|
|
|
The stratum servers will be getting restarted in 30 minutes (12:30 PM, PST) in order to deploy a fix. bfgminer 4.1+ added TLS to Stratum as the default even though it was never a part of the protocol, and this ended up causing connections to hang for 1 minute+ when trying to connect to BTC Guild, and sometimes simply failing entirely.
The restart will only take a second to complete, but check your miners if they stop working, since historically there have always been certain miners which can't handle a disconnect properly.
EDIT/UPDATE: Restart completed, everything appears to be working as expected.
|
|
|
|
Anyone can explain why for few shifts there is no coins earned:
pool shares:172,445,552, your shares: 790,528, credit earned: 0
pool shares:170,300,544, your shares: 1,904,640, credit earned: 0
pool shares:167,301,920, your shares: 2,527,232, credit earned: 0
few shifts ealier, LTC coins earned was fine with value about 0.4 LTC per block.
If you're manually picking a coin: The warning is right at the top of the worker page: You're solo mining it unless the auto switcher joins you. Unless your (likely) small hash rate manages to hit a block for the coin you manually picked, you're unlikely to get any payment for that coin. If you're on the auto coin: If no LTC blocks are found, no LTC is earned. Pretty obvious. |
|
|
|
Luck isn't zero-sum. One pool being lucky has no impact on another pool being unlucky and vice-versa.
Sorry for being obtuse here but I expect others will have the same difficulty that I have understanding the above. You stated this a couple times and I could not think of a simple way to think about it so others might be confused too. 1. luck is not zero sum. I can understand this statement on its own and how it is true. But what I do not understand is "Luck is not zero sum EVEN when the average block solving time is 9 minutes (especially when I assume "luck" is calculated on a 10 minute block time)." How is it possible for the whole network to be having "bad luck" without the average block time going to 12 or 15 minutes? If there is some simple way to explain this, please try. And if Organ needs to answer this (to make me feel dumb as usual) can he please try to use words that average syllables? thanks in advance The average block time of 10 minutes assumes that the network speed is not increasing. However, this is not true, the network speed has been growing by 10 to 30% per adjustment for almost a year. So it is possible for the average block time to be under 10 minutes and luck to still be negative. However, over the course of a difficulty adjustment, the deviation from expectation/luck (for the entire network) is quite low, just a few percent in either direction. |
|
|
|
Any way to look to see which pool solved blocks in real time? I'm interested to see which pool is getting the good luck while we are in the bad.
Luck isn't zero-sum. One pool being lucky has no impact on another pool being unlucky and vice-versa. http://blockorigin.pfoe.be has the most accurate tracking of which pools solved which blocks, normally on a 5-10 block delay I believe. |
|
|
|
I'm curious what those losses would be under PPLNS. If I understand correctly the advantage of CPPSRB is less variance but under PPLNS if the pool were to hit a lucky streak, the miners get a proportional rise in payouts (putting you above what you would get even in a straight PPS system.) In CPPSRB if the pool hits a lucky streak the best the miners will get is 100% of their shares paid.
In PPLNS, if the pool hits an unlucky streak, you could have many shares that are never paid.* You put an asterisk with no explanation of it, so I'll add my own: This only happens if the PPLNS system uses an 'N' value that is low. At no time in the history of BTC Guild PPLNS has a share gone unpaid, because we have always kept the N value high enough to outpace even the unluckiest of blocks. However, the point is valid for most (every?) other PPLNS pool, especially GHash which uses a VERY low N-value compared to their pool size. |
|
|
|
|
Days would be possible...given an infinite amount of time/iterations. Realistically, unlikely. Right now we're at ~5.5x difficulty worth of shares. I'll be more worried if we go above something like Eligius had last week: 88,809,711,520 shares for one block. Little over 8x diff.
In other luck news, the graphs will be updated to 1-month again next week, now that we're almost at 1 month since the block withholding issue was discovered/corrected. 1-month luck has been steadily rising, and hopefully gets back into the 95-105% range in another day or so.
|
|
|
|
My CSC doesn't seem to be showing up at its destination at Cryptsy from ScryptGuild. I have not contacted Cryptsy yet but I know there was a fork on May 19th and some kind of wallet security update just a few days ago so I thought I would mention it here in case something needs to be done on the Guild side. Maybe its just me or it is a Cryptsy issue too so I will follow up there also.
Thx!
ScryptGuild is on the correct fork, though I do see Cryptsy failed to recognize our last few deposits as well. Sounds like an issue on their side. |
|
|
|
+1 How great would it be, to see a big spike, around 200% on pool luck graph, that would look like, hmmm... Himalayas?  Would look like the spike on May 23rd @ 196%. I was thinking the other day it would be nice if we could set performance notifications, like idle notifications. So If I have a 1000GH miner, I could set it to report if it falls below 920 for more than 30 minutes.
I had an S2 module turned off (100GH) for more than a week before I noticed it, due to the variation of other reported miner speeds.
You will have to make your own program to do this (its trivial with the API). The pool does not actually know your worker speeds, it only calculates them when requested (viewing dashboard/calling API). |
|
|
|
eleuthria, hi
could u tell what is ScriptGuild commission for BTC withdrowal. I have tried to find this info on site but no succes. Tnx in advance
There are no fees charged for withdrawals on any coin. Does it mean that pool makes transactions to miners' wallets with zero comission to BTC-net? The pool pays the transaction fees if they are required (which they normally are). |
|
|
|
eleuthria, hi
could u tell what is ScriptGuild commission for BTC withdrowal. I have tried to find this info on site but no succes. Tnx in advance
There are no fees charged for withdrawals on any coin. |
|
|
|
So I'm using BFGMiner 4.0 ( https://bitcointalk.org/index.php?topic=626361.0) and keep getting "Pool 0 is issuing work for an old block: ~Block#~". It looks like when we start mining LOT is when the error comes up. Here's a screenshot... Should we do away with LOT? They're only worth a satoshi each... The error message is incorrect because bfgminer is not designed to have any clue how a multicoin pools work. The pool is never issuing work for old blocks. |
|
|
|
12,301 TH/s the 11's just got crushed  So much for 12's....at 13186TH/s now! Quite a few pools are REALLY increasing their fire power ... the hash rate is growing right now! GHash.io having major issues apparently, so most of their public hash rate is failing over to other pools. Goes to show you just how much of their speed is their private farm, since we've only seen ~5 PH/s show up on other pools. So how many blocks for neutral luck now that we in a new difficulty
~8.75. |
|
|
|
Time to change the thread title to 11000TH?  I generally wait a few days before updating the thread title. It's not like it means much . True, but I thought it had been 11 for a while. I must admit I haven't been keeping up as I was without miners for a few days. Just got back online last night. We've been hitting 11 a lot, but our 24-hour average has only had 2 consecutive days above 11 PH/s. I keep the pool speed relatively current on the title, but I don't feel the need to rush to update it every PH/s . |
|
|
|
|
Show Posts
