The US is building a 20 petaflop machine at Oak Ridge:
http://www.techeye.net/hardware/us-titan-supercomputer-will-dwarf-chinas-tianhe-1a

But they made a classic newbie mistake of buying nVidia instead of ATI  

Well, now that you've let everyone else know about all these stupid people, tomorrow you'll probably be able to find a bunch of 5970s on amazon for $775.

Well, if they buy at $1.10 and the price doesn't rise to $1.20, I guess that makes them an investor.

Ah, I see now.  If you compute the next two blocks faster than the rest of the network, the chances are still 50/50 whether you can compute the next block faster than the rest of the network.  But if you always build on your own blocks and not the shared blocks...on average, every other block created (by you or the network) will cause the entire network to oscillate between your block chain and the other block chain.

I was thinking the other day about the practice of encoding a block into the client (that basically fixates the chain as of some block in the recent past)...perhaps that should be codified in the client to happen in some way automatically...set a limit of say 60 blocks and make it so the client's will not accept any chain that alters a block that's more than 60 blocks old.  If someone were really paranoid about a transaction, they could wait 60 blocks (around 6 hours on average) for confirmation.  I'm guessing there's a downside to this, but I'm too exhausted to think through it at the moment.

Edit: One other thought...something like this might be useful for garnering transaction fees.  If you have this 60 block rule for firm embedding of the block chain...anyone needing rock solid confirmation within 6 hours would have an incentive to pay a fee with that transaction to ensure it gets included in the next block or two so they then only need to wait ~6 hours.  If they don't pay a fee and it takes a couple hours for the transaction to get into a block, they could be waiting 8 or more hours.

LOL...you knew someone was going to cite the Elliot wave.  I think in reality, most people that are putting some money into bitcoins understand that it could collapse at any time and hence only put in what they're willing to lose.  The flip side of that is that they're also not in any hurry to sell (and probably think bitcoins have enormous potential that far outweighs the risks of losing the small amount they've put in).  In addition, you probably have new people discovering bitcoins that reach similar conclusions and want to build a position.  And, at this early stage a wealthy individual or two that are willing to put a significant amount into bitcoins can really drive up the price (but it could fall just as quickly when they stop buying).

That's what I thought.  So, at 50% of the mining power on the network, you would get on average every other block...if people were waiting on just one block for confirmation, it means that in order to double spend, you would have to be able to compute 2 blocks (containing your double spend) before the rest of the network is able to compute 2 blocks...you could do some double spending with that and undermine confidence in the network.  But, you still couldn't do it on any sufficiently long time horizon...if people waited even three or for blocks for confirmation, odds are pretty good that they would protected from double spends.  I wouldn't call that overthrowing the network (if it started happening, people would in fact start waiting longer for confirmations and that would quickly limit the theft a double spender could pull off), but it could certainly have a very detrimental affect on confidence in the system.  If the objective were to steal money, I don't think super computer would be an economical choice (the top 10 supercomputers are likely to cost far more than all the bitcoins in circulation).  But, maybe the economics are better for a botnet.  If the objective is to undermine the confidence in bitcoins, this attack could do a lot of damage and I think is the biggest threat that someone with a lot of mining power presents.

So, what does it mean exactly to "overthrow the bitcoin network"?

But the longest chain still has to be a valid chain correct (meaning, no double spends in that chain)?

Hard to debate that.

You're speaking of mining power, but that's not the whole story.  Power alone would not be sufficient to overthrow the network.  If you held 50% of the mining power (which would require that you double the current total power of the network), about every other block would be yours and you could slow down the rate at which transactions made it into the chain, you could try to double spend, but your direct peers would immediately reject blocks with double spends.  You could probably come up with some ways to create a DOS attack on the network.  But, I think enough people would recognize such chicanery and would take measures to isolate and remove the bad actor from the network. 

To take control over the block chain, you'd also need to control over 50% of the nodes on the p2p network that validate any blocks you create.  Your powerful hardware could also run a bunch of nodes, but I believe the client seeks diversity (in terms of ip addresses) in the nodes with which it will connect.  That would make it hard to overcome the validation that the p2p network performs.  You would need to double the number of clients *and* convince the rest of the network to connect up with them instead of others (so, you might need to arrange for a bunch of different IP address subnets).  A botnet could potentially accomplish this (a botnet for ip diversity in combination with some super computer miners might be a good way to go).  Or, you could also convince a bunch of people to run your special, hacked up client that changes the rules for block acceptance.  Or you could write a virus that targets the bitcoin executables to overwrite people's legit clients with your own hacked up version (that changes the rules for block acceptance).

Actually, I've got another project that bubbled up ahead of the native Mac client in priority (just something I think will have broader appeal and is more urgently needed).  I'm not prepared to talk about it just yet other than to say I will be using this branch I've created for it.  I still would like a native Mac client though.

After putting together the 0.3.21 release candidate today, I'm thinking after 0.3.21 is out the door it might be a good time to do a major source tree re-org.   I like the idea of following the GNU directory layout standard, and it would make my job easier if source was in src/, readmes/etc were in doc/, scripts to automate the Windows build were in build/, etc.

PS: jaromil is the second person I've heard who says they'd prefer a development mailing list.  I don't care one way or another, but it would be easy to create one using SourceForge's mailing list feature.  What do others think?
[/quote]

I'd vote for a mailing list...in other open source projects I've worked with, it's worked well. 

As for a re-org, let me know if I can help.  I think a simple approach of separating the classes out into *.h, *-inl.h, *.cpp files is a good start.  Some people have objected on the grounds that it creates a lot of files (in reality, less than 150), but I think it's a clear and simple rule and allows people to easily reuse any of the classes in any combination for custom projects they might work on.  If you don't separate the classes like that, then what do you do?  Five classes per file?  Ten?  I think a clear and simple rule in this regard overrides the concern over a proliferation of files (and actually, I like being able to see all the classes when doing an "ls" in the directory).

This is a key point...you have to involve a trusted third party in the process to help ensure 2 things: a) than an order can be accepted by anyone else in the system and b) that trades actually execute (whether that's by requiring collateral up front or by the exchange making a guarantee is a separate question).  Without these, the price discovery function of the system is compromised because the system can be easily manipulated (people making trades with themselves, people not actually settling trades, etc).  The trusted third party then makes certain information about the trade available to the public to help in general market price discovery (which is for the benefit of everyone).  We just need more of these trusted third parties and perhaps a more standardized and federated trading platform.  It would be nice to separate the various concerns in the architecture (allowing different people to operate the order entry and execution system from the people backing orders with collateral, from the people providing market intelligence, etc).

How about keeping a few encrypted backup copies of your wallet with a couple different online storage services.  Then keep the decryption codes and instructions in your safe deposit box (or better yet, keep the instructions online and encrypted as well...in the safe deposit box, you have the decryption code for the instructions and a URL).  This way, as you add new keys to your wallet, or you move things around, you only have to update that set of online instructions (rather than print a new copy of your wallet and replace it in your safe deposit box).  This is essentially what I do (though it's not just for bitcoins...and there's no one sheet of paper that has all the needed info...you need 2 out of 3 sheets of paper that I have distributed among family members).

I think it's good to let actual needs drive evolution, but that doesn't mean it's not worthwhile in soliciting ideas/requirements if you're about to undertake work like this (but, I do think it would be better, for someone that is so inclined, to collect some input/feedback...and then go write some code and let the code be the specification...I wouldn't agitate too much about getting the specification agreed upon by a large number of people in advance).

So, here's my feedback...first, here's a "user story" I would like it to support:
"As a user, I would like to have very tight control over the handling of my private keys"
    - to support this story, I think you need to boil down the private key handling to the very basic methods that require the use of unencrypted private keys...I think this is basically the creation of new keys (for receiving payments) and the creation of spend transactions (is there anything else?) ...I envision a very simple module (with a very small amount of easily comprehensible code...perhaps in a very readable language other than C++) that supports an API to a) instantiate a set of key pairs from a serialized form (where the private keys are encrypted), b) request the creation of a new key pair, c) request the creation of a transaction, d) request to serialize the public portion of all key pairs e) request to serialize all key pairs (with private keys encrypted)  ...additionally, the key pairs might include a small bit of meta info (like a description of the key as the current client supports) ...an implementation of this very small API would allow for someone to run a very small and trusted bit of code that is used to maintain the privacy and integrity of their keys (about the only UI that module would require is a password prompt used for the encryption of the private keys), while at the same time allowing the rest of the system to manage physical storage and backup of the encrypted keys and create the full wallet GUI (showing a balance, a send bitcoin UI, a transaction listing, an address book, etc).  ... few additional APIs to let the components work with keys individually might also be useful

