Transactions like the one linked will only cause an orphan to the miner/pool that make a block containing it.  The block they make is invalid per the majority of the network's rules (BIP16), and all properly updated clients will continue building the chain off the previous block, ignoring the invalid one.

Small update to the site:  Worker speeds are now calculated more dynamically.  For regular miners this won't be too noticeable, but for anyone who turns on/off, your worker speeds no longer take 15 minutes to normalize.  It will begin showing speed estimates after about 2 minutes, and the time used to determine your speed will grow from there, resulting in a more accurate speed estimate as you continue mining.

If you notice any very odd speed estimates, please let me know so I can take a look.

The hot wallet has plenty of funds at the moment.  Looks like bitcoind timed out and didn't respond with a txid when you requested your most recent payout [which causes it to lock your new payout requests since the previous one is still "processing"].  I've corrected the error on your account.

It'll be time for an ASIC subforum when an ASIC miner exists.  Right now we have the promise of an ASIC [with specs/prices that scream its a scam] and nothing more.

Good point on TOR.  I will definitely look into adding that to the anonymous mining server as an OPTION [not a requirement].

'Anonymous' mining is a bit of an awkward term, since even regular BTC Guild accounts are anonymous for the most part [don't require any email/contact info].  A better word would be account-less mining.  Adding TOR would make it anonymous though .

Yet another poll added [yes, I've had a lot of ideas floating and I'll soon have the time to implement them].  The new poll is an option for anonymous mining [no registration, just use a payout address].

Anonymous mining will work as follows:
  1) Begin mining with a bitcoin address at anonymous.btcguild.com
  2) Log into BTC Guild using your payout address [no password] to check stats.
  3) You will be able to set automatic payouts or request manual payouts as usual.
  4) NMC may not be available in this setup, still working on how that will get implemented.


As with previous polls, the purpose of the poll is not to determine whether or not the feature will be implemented, it is to determine the order in which they are added.  The current order of addons is as follows:

1) BTC Savings Accounts [may not be available to all users immediately]
2) Direct PayPal payouts

Yes.  Because a difficulty=1 share is approximately 2^32 hashes.  Pool software likely isn't using anywhere near the optimizations that mining software uses to evaluate hashes, so lets say that it can only verify ~10 KH/s worth of hashes.  That means it can verify 10,000 shares per second.  This is a very rough number, since no pool has ever had to verify even close to that.

BTC Guild currently processes ~380,000 shares in 20 minutes, or 316 shares per second.  If my 10,000/second number is accurate, that means BTC Guild could support ~31x the hash power it currently has, which is about 35 TH/s.

Now in this scenario, I'm starting to think sending out higher difficulty shares would be beneficial.  The likely bottleneck would be DB access time (inserting 100k rows every 10 seconds in batches with my current software setup).

Historically, the biggest problems BTC Guild has had is pushing out longpoll connections quickly.  When you starting having 4,000+ longpoll connections, it starts to bog things down on the server.  Normally the bulk of those connections are to inefficient miners, so its very difficult to say just where the bottleneck will lie when dealing with highly efficient and very fast mining hardware.

They claim October...but I'm extremely skeptical.  I know quite a few people that are involved in hardware design/engineering who have dealt with ASICs in the past.  Not one of them believes BFL could possibly deliver the specs they're claiming (especially the ~2 watt 3.5 GH/s chip).

However, even if the end specs are only 10-20% of the claimed speed, it's still a massive leap forward in the hash rates that we'll be seeing on the network.

I'm looking at some alternative pool server software and running a lot of benchmarks to see where the choke points are.  Hopefully that'll get everything ready in time so we don't come crashing down under the weight of terahash miners.

Just wait.  Once some of the other projects die down, there's a chance at a much more modern looking (but still very clean) interface coming.  I'm doing a lot of work behind the scenes right now to optimize pool servers in case BFL actually delivers anything remotely close to their claimed ASIC specs.

Just to repeat what was stated in the last thread about this:

Changing the difficulty does not change the frequency your miner will request work.  It will only reduce the frequency you send work back.  For pools, the difference in load here is minimal, it's much harder to send you work than it is to verify work that was sent back.


If the ASICs are real (I still highly doubt BFL will produce anything remotely close to their claims), the entire mining protocol will need an overhaul.  Clients will either have to generate work locally and send it to the pool (similar to p2pool), or a method of getwork where a miner can get a packet of many getworks at once in a condensed format.

I saw it mentioned earlier, but I wanted to check.  Right now GLBSE is implying there WILL be a buyback on July 24th.  Do you know if this is going to be forced upon you by GLBSE even though you've stated you don't want to do that?  I know quite a few people (myself included) that were taking that buyback on the listing as a guaranteed event.  We'd prefer it doesn't happen of course .

