Working just fine for me (just restarted my miners pointing them at EU, instantly connected).

They should remain available once added.  The fee will only be for SMALL payouts (< 0.01).  0.01 and higher will still be available at no cost to the miners.




Looks like the EU validation/ddos filtering server was getting slammed pretty hard by a botnet, giving it a reboot to see if it clears up any issues.

I refuse to tamper with transaction selection settings in bitcoind.  I only use the bitcoind arguments available (minsize, maxsize, prioritysize, mintxfee).  I also do not plan on *encouraging* tiny payouts, which is why the fee will be 0.0005, even though they will still be in a sendtomany along with other larger transactions.  It's creating a cost-benefit to adding extra clutter to the blockchain.  You can get your tiny payouts if you really want them, but not for free.

This weekend Manual Payouts will be extended to amounts smaller than 0.01.  However, any withdrawal under 0.01 will have to pay the 0.0005 transaction fee.  This will only be available for *manual* withdrawals.  Automatic payouts will remain at 0.01 intervals.

I'm not a fan of trying to increase the frequency of micropayments, but at today's rates 0.01 is ~$4, and I can see a user for being able to withdraw $1-3 (at the cost of a few pennies).

BTC Guild is ~28% of the network speed.  So you'd expect a block *roughly* every 25-30 minutes right now.  If you want an example of how bad luck can get, just look at the network as a whole.  We have (normally multiple times per difficulty) periods where THE ENTIRE NETWORK doesn't get a block for an hour, even though it was averaging one every 8 or 9 minutes that difficulty.  If the entire network is having a period of 1 hour without blocks on a semi-regular basis (more than once per difficulty normally), you shouldn't be surprised if a pool under 1/3 the network size occasionally has a block lasting 3 times that duration.

My favorite part is this accompanies a lot of pool comparison posts.  Apparently because slush's stats are so bland/basic, people don't quite realize when the luck is bad there.  Meanwhile I seem to recall plenty of bitching about 20+ hour blocks at Slush within the last 2-4 weeks.  But apparently it's "never that bad at Slush".

Uhm, where are you getting that number from?  BTC Guild is only about 40% of the NMC network.  GHash.io, BitMinter, Eligius, and BTC Guild are all on NMC.  So are other smaller pools.

Pictures will come soon.  A few key points:

1) These are *not* next gen chips yet.  But I expect this is probably the form factor we'll see when they start using smaller chips.
2) They are powered by PCI-e connectors (you will probably have to short the PSU 24-pin connector by either soldering the wires together or using the paperclip method)
3) They're stackable.  They have grooves on the corners which will allow you to slide units to connect them together.
4) No need to buy your own fans, they're designed like a small wind tunnel.
5) 30 GH/s and overclockable through the web interface.
6) They will require a stratum proxy to work with modern pools in their web interface.

I do not know if they can be plugged in and recognized by mining software directly.

Yes, I just received some photos and tech spec confirmation from friedcat regarding what it needs to be setup, power connectors, etc.  I'm asking for confirmation on the price, and will be placing a limited order for the first batch to gauge demand before placing a larger order.  They will be listed as soon as they're available.

Work is now starting on the new API server which will include a brand new API for programs/users that would like more control.  The current BTC Guild API is limited to just a raw data dump, while the new one will allow you to pass in arguments of which stats you are polling for.  This will include:  Block Stats, PPLNS Shift Stats, User Account Stats, Pool Stats.

Since it's virtually impossible to know everything that users want, please let me know if you have any specific requests for things to be included.  Note that odds are if it isn't shown by the website in some way, it is likely not possible to produce.  A common request is per worker earnings, something which CANNOT be done due to how the database records your PPLNS earnings (worker-agnostic).

The dashboard was updated to re-enable the hiding of NMC statistics for users who haven't turned it on.  It's still a setting in the Settings if you want to enable it again.  If you have NMC hidden, you now have an "Active Workers Mining Summary" section in the top right of the dashboard.  This summary simply gives you the grand total line from your Active Workers (Speed, Total Shares, Total Rejects/%) to save the need of scrolling down.

Yes, that's how an orphan block looks on blockchain.info (unconfirmed transaction).  If it's in the pool stats, it was paid.

Orphans are paid as long as the primary payment server sees the block.  *Most* of BTC Guild's hash power is in the US, which is where that payment server is located.  There are the occasional very rare orphans found by the EU servers which do not get seen because the window between the two competign blocks was close enough to trump the latency between the US payment server and the EU server.  It's extremely rare for this to happen since every node is either directly connected, or has 1 hop between them (bitcoind doesn't have an addnode method that aggressively keeps connections open between the two servers, so instead BTC Guild had a few dummy servers which can only connect to the pool servers to attempt to circumvent that limitation).

That block can be shown as an EU-block due to a small token in the coinbase (03921b04040002b96505 is the start of the coinbase message.  05 at the end is the server identifier token.  04 and 05 are EU).

BFL promising deliveries in November, that's cute.  Obviously 2014

The "real" private server "required speed" is variable.  It mostly requires that you have a "fairly significant" investment in mining.  As new mining hardware has become available at lower prices, this threshold has been raised over time (otherwise anybody with a Saturn would have it).

However, whenever a persistent attack appears, there are semi-private servers that are quickly distributed to miners with a reasonable history with BTC Guild to help get them back online in the event that the baseline defenses aren't adequate.

It's most likely a poorly configured bitcoind node or pool software.  This used to be common among some pools that sent blank work templates at longpoll in order to reduce any overhead of building up a new block.  However, that really isn't needed these days.

It's unfortunate because now you have these pools that share txfees with miners (in the old days that was extremely rare).  Before, they could contact the pool and most upstanding pools would refund the tx fees.  Now that is only an option if your pool makes miners wait for 120 confirmations (and then it's still only a ~16 hour window to try to ask for the error back) before they can claim funds from a block.  In the case of BTC Guild, we do instant crediting of block rewards.  There's no way to refund those fees since the miners already got paid (and in many cases already withdrew).

Of course, the real argument:  Why the hell weren't they using testnet to mess with raw transactions first?  It's just stupid to be playing with thousands of dollars on the live network if you aren't positive you've done it right.

A transaction with a fee like that is not created by any standard Bitcoin client.  It's somebody writing a transaction in raw format and screwing up.

On the Pool Stats page, there's a list of blocks at the bottom, which includes how many BTC were mined with the block.  Everything over 25 = Transaction fees.

I really am curious why everybody calls it "gigaforce".  But no, gigaforge still works just fine, it's the exact same server as what you get redirected to on stratum.btcguild.com, it just skips the validation server.