HDD speed, CPU speed, and how well connected you *AND* your peers are, in roughly that order (assuming server quality bandwidth).

1) HDD Speed:  Disk access still seems to be a relatively heavy hit whenever a new block is found.
2) CPU Speed:  Validating a new block and subsequently updating to work on the new block both appear to be mostly (entirely?) single threaded operations, so the raw clock rate is quite important.
3) Connectivity:  Assuming you're on a server quality connection, your biggest limits are how many peers you're connected to, and how well *those* peers are connected.  I've found having only 30-60 connections is preferred over having 120-1000 connections, when your 30-60 include at least 10 "known good nodes".  The biggest window for orphans are the first 2-3 hops of distributing your block (most orphan races, according to blockchain.info are roughly a 80%/20%  or 95%/5% split on how much of the network has seen a particular block in the orphan race.  I've never seen those numbers approach a true 50/50 split.

This is actually why BTC Guild has taken the "many individual bitcoind instances" approach.  Each one is connected to each other, and each one has a list of about 10 different nodes they always try to connect to, then let the other 40-50 nodes come randomly.

Sorry, missed that question apparently.  I'm interested in it, but my last PMs have gone unanswered.  I'm probably asking too much of the people trying to make them because I'm not willing to front 600+ BTC for inventory of a product that has an unknown rate of failure and unknown levels of demand.  My biggest concern is ASICMINER Gen2 completely crushing the BitFury sticks.  ASICMINER makes the chips and the USB boards, while these other USB sticks have chips made by BitFury then somebody else buys the chips anddoes a *relatively small* production run for the board assembly & chip placement.  There's a *huge* difference in the end cost for ASICMINER to produce Gen2 compared to what the BitFury USBs can possibly drop to.

I'm no help on getting the settings to save, but for the proxy:

-o <server host> -p <server port> are how you point the proxy at a different pool.  Example:  -o stratum.btcguild.com -p 3333 will connect to BTC Guild with the stratum proxy.

BTC Guild sells them (in hand, ships within 24 hours) for 0.15 for repeat customers, 0.17 for new customers.  That *includes* the cost of shipping.  So no, the one you linked isn't worth it at all.


However, they are unlikely to ever produce a return compared to the value of just buying that much BTC and holding onto it.  These days they're more of a gift item/novelty.  They're very good as a replacement for noisy GPUs if you want to keep mining.  Get rid of the heat/noise/power consumption that a graphics card uses for a fraction of the cost.

Just for those wondering if the pool is having issues (pool overall hash rate drop):  MegaBigPower began solo mining today, which means the previously fastest user is no longer on the pool.  It's sad to see them go, but it was going to happen eventually (just like ASICMINER).  At least it will remove some of the "omg BTC Guild is 51% again" feelings...til the next time.  Happy mining all.

Nothing is "correcting itself" - 4 shifts without a block found is only ~2.5 hours.  The pool had no blocks between 9:04 AM and 11:30 AM (Pacific Time).

Is BTC Guild your first or second pool?  If its your first, that error isn't coming from BTC Guild. The error isn't something that my pool would generate, so I'm guessing your failover pool is having issues.

There is going to be a brief restart of the private server in the next few hours.  Historically, most users on that server reconnect quite quickly, so it should be virtually unnoticeable.  This restart is to link that server to a different bitcoind server until the new dedicated hardware for the private server arrives later this week.  Recently the private server has been lagging a lot when new blocks hit [HDD speed bottleneck], causing a higher stale rate than what would be seen on the public servers.

Later this week the public stratum servers for BTC Guild will be extended from 3 US servers to 5 US servers in order to give a better balance of the load, and extra redundancy in the event of an attack.  That upgrade will be completely transparent and users will not experience even a brief moment of downtime when the new servers are added.

Are you running the latest bitcoind?  5-10 seconds is a very long time, even for the crappy performance you get with AWS.  GBT is very single-core CPU and HDD intensive, and AWS uses many-cores with relatively slow clock rates, and disk access speeds are always garbage.

