I swear I tried to give up judging people on their grammar and spelling. I tried so hard to walk away from it, I really did - and then you had to go and do this... Great. Just Great. I'm back off the fscking wagon again. Look what you did.

Quite happy that the movement was in the positive direction, maybe I can start making reasonable income mining again. Oh wait, that's right, difficulty increase

Oh well, let's see where it goes from here.

Not really, the equilibrium will be influenced by the profitability certainly enough but I doubt we'll see mining become truly UNprofitable.

I have rigs in my living room, bedroom and kitchen. They make a ton of noise, lots of heat, I've had to add portable air conditioners to parts of my house, I have to keep one eye on my pools' status tables to make sure they're all still running and connected, every so often they need reboots, maintenance, etc. It's not the worst job I've ever had but it's still a bit of a hassle and there IS a baseline income below which it's no longer worth my time - and that baseline is > $0.

If you were correct, people would only leave when the net gain of running a miner became zero, which simply isn't true. Once we fall below a certain level of profitability, we'll begin to cross other folks' (and maybe my own) personal thresholds and they will pack up their rigs and go home. At this point, difficulty drops and mining becomes more profitable again.

Check out this post: http://forum.bitcoin.org/?topic=7427.0

There's a wonderful chart there that shows an arbitrarily scaled price over difficulty. See how it dips then climbs and repeats that pattern over and over? It's called homeostasis - you may have learned about it in your Biology class, but they should've taught it in Economics as well

I make ~3 BTC per day, give or take. It should be more given the number of nodes but it's summer in Vegas and my AC can't handle the load enough to keep the overclocked the way I want - even with the 9,000 BTU portable unit I added JUST to cool the rigs 

Bah, never mind, it'd probably be enough work to implement the n-round SHA that I might as well just rewrite the login system from scratch... Which I think is what I'll do.

I started off thinking I could reuse some code but I'd rather do it right - and at this point there's no question of whether or not it's too much work for me to follow through. It's WAY too much work but I'm STILL following through.

It should be a badge of honor for this community that you've got me interested enough in a project to actually do something more than throw ideas around 

Y'know how everyone on the internet says "oh, don't mess with Anonymous"?

Y'know how everyone's first reaction was to point at LulzSec because we all know there's heavy anonymous presence here?

'Nuff said...

That's what I'm using. Their library doesn't implement the HashAlgorithm class and I can't for the life of me create a usable wrapper for it. I could just be having a massive brainfart though, if you happen to find a way to wrap the thing please please please let me know, I'd love to use it - otherwise I'm pretty much spent with the whole BCrypt thing.

Also, I've now played with Rijndael enough to slap myself in the forehead and remember that it's a symmetric encryption algo, not a hashing algo - the last thing I want to do is store passwords in any kind of reversible manner... GetHashCode() was entirely the wrong method to reference but hey, I've been going at this for almost 12 hours today and my brain is pretty much fried from dealing with crypto. Maybe it'll all make sense again in the morning after some nice refreshing sleep and a hot cup of coffee? 

Hey, thought... What if I did occasional benchmarks automatically to see how many rounds of SHA1/SHA512/whatever it takes to eat up N milliseconds? It might not be as advanced or future-proof as BCrypt, but it would be dead simple and if I specified long enough (200+ ms perhaps) it'd probably amount to thousands of rounds. THAT would be easy enough to override in a usable way and I could just store the ever-shifting number of rounds alongside the hash. If I forced password resets at a reasonable interval, it would also ensure that the only way the # of iterations ever got low enough to become insecure is if an account was simply abandoned for a very long time.

Who said anything about legal manners? If I were Mt Gox I would be least worried about the folks with lawyers - I'm more frightened of the folks with baseball bats 

Well, hey, if it's got a GetHashCode() method (which it appears to) I can use it with the code I've got, the only question is how does it compare to BCrypt? I'm obviously not a crypto expert considering I was going to use an SHA variant so what does the crowd think?

