The person who created the bad transaction made a post (and a raw transaction in an attempt to try to get a lower fee version on the network to possibly "double spend" the transaction with the appropriate fee), and confirmed their identity.

102 BTC of the overdone fee was returned to the original wallet the transaction came from in this transaction: http://blockchain.info/tx-index/42579467/4a0fe8cb78b19778a49d171642649c9ee25453ed206894c88b049d0ee7939a0f .  The rest was already credited to PPLNS miners (rounded up to 9 BTC).


Luckily you can always see the originating address, so it was risk free to send it back without worrying that it was going to the wrong person.  I just needed confirmation it was safe to send back to the original address, otherwise it would've been harder to go about sending the money back (https://bitcointalk.org/index.php?topic=135665.msg1445272#new).

102 BTC returned in this transaction: http://blockchain.info/tx-index/42579467/4a0fe8cb78b19778a49d171642649c9ee25453ed206894c88b049d0ee7939a0f

I'd highly recommend not creating raw transactions in the future unless absolutely necessary .  $1,500 is a pretty risky mistake if it didn't land on a known pool wallet/IP.

Just confirm it's safe to do so and I can send 101 BTC back to the originating address.  Unfortunately a bit does get eaten up because PPLNS users on the pool are paid transaction fees (but only a minor percentage of users take part in PPLNS).

1ciyam3htJit1feGa26p2wQ4aw6KFTejU is the originating address.

PPLNS users got a big boost to earnings from it.  Time to figure out who the real owner is and send them back the part that hasn't already been credited to accounts.

A nice stream of blocks helped speed up confirmations of the cold->hot wallet transfers.  Automatic payouts were processed twice this hour to catch the ones that failed today and yesterday.

Some payouts failed today.  Apparently a huge number of users who haven't been active/never withdrew coins in the past few months decided to come back and finally withdraw, cleaning out the hot wallet.  I'm refilling the hot wallet right now, and the bad payouts have been cleared from payment history.

I've noticed a lot of users have returned that were absent after the DDoS, but the split between Stratum and Getwork started shifting back to getwork.  When the servers were initially recovering, the Stratum redirects were not pointing to the proper IP, and your miners may have defaulted back to getwork.

If you're using a native Stratum miner and you're seeing any of the following:
1) Warning about not using stratum ("Mine more efficiently" notice at the top of each page)
2) Not having shares show up as PPLNS
3) Seeing "pool # not providing work fast enough" in cgminer output

Please give your miner a quick restart if you see any of the above when using a native stratum miner.  It should redirect back to the Stratum based server.

p2pool's luck is just that:  luck.  The smaller the pool size, the more varied that is.  90 days is hardly enough time for measuring it given it makes up less than 3% of the network.  For almost a year the p2pool luck was abysmal and anybody using it would've been better off with any decent sized pool.



It's hard to give a real world example, but you'll have a very hard time ever sending 13 BTC with 325 different inputs.  In that kind of situation, you'd be better off sending your inputs into a separate wallet with larger chunks (keeping the transactions small while doing so).  Do that a few times, then wait for those to mature, then use those to make even larger chunks (keeping transaction size small while doing so) again once they've matured enough to not require a fee.  Note:  This will not work if your initial inputs aren't big/old enough to avoid transaction fees.  Each 0.04 input would have to be 25 days (I think) old prior to being merged.

