BTC Guild questions should be posted in the BTC Guild thread....which has a bunch of posts about the outage.

Unfortunately no...not that I have any objections to just locking this and making a new one.  Which may happen.

Yes, immediately after posting it was back up it went down again.  I'm looking for the cause.  Mining is back up again at the moment.

I'd always recommend checking your miners after a confirmed service outage, just because not all software functions perfectly when dealing with unexpected disconnects.

Pool service restored, database server had stopped responding.  Looking into logs now to find the cause so it won't repeat itself.

Orphaned blocks will show up under the Pool Stats listing of our last 200 blocks, as "Orphan" for their block #.  They will not appear on your dashboard or on the PPLNS Stats pages at any time (they only show up on those pages after the block has another block confirming it, AKA:  Not orphan).

Hi organofcorti,
  Please update BTC Guild PPLNS to 2%, and "No" on paid orphans.  Also remove the BTC Guild PPS .

  Thanks.

Thanks for the reminder.

Sure it is.  I'm sure it's a coincidence that you're the one who posted a thread about it, and have a number with no backing, at all.  You are not going to outperform every other multipool by 30-50%.  It's not possible.  No amount of "profit switching algorithm" bullshit will make that true.  Which coin is most profitable is a very clear calculation.

Do you have automatic conversion enabled?  EAC, DOGE, and DGC are all being converted hourly as usual.  If you don't have enough of them to equal 0.00001000 BTC it only converts once per day in order to avoid excessive rounding when it comes to fees.

Here's how it works:

1) Block is found by BTC Guild.
2) Within a minute, the frontend recognizes the block and it's listed under Pool Stats.  This process also identifies which 10 shifts will get paid for the block.
3) Once the block has a confirmation, the block is credited to the appropriate shifts.



So BTC Guild is still offering the near-instant rewards, you don't have to wait for the block to hit 100-120 confirmations.  It just waits for another block to confirm its own block before applying the reward to accounts.  To date BTC Guild has never had a block get orphaned after another block built off it (it's extremely rare to have a blockchain re-org beyond a single forked block).

EDIT: Obvious exception for the 0.8 hardfork orphans with regard to BTC Guild not having a block orphaned after another block confirmed it.

The pool is in the United States.  If I'm given a warrant, I must comply.  If I'm given a subpoena asking for specific information, I will comply.  If what I'm provided with appears to be nothing more than fishing, I will request clarification/specifics before taking any action, but if legally required to do so, the information will be provided.

Not that any of this makes much difference, since the only miner information I can provide is what users provide to me, which is extremely limited.  If I'm asked what John Doe mined on BTC Guild, I cannot answer unless other information is given to identify which user was John Doe.

Fee Update (3/31/14)

A modification to the pool fee has been applied effective as of any block found after #293429.  Going forward, the pool fee has been reduced from 3% to 2%.  This is to offset the removal of paid orphan blocks.  BTC Guild's historical orphan rate is slightly under 1%, so this doesn't have much effect on the effective fee of the pool.  This is being done for 2 reasons:

1) To make the pool fee comparable at a glance to other pools [I'm tired of pointing out that BTC Guild is an effectively lower fee due to paid orphans]
2) To complete the pool transition to where miners are paid only what they have mined, minus the pool service fee.


#2 is an extension of the removal of PPS, a part of that decision was related to the recent IRS tax ruling.  As pointed out earlier, BTC Guild's stance is that we are a service provider to miners.  We allow miners to work together to pool their resources, and for a fee, we make sure those miners are given their fair share of what they have contributed to.  In the spirit of that official stance, paying for orphaned blocks was something which didn't quite fit.  While my tax and legal counsel did not believe these actions were required, they do agree that these actions would help strengthen our position if it was ever brought into question.

Because when the pool mines LTC everybody bitches non stop because we might go 6 hours without a single LTC block.  The pool penalizes coins where the difficulty is much higher than pool speed, which is the case with LTC.

Your reject rate should not be higher if you have it set higher.  Your rejects will hurt more, but you will have proportionally less of them in the long run.  The pool sends you work once.  That work is the same whether you're diff1 or diff65536.  All difficulty means is you won't bother submitting results that aren't high enough to match d ifficulty.

Could be true for some multipools, but making a blanket statement like that makes you look like a dumbass.  You have no proof this takes place on any pool, let alone ALL.  In the case of ScryptGuild the stats are clearly there, the miners see what coins they mined and can either let the pool convert it or do the trading themselves.

Those shouldn't impact mining at all.  Ignore them.

It's more likely due to Eligius growing as a % of the network compared to mid-2013 and prior.  Measuring luckiest blocks in terms of time since the previous block would be affected by that.  A better way to measure the luckiest block would be the best shares vs difficulty ratio.

Automatic Payout Batch #32804 failed to send yesterday.  The payout has been removed from the payment history for any users included in that batch and it will resend shortly.



Doubtful.  The IP may be an Azure server that has an extremely good connection to the network + blockchain.info, meaning they are the first source of some blocks that blockchain.info sees.  The relay IP blockchain.info shows is not the SOURCE of a block, its the first node that informed them about a block.

The emails were sent.  They weren't bounced.  Check your spam box or try changing the wallets to a different address for a new email to get sent.  They get pushed to the mail server before the page even reloads stating that a confirmation was sent.  Within seconds they're then actually sent by the mail server.  Every single email sent to your address was successfully delivered without a bounceback/blocked message.