So..... NameCoin?

25 minutes to go and no response email here. As far as I'm concerned, I'll be withdrawing anything I've got there and jumping ship to TradeHill.

Proof that we've got more going on than our shitty centralized ancestors?

Repeat themselves repeatedly?

Mandelbrot perhaps?

Depending on how classy it's done (i.e. text links vs uglyass banner ads) I might be interested in linking to others, I'm definitely interested in being linked to.

http://www.bitcoinreference.com

Except that the only BCrypt library I can find doesn't implement the HashAlgorithm class so I can't use it with my existing solution. I'd have to rewrite the entire login system... Which I might still do... We'll see

OK, found a BCrypt library for C#, now I just have to tweak everything else to actually implement it 

I haven't read the documenI'm assuming this is the "difficulty" value:

    // Blowfish parameters.
    private const int BLOWFISH_NUM_ROUNDS = 16;

I don't have a server available to test on at this exact moment, anyone know if the 16 round default is enough or have a suggestion on where I should set it?

Oh and one more thing I've picked up whilst working in the casino management software industry... Our security is usually just as crappy as banks but our accounting and transparency is bar none. I'm hoping the above will make it significantly harder for anyone to pull something like the Mt. Gox incident, but even if they do it's just as important to have regular audits. Imagine if the Mt. Gox hack weren't a big obvious 500,000 BTC move but a large number of tiny transactions over a long period of time. How long would it have been before MT noticed the transactions adding up to meaningful numbers?

PCI is actually a really terrible standard - little more than the lowest possible baseline they could've set. Also, while it might apply to the finance industry some day, it currently is meaningless to anyone but merchants and those who supply hardware / software to said merchants. BTC actually takes a lot of the load off of merchants since the whole thing is built secure from the ground up instead of relying on nonsense like sending credit card numbers in plaintext, which then requires merchants deal with HTTPS unnecessarily.

For the record, I do support (almost) everything that's been said so far about security for exchanges I just wanted to clarify that despite vague-sounding comments, they don't necessarily apply to merchants.

I'm actually working on some ASP.NET / C# code for another project right now that already meets many of these requirements... Now that I realize how close I already am to the mark I might just spend the time to make an exchange that implements (most of) these suggestions.

I don't have iterative hashing just yet, but SHA512 with a nice long salt seems fairly strong to me. If I do modify for iterative hashing I'd also throw an extra application-specific salt into the (encrypted) stored procedure just so we're not storing ALL the data right there in the table(s). I do use cookies (session variables SUCK without them) but all cookies are encrypted with very short timeouts. I also use rotating session keys to validate everything users do. Every row of every table has a "validation" field which contains an SHA1 hash of all data in that row plus an application-specific salt and the stored procs that contain that salt are all encrypted of course. The "validation" field prevents attackers from simply updating a row - all changes must go through stored procedures which of course all require some form of re-authentication.

So if (and that's a big IF) I were to modify my already-existing code, what non-obvious measures should I throw in the mix? (and seriously, non-obvious measures... I know to parameterize my fscking inputs)

The average computer in 2010 shipped with a 250GB 3.5" hard drive weighing approximately 625 grams (~22 oz)

This means that each kilobyte of data "weighs" on average 0.000000088 oz. If I consider my wallet.dat to be "average" at ~352K that means it "weighs" ~0.000030976 oz.

According to bitcoinwatch, there are 6,637,400 BTC in existence right now, and the estimated network size is 11,250 users. This means that, excluding extreme cases, the average user has ~590 BTC.

We can therefore say that 590 BTC "weighs" ~0.000030976 oz and so 1 BTC "weighs" 0.00000005 Oz.

Since 1 BTC is currently valued at $15.4998 that means that it is trading at $309,996,000 per Oz.

Gold is currently valued at $1,545.99 per Oz, so ounce for ounce BTC is worth about 200,516 times as much as gold.

Yeah I was pretty bored