We've been at 0.6.2.2 since a few days after the announcement of 0.6.2, which we initially heard about thanks to you.

I like the direction the bitcoind code is going but it's hard to argue that Gavin hasn't fouled up in how he's been dealing with the recent releases, with many things being done in secret.  BIP16 was initially stalled after it was announced while network consensus was being done.  Then when Deepbit finally switched over to BIP16, he gives pools two weeks to switch over to an unstable beta known to have lockup problems.  A few hours before the BIP16 deadline, the "stable" 0.6.0 release is announced after 2-3 hours of the "it compiles and runs" release candidate testing.  0.6.2 comes out of nowhere and pools must update or else a DoS or fork may occur; have you seen the kind of changes 0.6.1 made?  That is a major change from a deployment POV and needs heavy testing to make sure that there are no deadlocks and that no corruption occurs.  How much stress testing did it really have?  I've already noticed one area in the code where the locking differs between 0.6.0 and 0.6.2, which may be due to bad code updating (it's very easy to mess up), but have not investigated it.  And I've barely looked at the 0.6.2 code.  Backports were mentioned but no info was given on where they could be found.  Were 0.6.1 or 0.6.2 really ready or were they rushed?  Given the changes to 0.6.1, it might have been better to have a 0.6.0.1 patch instead.  We were already (accidently) using a seemingly stable pre-0.6.1 build so the switch to 0.6.2 wasn't a big deal.  If pools/services were made aware of the risk with 0.6.1, I don't think many would have updated right away.


The mailing list would be helpful.  Even a sticky in all bitcoin subforums indicating the current version and its release notes would help.  New version or release candidate annoucements usually get drowned in the sea of threads.

what's the difference?  1000 mBTC = 1 Bitcoin.  Yes, a human must manually approve any Bitcoin in/out.  This will become faster when we can afford to have someone around 24/7, but it shouldn't ever take more than 12 hours and in most cases it'd be processed in less than 1 hour.  Think of it as incentive to leave some credit in the system

Yeah, I'm not too sure what's going on but everything appears to be functioning correctly and in sync with the network.  The competing blocks have all been found within 20 seconds of each other and blockchain.info is seeing them (both ours and the competitors') within a minute after being found.  I'm not sure what the norm is but a quick browse of the orphans at blockchain.info shows a lot of orphans recently and seems to indicate that the smaller pool usually loses out against a bigger one.

Bitcoind was restarted to clear out a potentially slow selection of connected nodes and the number of connections were increased.  Hopefully Gavin's not doing another one of the required updates to bitcoind and not informing smaller pools.

I didn't really care to check since he gave first and as far as I knew, MTGO tickets were irreversible.  Apparently they are not, however, after discussing with the Wizards support, they're going to let me keep the tickets.  His MTGO id was 'cyntrez', but I suspect he is banned by now.

I purchased some Magic: the Gathering Online tickets from Alarmoz (https://bitcointalk.org/index.php?action=profile;u=55563) a few days ago and just today got contacted by Wizards about the tickets being stolen and my account being under investigation.  I suspect they will take the tickets back from me.

I noticed!  thanks for doing those reports, btw.  pretty awesome.


ok, lemme pm you for more info.

how much are you trying to queue?  bitcoin or namecoin?

great.  thanks for the update

I just tried refreshing the DNS settings at Rackspace.  Please give it a shot now and let me know if it's working.

It could take up to 24 hours for negative DNS caching to clear.

try clearing your browser cache and cookies.  try a ctrl+f5 to force refresh

I suspect there are a number of factors at play here but my guess is that for most people it's just that they stand to gain very little from switching away from Deepbit and it's not worth the brainpower/time it'd take to determine the best new choice and get everything set up, and the chance that they could be wrong again, and more wrong than they are already.

http://en.wikipedia.org/wiki/Cognitive_dissonance

http://en.wikipedia.org/wiki/Confirmation_bias

http://en.wikipedia.org/wiki/Sticky_(economics)

http://en.wikipedia.org/wiki/Analysis_paralysis

Thanks for reporting that.  The domain should be back up.  If it's not, clear your cache.  Apparently, GoDaddy waits until your domain is expired to attempt to renew, and if there is any problem at all in billing you, you're shut down.  Might be nice if they renewed a day or so before you expired so if there were any problems you'd have time to correct them.  Anyway, I needed a reminder to move after the SOPA crap so we'll be off GoDaddy soon.  I apologize for the inconvenience.

you're welcome.  Thank you for being patient

Ahh yes.  I'm more used to dealing with log(r) and log(o) than fiddling with the other parameters.

Added two-factor authentication to the site.  Yubikey and Google Authenticator (HOTP and TOTP) are supported.  You can set it up under Account > Password & Security.

Unfortunately, no fix yet for the rotten luck we're having.

Thanks for the correction and link.  I haven't seen that and it should help people understand how the different variables come into play.

I was thinking along the lines of sites with extremely high o and extremely low c (resulting in a low r/high maturity time) to explain the low variance the poster was seeing.

Thanks for joining.

It looks like you've set it up properly except for the test worker.  Was that the one you were testing the idle miners notification with?

You can also find us at Ogrr: https://ogrr.com/forum.php?f=26

The first answer is a good summary but the designer's criticism of DES based encryption should also be viewed with the same type of criticism for bcrypt/scrypt.  DES and other NIST type encryptions are heavily studied and analyzed, resulting in the breakthroughs in finding the vulnerabilities that the designers claim as a failure of DES/SHA.  If the same amount of resources were put into bcrypt/scrypt analysis, it's likely that breakthroughs specific to those crypt methods would be found as well.  If you don't think it to be the case, the recent finding that the reference implementation of bcrypt that is used in almost all programs is flawed after 10 years of use should serve as a warning: http://news.ycombinator.com/item?id=2654586.  The creation of scrypt after 10 years is also a testament to bcrypt's lack of analysis; scrypt is an attempt to slow down the hashing even further due to the rise of technology that was available 10 years ago for those with big budgets.  In a sense, it is security through obscurity (very little research compared to the "defective" algorithms).  I don't think there has ever been any real proof that what's being done with bcrypt doesn't weaken the crypto and people are just taking the designer's word on it.  What is undeniable is bcrypt/scrypt are generally slower than SHA on easily accessible hardware.

The thing to get out of it is also in that answer under the "What NIST recommends" section:


So even though in theory scrypt is possibly better, PBKDF2 is safer and is sufficient (the principle of high iterations hashing behind bcrypt/scrypt is the same as PBKDF2).  The general recommendation is to use well established crypto instead of creating your own.  I'd put bcrypt/scrypt on that sort of level because there hasn't been enough crypto experts checking to see if what's being done with the secure blowfish encryption doesn't weaken the cryptography after many iterations.  In some cases, combining or using the same secure crypto will weaken it.  In other cases, doing it multiple times will make it more secure (3DES).

I'd avoid bcrypt altogether unless you have a fixed implementation, but that would mean you're now non-standard.  If you're going to compile your own code instead of using standard, unpatched code, I'd use scrypt instead.

Once something is "secure enough," you should focus on the next weak link.  If you're going to use secure password storage crypto, it's not going to be of much help if you allow users to use weak passwords like "password", which happens to be in the top 3 cracked passwords on several social networking sites.