I'm surprised it took this long to be honest.  The difficulty:price ratio for April - July was completely skewed.  But before that, it was looking pretty much like what we have today.  Paired with more efficient mining: GPU miners improved almost 50% in April with BFI_INT and other optimizations, FPGAs like Ztex, Icarus, etc., and the BFL Singles starting to be released in massive numbers (and now mini rigs).

The mining landscape is very different from what it was last year, and all of it is more optimized and power efficient.  Quite frankly we should be at a higher difficulty than we are already [mining should not be as profitable as it is for some people].

Thanks for the support, been a long time since the thread had any activity like that .

There's going to be a brief restart of mine1 in about 30 minutes (9:15 PM, PDT).  The downtime should be under 5 minutes.  The downtime will be one of the last steps completing the move of BTC Guild servers to a new physical node (faster hard drives and processors).  The only item remaining on the old server will be the database (still working out a gameplan for how to efficiently move that).


UPDATE:  mine1 maintenance was completed after a 4 minute interruption.  I was also able to do a small database optimization to speed up the connections between the mining servers, the website, and the DB server.  The website is snappy again after a little slowdown in the past few days.

I can say the one bit that showed me this is legit is that pirate will kick funds out when he has too much.  I just can't think of a scenario where you would do that unless this was going to be a MASSIVE ponzi scheme where his end goal was in the millions.  And from what I've seen, that just doesn't seem likely.

Although I am a bit sad that I got my BTCST account and less than 2 days later all my coins got kicked out from an earlier member depositing .

Support for the savings accounts put it high on the priority list.  Unfortunately since my account at BTCST is relatively new, and the amount of coins BTCST is willing to hold and pay interest to is limited, this service won't be able to launch immediately.  When an earlier member puts in their deposits, if the total coins in BTCST is beyond the threshold, coins are kicked back out to members, starting with the most recent.

I will be working on the backend for the Savings accounts over the next week to have it in place for when BTCST is able to accept more coins, and the account has a little more age.

PayPal withdrawals will likely be added early July.  I'm working on setting up a business account for BTC Guild with PayPal at this time.

For clarification (received a question by email):

This proposed BTC Guild interest-bearing savings account is an OPTIONAL service.  Your coins will not be automatically placed into the account unless you elect to do so.  That is why there is a delay on receiving interest after depositing funds:  Only the accounts that have elected to use the savings account will have their coins placed in BTCST.  All other coins will remain in the hot/cold wallets, and will not be affected by any BTCST default (if one occurs).

Correct.  It's a decision I may revise later.  I do not want people to be able to send extra money into their BTC Guild accounts.  This is mostly because there is no way for me to guarantee that BTCST will not default in the short term, before the insurance fund has been able to build up a reasonable balance.  By limiting deposits to mining income, it means the balances will be much smaller at the start, leaving them in the 3% weekly category.  This means more "profit" is made, which will cause the insurance fund to grow much faster relative to the amount in savings accounts, at least to begin.

A new poll has been added related to a potential new service for BTC Guild miners.  Full information and examples can be found at https://www.btcguild.com/savings_faq.php.

This proposal for a new service is an interest bearing savings account.  The account would be managed by BTC Guild, as a passthrough for a savings account at Bitcoin Savings & Trust (Forum Thread).  These accounts would pay weekly interest at tiered rates based on the amount stored.  These are NOT deposit accounts.  You would only be able to put money into them by mining or transferring your available balance into the account.

Since these would be passthrough accounts, they are not fully insured by default.  The proposal and examples on https://www.btcguild.com/savings_faq.php show how a special insurance fund will be managed for BTC Guild users.  Rather than pocketing the profits each week, all profits are added to an insurance fund.  In the event of a default by Bitcoin Savings & Trust, the insurance fund would be split proportionally to all savings accounts, along with any principle returned by Bitcoin Savings & Trust.

While there is more risk involved at first, as time goes by a larger portion of the total balances will be insured by the fund.  BTC Guild will only claim a profit if the insurance fund + principle received after a default are greater than the amounts owed to all miners utilizing the service.

There was a massive LUCK-BASED surge yesterday.  At one point there were 10 blocks in 20 minutes.  Those weird spikes really screw up hash rate estimate graphs.  Yesterday there were many pools finding blocks much faster than they normally should (luck).

There has also been some growth due to the $1 increase in BTC price in under a week, which should be expected.

The quote given by BTC Guild at time of withdrawal would be what you receive [likely ~5% less than Mt.Gox last price].  When sending Mass Payments, the sender pays all fees [unless there is something hidden I haven't found].  This avoids the whole personal/gift BS which is what tends to get PP accounts frozen in the first place.