The "bag of pennies" scenario is a significant problem for small miners on p2pool.  Not so bad for larger ones.  But the larger p2pool becomes, the worse this problem is.  It's a hidden fee for using p2pool.  You get your money faster than some pools, though there are many pools that don't require waiting for blocks to mature (or PPS where you don't even have to wait for a block).  However, the larger p2pool becomes, the more frequently you'll be forced to pay txfees when spending coins.



p2pool's concept is great, but the payment method and share chain prevent it from becoming a major "pool".  Unless it gets turned into a series of supernodes which people mine through, which would end up being worse than the current pool system due to high stale rates using a remote node that has longpolls every 10 seconds.

Look for a pool that supports Stratum or GBT if you want the most efficient use of ASICs without worrying about the pool being too slow to send you new work.

I've deployed a fix to the generic 'btcguild.com' getwork server.  I brought back the 3rd getwork server, and pointed the default DNS to that server, but the redirect for Stratum was still using the old IP from before the DDoS.  If you're using a native stratum client, you may need to restart it to get back on Stratum.  This shouldn't have affected too many users, since native clients should default back to getwork if the stratum redirect fails, and most proxy users had the correct IP already redirected from before the 3rd server came back online.

Thanks for another week of updates.  I'm just wondering, do you collect any daily data that might be able to show the side effects of what happened when BTC Guild was being DDoS'd?  Started around 8 AM UTC on 12/20, and the pool was basically off for 8 hours and crippled for another 12.  Still missing a large chunk of hash power as a result (although BTC Guild historically loses ~500-600 GH/s whenever Litecoin difficulty drops).

Would be curious to see if we can get any hint of how the hash rate redistributes (if at all) when a major pool goes down.

The getwork servers had a brief restart today to put in a change that I have been considering (and tried once in the past) for quite some time.  Ufasoft-based miners are no longer allowed on BTC Guild getwork servers.  For almost every botnet I have banned on BTC Guild, all but 2 were using Ufasoft.  For GPU mining, there is no reason to use Ufasoft.  CPU mining is unprofitable, a waste of resources, and puts as much load on getwork as a fast GPU, even if you're mining on a raspberry pi.

This change should improve the performance on the getwork pools for all other users.

Just an extremely good run of luck.  It's why looking at daily network hash rate charts you see such massive swings.  It's not that tons of people are turning on/off, it's more about overall network luck than anything.

It'll fall back down.  After recovering from the DDoS, BTC Guild started shooting out blocks roughly twice what it's hash rate should produce (which means a ~3.3 TH/s pool is pushing out over 5 TH/s worth of blocks in the last 24 hours), which means a single pool is inflating the 24 hour estimate by over 2 TH/s alone.

If you ever encounter this error in the future, add 'www' to the address.  When the DNS shuffles around like this during a DDoS, I don't always have time to fix the redirects to the website.  It should let you in without it now.

PPLNS is a very simple system when you think about it correctly.  BTC Guild uses 'N' = 30 million.

When a block is found, the last 30 million shares (10 shifts) split the block reward.  Ignoring pool fee/transaction fees in the block, this results in:

25 BTC / 30,000,000 = 0.0000008333333 BTC per share.

So each time a block is found, the last 30 million shares are paid 0.0000008333333 (again, this is without doing the math for pool/transaction fes).  This is much less than PPS.  However, a share can get paid for multiple blocks, since each block pays the last 30 million shares.  The PPLNS Shift History shows you how many blocks paid to a given set of shares.

At current network difficulty, it takes ~8.5 blocks to equal the PPS rate.  If a shift finds 8 or less, it was paid lower than the PPS rate.  If a shift finds 9 or more, it was paid higher than the PPS rate.


The first week of PPLNS was pretty rough at BTC Guild on luck.  However, there have been 24-72 hour periods that paid an average of 30-50% higher than 100% PPS would have.  Luck since PPLNS began is very close to neutral at this point.  The only thing skewing that a bit is the DDoS that hit on 12/20 (and early 12/21), which affected Stratum more than getwork due to which servers were targeted, meaning people on Stratum (which is required for PPLNS) were more affected by the pool outage than getwork users.

The attacks haven't completely stopped, but they are being mitigated.  The mergedmining server should be up again shortly.

Try multiple servers: mine1, mine2, mine3, btcguild.com, etc.  The stratum proxy will redirect you to a different backend, so even if that DNS goes down you should remain connected.

The attack keeps moving an hour or two after each nullroute.  Called the DC again to have them nullroute the next one, and I'm juggling servers around to try to keep things running as much as possible.

What do you think is wrong with vardiff implementation?  Current settings are it will double your difficulty if your shares per minute is above 40.  Which means:

Difficulty 1 for users that are between 0 MH/s and 2800 MH/s..
Difficulty 2 for users that are between 2800 MH/s and 5600 MH/s.
Difficulty 4 for users that are between 5600 MH/s and 8400 MH/s.

This is on a per-connection basis, so if you have multiple copies of mining software open, but each one is running separately (instead of through a stratum proxy), the vardiff is applied to each miner.  This gives an expected SPM range of 20-40, the average being 30.  This is the highest SPM target of any other pool at the moment, chosen specifically because it provides very little variance even in a small window (15-30 minutes).  Obviously this only applies to Stratum.  There is no vardiff for getwork and never will be.