The dashboard clearly shows when the last block was found, and you can make it show up in your personal time zone by changing it on the settings page.  BTC Guild hasn't found a block in 15 hours.

Every pool will close eventually.  BTC Guild almost closed 6 months ago.  When the time does come to actually close the pool, there will be 30+ days of warning before a single mining node stops, and many months of time before it finally goes offline.

That's the intention, not the letter of the law.  On a pool, your money is in the pool's wallet until you ask for it or your threshold is hit.  See the 2nd definition of what qualifies as a virtual currency business:  securing, storing, holding, or maintaining custody or control of Virtual Currency on behalf of others;

It is not possible to run a managed pool without a central wallet, with two exceptions:  Solo pools, and p2pool-style where there is a minimum difficulty that prevents a user from having a "dust" balance owed to them, and each share submitted requires a new work push (share-chain style) where any work submitted without the new coinbase reflecting the new distribution is considered stale/not paid.

BTC Guild isn't affected as you mentioned.  The BTC Guild stratum server was actually written before Stratum even existed when I was working on a different mining protocol solution to prepare for ASICs.  Stratum was close-enough to my protocol proposal that it took just a few hours to adapt it to match stratum syntax.

Quite alarmed that such a simple bug is in the "official" stratum branch, I'm pretty sure I remember this same type of exploit existing in the early days of getwork mining servers.

BitLicense is the start of over-regulation, not the end.  Other states will follow RAPIDLY after New York finalizes BitLicense, copying it almost verbatim most likely.  Given BitLicense is already trying to establish jurisdiction when you have a user located in New York, it would only be a matter of time before the pool would be forced into closure.  Legally, it's likely a defendable case, but the cost of defense would be high.  With the pool's income is shrinking every single month as the price gets lower and private farms/China continues to take a larger chunk of the network for itself, it's not a legal cost I would be willing to endure.

Yes, I'm sure there would never be such a drastic split.  Was just using an extreme example.  The main point was that it doesn't matter what miners do (unless the hard fork is implemented in a way that requires a mining consensus to take effect).  It's  also extremely unlikely that miners wouldn't follow the money.  Miners will go wherever they get paid, and that is decided by the businesses and exchanges that accept Bitcoin.

A common misunderstanding:  Miners actually have zero influence over hardforking.  If a hard fork is going to happen, it doesn't matter if 99% of miners decide not to follow it.  If all of the major Bitcoin businesses, payment processors, and exchanges move to Bitcoin (New) and the miners all stay on Bitcoin (Old), it doesn't matter, forks do NOT require mining consensus unless the fork requires one, such as the "Block Version 1" -> "Block Version 2" fork, where the network switched to enforcing version 2 blocks after 95% of the last 1000(?) blocks were V2.


Guess which one is going to retain any value?  Especially post-fork when the miners realize they can't exchange their BTC for goods or cash because no exchanges will accept BTC-A coins.

I believe we absolutely need to remove the 1MB block limit.  I'm not opposed to the jump from 1MB to 20MB, as I think it will have very minimal impact what the new limit is for quite some time.  I'm not sure if this jump to 20MB also implements the original proposal for automatically increasing the limit annually.  I do have objections to that one as I think Gavin's original proposed annual increase was FAR too aggressive and optimistic regarding throughput and bandwidth quotas for huge portions of the world.

What I think probably won't matter much though.  With a March 2016 prospective date, I'm not so sure the pool will even still be around by the time it's time to choose a side, given how much noise is being made by regulatory bodies who have absolutely no clue what to do with Bitcoin but sure as hell want to regulate it anyways.

Wouldn't use ghash as an example of a bigger pool these days.  They've shrunk significantly (smaller than Guild and Slush).  These days the only "big" pools are Chinese.  Everybody else is 5% or less of the network.

Block payments are based off contribution average over 10 shifts, which is something like 18-20 hours depending on pool speed.  If you drop out for an hour, your share of blocks will be decreased by roughly 5% of your normal contribution (1 hour missing out of the 20 hour evaluation window) until the shift with an hour missing is no longer part of the last 10 shifts.

PPLNS basically distributes the effect of your mining activity.  Instead of getting paid nothing while your miner was offline, you get paid slightly less averaged out over the shifts.

You're saying this while the 3-day average is at 110% (and was at 130% 2-days ago during that massive spike of luck).

Will also point out that any time somebody is claiming multiple days at less than half:  You need to redo your math.  That hasn't happened.  In the last 3 months there has not been 2 consecutive days under 50%.  Hell, there's only been 2 or 3 24-hour periods (if you cherry pick a start and end time) at under 50%.

Good luck with your future endeavors kinlo.

Nope.

One of the private servers had an outage earlier.  There was an error in the configuration when updating it, and instead of failing so I knew immediately it was there, it created a silent failure/process hang that didn't alert me until my monitoring script noticed it wasn't getting a new response after a block change.

The problem has been corrected.

Everything is patched up and running again.  Migrating the web server is such a pain when everything important that it talks to is locked down by IP.  I have to do a strange ritual dance just to remember the right combination of servers to connect through to actually let myself in.

Will be fixing the "invalid address entered" message shortly.  The web server is being shifted to a different machine and this error is popping up because the migration isn't 100% complete yet.

Have still not seen anything from you.  If you're sending from your own domain, check your SPF/DKIP records, because they don't even arrive in a spam folder meaning you're getting hard blocked due to bad mail server/dkip/spf settings.

Try resending it.  I normally answer support emails in under 24 hours.  Make sure the subject isn't a reply to a confirmation email, I automatically delete those.  I also ignore emails with vague subject lines because I get too many idiots sending me junk to the support address.

My recommendation for auto withdrawals has generally been that if you are mining > 0.1 BTC per 24 hours, you should probably set your minimum withdrawals to your expected 24-hour amount.  It's a little trickier these days since the pool is so much smaller as a percent of the network, so one day of mining can swing quite a bit.  At worst, I recommend setting the automatic withdrawal to 1 week's expected generation,  just to avoid the pool being responsible for your coins.


Obviously it depends on how much BTC you're planning to send in the long run, and how frequently.  General rule of thumb used to be 0.10 BTC could be spent after 10 days of confirmations without a fee (10 Days * 0.1 Bitcoin = 1 Bitcoin Day).  Now if you are combining multiple inputs (sending > 0.1), it gets a little trickier (read the wiki on transaction fees/priority).

Should be clear for reconnecting and reconfiguring workers now.  Was doing some work on the frontend servers which meant restarting a miner (or swapping pools on one) may have encountered problems getting on again.

Having infected zombies participate in a DDoS is how they are most commonly detected and eventually fixed.  Reporting huge amounts of IPs to ISPs, while most are ignored, will cause some infected users to get contacted regarding the fact that their computer is participating in illegal activities.

They're much more valuable when undetected and stealing user information (passwords, credit card numbers, etc.).  So while executing a DDoS with your own swarm of infected machines might not actively cost money (though many DDoSes are actually somebody paying for another perosn's botnet to attack), it will lose them machines that could be generating money in ways which don't get detected as quickly.