Automatic Payouts (> 0.10 BTC) have been re-enabled. Smaller auto payouts (0.01-0.09) and manual will be enabled within the hour.
UPDATE: All payouts are now functioning normally. Sorry for the extended maintenance, but sometimes you're stuck at the mercy of transaction confirmations! Some more work is planned later this week to bundle smaller manual payouts to increase overall confirmation time for all users on the pool.
Didn't i see that you were getting rid of PPS? you need to fix your Sig.  Not getting rid of it yet, but it's certainly a consideration. I do need to swap the order though, since PPLNS is now the default (and only method if you're not on stratum). |
|
|
|
|
Automatic Payouts (> 0.10 BTC) have been re-enabled. Smaller auto payouts (0.01-0.09) and manual will be enabled within the hour.
UPDATE: All payouts are now functioning normally. Sorry for the extended maintenance, but sometimes you're stuck at the mercy of transaction confirmations! Some more work is planned later this week to bundle smaller manual payouts to increase overall confirmation time for all users on the pool.
|
|
|
|
|
Updated estimate to 22:00 for auto payouts. Sorry for the delays, looks like the transactions were backlogged due to a payout that didn't have a confirmation yet, so the future transactions can't confirm until that one does. I've manually rebroadcasted about 15 minutes ago.
In the meantime, additional work was done pruning the database of users that had created accounts but never mined a single share. User accounts which were registered over 1 month ago which have never mined a share, and have not been logged into since their creation, are currently being deleted. These accounts have been backed up and can be restored later (or simply recreated).
|
|
|
|
|
Hot wallet maintenance is still in progress. It may still finish by 21:00 UTC, but not having much luck getting the transactions to get confirmations even with appropriate fees. Not many blocks on the network since the transactions were initially sent to clear out the old wallet.
Will post an update when it's closer to 21:00 with any time extensions needed.
UPDATE: Automatic payouts should be re-enabled by 22:00. Manual payouts will likely be disabled for an additional hour to give funds a chance to gain confirmations before they begin to churn from manual payouts.
|
|
|
|
So do you think that almost 50% drop for good few days in a row is normal? I know that luck is important, our hashing power is not increasing compare to other pools and we get smaller chunk of the pie, and difficulty is increasing but would that factor for such a difference? I was expecting drop in reward but not so quick and so much.
Measuring just a few days of earnings is not enough data to make any reasonable conclusions, especially at these difficulty levels and slush's pool speed. "Luck" takes a significantly longer amount of time to "even out" than what most people think it does. |
|
|
|
Do you have a longer history of PPLNS average rate than the last 100 shifts? Or any charts?
It looks like PPLNS is 8-10% less than PPS. If I'm not mistake, that's after all the fees are taken out... Been that way for a couple of days.
PPLNS has been paying less than PPS for the last 3 weeks roughly (with a few days being exceptions). In general, you will spend more *time* influenced by bad luck, but periods of good luck should make up for it. Over the last 18 months since BTC Guild has been PPS (and 2 years as a pool), the pool luck is extremely close to neutral (less than 1% off, and that is influenced by orphans and software issues in the early days more than anything). Extending the PPLNS average rate is a bit hard to do in a way that provides any meaning since different difficulties would mean different expectations for payouts. It's already a bad number to use for comparison for a few days after difficulties change. Fair enough. The only time that they are inaccurate is when the difficulty changes, correct? Or am I understanding what the difficulties would be? You've got great miner charts on there. I think what I would love to see on a chart, would be the rolling 100 shift rate on a chart throughout history. Of course at a difficulty change it would drop by whatever percentage the difficulty would be up. When looking day after day and seeing PPS kicks your but, it would be nice to see those short spikes in a chart somewhere making up for loneliness of PPS  And as usual, Murphy's law strikes  . Look at the PPLNS Shift Stats right now. A few shifts which pay enough above PPS to make up for a few bad shifts each, and still more time for them to go even higher. |
|
|
|
|
The website is currently having another attempt at major brute forcing on the login page. I've re-activated the cloudflare "I'm under attack" mode. This will likely cause issues with monitors which rely on the API since the monitors will not interact with the cloudflare intermediate page properly.
I'm working on updating the API to be served from a separate subdomain which is not subject to the same "I'm under attack" settings.
|
|
|
|
Do you have a longer history of PPLNS average rate than the last 100 shifts? Or any charts?
It looks like PPLNS is 8-10% less than PPS. If I'm not mistake, that's after all the fees are taken out... Been that way for a couple of days.
PPLNS has been paying less than PPS for the last 3 weeks roughly (with a few days being exceptions). In general, you will spend more *time* influenced by bad luck, but periods of good luck should make up for it. Over the last 18 months since BTC Guild has been PPS (and 2 years as a pool), the pool luck is extremely close to neutral (less than 1% off, and that is influenced by orphans and software issues in the early days more than anything). Extending the PPLNS average rate is a bit hard to do in a way that provides any meaning since different difficulties would mean different expectations for payouts. It's already a bad number to use for comparison for a few days after difficulties change. |
|
|
|
|
The pool hot wallet will be going through maintenance tomorrow at 12:00 (noon) PST/19:00 UTC. This maintenance should only last about two hours, during which time payouts will not be available. Mining will continue uninterrupted, and automatic payouts will run two "catch-up" runs after it is complete. Maintenance will mostly be based on waiting for the hot wallet transactions to receive a few confirmations, so it may be as short as 30 minutes, or as long as 4 hours depending on overall network luck and transaction confirmation time.
|
|
|
|
Not sure if I need Slush's permission to call the API but I have limited the refresh to 10 seconds minimum for now.
As a pool operator, I would recommend making the auto refresh interval measured in minutes, with 1 being the minimum. Most people will run this in the background and rarely look at it, so having constantly up to date information is just adding load to the web server+database without much benefit. It's one of the reason most pools removed/never added live refreshes on their websites: Most people will just leave a tab open and forget about it. |
|
|
|
|
New server in the EU has been provisioned and is in the process of being setup. I will update this post (or make a new post if somebody replies first) when the DNS is updated to point to the new EU Stratum server, which should be in a few hours.
UPDATE: EU-Stratum is now back in Europe and DNS has been updated. Users will be redirected to the server the next time they try to connect to eu-stratum.btcguild.com (NOTE: DNS caching may cause you to connect to US servers for up to 24 hours even though the DNS should be cached for 5 minutes).
|
|
|
|
|
EU-Stratum was down again this morning, roughly the same time as yesterday. I have temporarily moved EU-Stratum DNS to the north american servers while waiting for a new server to be provisioned in the EU with a different hosting company. Sorry for the inconvenience, and hopefully service will be moved back to the EU within the next 24-48 hours.
Estimated downtime of EU-Stratum was once again about 7-10 minutes [I get the warning that the server is dead after 5 minutes of downtime].
|
|
|
|
He moved that capacity over from asicminer on BTC guild to help them being under 50% of network. Who is this who mines more than 25% of the entire BTC hash rate? Why does he have so many ASICs and nobody else can get?
ASICMINER was a publicly funded company. They developed their own ASIC hardware, and the people who invested in them at the start have already made their money back many times over with the dividends. That's why they have so many ASICs: They designed them. They are now auctioning off hardware in batches as well so that they won't reach 50% as a single entity. Oddly enough, they had no plans to sell hardware originally, and so far they're the best company to buy from because you'll actually get your product in a reasonable timeframe. |
|
|
|
|
Merged mining is already available with Stratum. Some pool operators (myself included) simply decided to stop wasting time with Namecoin, a project which has no active development and is only being kept alive by people trying to screw each other on the exchanges.
|
|
|
|
|
Restart happening right now on EU-Stratum. Server completely stopped responding. Do not believe it's an attack at this time, but should know shortly.
UPDATE: EU-Stratum restored. Downtime is estimated to have been about 9 minutes in total.
|
|
|
|
FTFY? Do you understand PPLNS at all? You get paid for each share based on blocks solved after it's submitted. The value of the share has NOTHING to do with timing/consistency of share submissions. It is entirely based on how many blocks the pool solves after the share is submitted. There is no exponential/DGM scoring involved that makes shares worth less when you stop or when you start.
Reading comprehension is your friend. PPLNS (while better than DGM) still punishes inconsistent miners on long rounds. It only counts the last N shares. You can claim it isn't related to timing or consistency of submitted shares... but anyone who understands how the payout method works knows you're incorrect. The saving grace on PPLNS is on short rounds you effectively get paid the same as an average round... But how often does a pool have multiple short block finds in a row? Your terminology is flawed. Punish implies the method actively discriminates/penalizes the miner. You're simply giving an example where a miner submits shares during bad luck then isn't mining during good luck. That's variance, and is present under EVERY system except for PPS. They could have the exact opposite, and only mine during good luck. That's not rewarding them for inconsistency, that's just being on the positive side of variance. PPLNS with bad settings could make it so they get -no- payment during bad luck, which could be considered punishing. With proper settings, they will get some payment. BTC Guild's setting for 'N' is ~25x difficulty. There will never be a time where a share is not paid something. The higher the N value, the less variance for inconsistent miners. |
|
|
|
|
organofcorti, possibly easy question, or possibly extremely difficult to answer: Due to the random nature of block solves, is it accurate to say that on average, a pool will spend more time with negative "luck" than with positive "luck"? I want to say that's the case, and it's why miners are always pointing out how <X> pool has consistent bad luck.
In my eyes: Bad luck is DEFINED as a long period with fewer blocks than expected, while good luck is defined as a lot of blocks in a shorter period. So you would expect that a pool would probably spend most it's time negative when viewed on a graph with time as the X-axis. However, the good luck bursts only need to last a fraction of that time to "make up" for the bad times. When viewed on a graph, that would paint the picture of consistent bad luck, but when evaluated over a long enough period, you would find it gets very close to the expected average.
I'd love some confirmation/observations from you on the matter [maybe split to another thread, but it does fit in with this BitMinter thread as well, so it's your choice].
|
|
|
|
|
Website is a bit slow right now (started about 10 minutes ago) due to someone doing a brute force attempt on the BTC Guild login page. I've killed the brute force from actually getting any information out of the server, but they are still hitting the website pretty hard from many locations (or faking their source and cloudflare isn't catching it), which is causing the website to have a bit of lag. Mining pools are doing fine at the moment.
Just a standard security notice: Do not use the same password on BTC Guild as you do on other sites. This brute force attack is using a list of what appears to be specific usernames/password combinations, which indicates they're using a leaked database from somewhere. They don't come even close to matching BTC Guild usernames in most cases, so it's definitely a blind attack, but may be sourced from another Bitcoin site that was compromised at any point in the last few years.
UPDATE: The website slowdown has been fixed with some temporary adjustments to Cloudflare's security settings. Unfortunately this is currently causing problems with the API for some users. I have a support request in with Cloudflare to discuss options on how to keep the API page functioning with the current security settings.
|
|
|
|
|
Show Posts