I would be very interested in a solution that utilized 0mq+protocolbuffers for this.

I mentioned it on IRC that I don't see a need for bitcoind to have any process forking behavior in it...interactively, you can fork the process easy enough to run in the background (and even detach it after starting).  And, if you're setting up a server, it's simple enough to run in the background (and if you're serious, you'll be using something along the lines of daemontools to manage it).

I could even be persuaded that the only command I/O interface it needs to support is over stdio (because that too is easy enough to redirect, could be put behind something like xinetd, etc).  Switches could be used to control whether it's JSON, or human readable, etc (or use separate executables for different formats).  (but there's also an argument to be made against over-doing the modularity)

I suspect, if it's a botnet, that whoever is using it has discovered that they can't mine full time and unload everything they mine without significantly pushing the market down.  So, they might be mining for a while, until they collect some amount of bitcoins then they switch to something else lucrative while they unload the bitcoins over time...once finished unloading (and perhaps when done with the other activity) they go back to mining again to load back up on bitcoins.

I think that kind of price move would either be a) relatively temporary due to some panic or b) permanent and associated with complete demise of bitcoins.  In the first case, the price would recover as would mining interest and the situation would right itself.  In the second case, it's game over for bitcoin, so who cares if it takes 5 years or 5 decades to mine the next 2016 blocks.  It's hard to imagine a scenario where it loses 90% of its value and takes more than a few months to recover to the point where mining activity picks up enough that the next 2016 blocks get mined in a reasonably short amount of time.  Also, I don't think it would ever be the case for very long that the electricity cost of mining a block is equivalent to the value of the reward/fees for a block.  If that were the case, then mining would be a money losing proposition due to the hardware costs.  And, you have to factor in new generations of hardware that would increase efficiency and hence lower the cost of mining (thus inducing people to invest in new hardware and resume mining). 

But, it does raise interesting questions.  I'm not sure why it couldn't be made such that the difficultly adjustment happened more frequently (say every 100 blocks), or be triggered based on thresholds set on a moving average of the block creation rate (i.e. if the average rate of block creation for the last 100 blocks is <5min or >15min, re-adjust the difficulty).

What does "global mental design" mean?  I didn't mean to imply that he may have spent several years coding...designing a good system often involves a lot more than actual coding.  I suspect the creation process was several years in the making even if the actual coding was relatively quick.

I believe Satoshi was working on this idea for quite a while...looking at the code, I don't think this was something he threw together in a couple months.  I think he may have been working on it for several years and took great pains to ensure it was sufficiently evolved such that it wouldn't simply die shortly after its release.

Maybe the best approach would be to find a small local bank to partner with to issue a bitcoin backed debit card.  If someone knows an executive at such a bank, it might be worth talking to them about it.  I imagine you could issue at least a few hundred such cards right off the bat.