Best specs you can get for GBT:  High clock speed modern CPU (E3-1230v2 is beastly for this since it has a 3.7 Ghz turbo, 3.3 baseline), and SSD.  Another alternative is storing the blockchain on a ramdisk, but that's only an option if you've got a dedicated machine with 32GB+ of RAM.

You mean 35.7-36.1%?

If luck is equal, you'll make more on BTC Guild counting NMC.  If luck is not equal, obviously it depends on which pool was lucky and which wasn't.

Also, Guild has _NO_ penalty on payouts for shared hash rate or failover.  PPLNS does not penalize you if you leave, unlike exponential score where shares become worthless shortly after they're submitted in long rounds.  Once the share is submitted, it's paid just like every other until it expires (after it leaves the 'N' window).

Also:  If you submit a share, it continues to get paid for 8 hours, rather than only getting paid once (or not at all due to exponential score on slush).  It seems nobody ever factors this in when comparing payouts.  The math shows quite clearly Guild will beat slush (NMC + paid Orphans will pay better than a 1% fee difference).

No.  The previous update screwed up how the pool speed estimate on the website is calculated.  Working on getting it resolved.

In the long run it won't matter, but splitting hash power between pools can help with short term variance (somewhat).  I'm not sure how well this strategy works at the moment when you have BTC Guild with the lion's share of the network, while the second fastest non-PPS pool is only ~1/5th their size.  The writeup on splitting hash power over many pools is quite old, and I don't know if it made assumptions for splitting hash power between a pool with 30-40% of the network and others with only 4-7%.

As stated above, long run it won't matter.  Theoretically it reduces short term variance, but that *may* not be true with the current network distribution percentages.

Small site update:  The worker speeds on the dashboard now update on a 1-minute interval again, which will help produce faster speed estimates when turning a miner online, and more quickly adjust to a proper estimate.

Since the network has changed quite a lot over the last few months, the new system is setup to use 1 hour of share submissions to generate the speed estimate, but that 1-hour window will be reset if it finds a 5-minute gap in share submissions.  I've also set it up so if you decide to reset your share counters, it will also reset the speed estimate, which can be very useful when troubleshooting hardware.

Are you sure the worker has hit your idle time threshold?  Check your spam folder otherwise, because they absolutely work.


EDIT:  They also won't trigger on hidden workers.

BTCGuild sends out a *lot* of emails as is due to Idle Miner alerts and Confirmation codes, which have made me fight to get the mail server stopped from being marked as a spammer on multiple occasions.  BTC Guild sends 100-250 payouts per hour, and adding that to our outgoing email would basically guarantee most major mail providers would start marking everything as spam, or even worse, start blocking it from even being forwarded to their servers.

People who refuse to update software for more than a year "because it still works", people who are using ASICMINER blades and are too lazy to setup a stratum proxy or compile newer bfgminer builds which support them, and botnets that are small enough to not be autobanned/easily spotted during manual inspection.

There's still approximately 4-6 TH/s using getwork on BTC Guild, so it's always hard to just toss out that hash rate.  But right now the only reason it still exists is I stupidly prepaid that server for 3 months last time I renewed, so I want to get the most out of it while it's still there.

The issue is 24-hours is too short of a period for a meaningful chart.  I stopped giving a damn about what blockchain.info said the % of network for any pool was a long time ago, because even if the pool+network speeds are steady, you'll see the pool swing 5-15% on that chart day to day for BTC Guild.  Other pools can fluctuate to showing more than double their actual share of the network in a 24-hour period, or more.

Getwork Server Reminder

As stated in the past, the getwork protocol is on life support (at best) for BTC Guild, and in approximately 2 weeks it will be shut down completely.  I have already extended this beyond my original posts (stating it would close when it was less than 2% of the pool).  Getwork will be permanently shut down for BTC Guild in early October of this year.

Yes.  Blockchain reports lots of garbage.  There's a link on the very first post showing you an accurate chart (one that doesn't classify 35% of the network as unknown, and doesn't use a USELESS 24-hour chart).  And for the record, clicking the extra length on blockchain.info's chart doesn't change the data (this hasn't worked properly in close to a year).

BTC Guild is 35.9% of the network over the last 10 days.



Not to mention it's a necro from 6 months ago when 50% was actually looking like an imminent event.