Start here for possible holes:
  http://scholar.google.com/scholar?q=%22mix+networks%22

The current plan is to password-protect private keys in the wallet and unlock them when coins are sent (with an option to 'remember the password' for a certain period of time) for the 0.4 release.

That doesn't completely fix the problem (a keystroke logger can get your password, and a virus can insert itself so instead of sending 10 BTC to your grandma in Boise it makes bitcoin send your entire wallet balance to Little Bobby Blackhat).

To almost completely fix the problem transactions would need to be created on one device and then verified on a second device.  Assuming both devices aren't infected/compromised, that will be safe. The two devices would be your computer and something else-- maybe a website, If anybody has experience with that type of cross-device security/programming and is interested in helping Bitcoin out, help would be much appreciated.

Technical growing pains like the ones we're dealing with right now-- IRC channel filling up so new people are having trouble connecting, BTC/$ going up so the 0.01BTC transaction fees are too high, etc.  There will be more of these as transaction volume increases, some in the core bitcoin code and more affecting bitcoin-running websites (who will find they have to upgrade their servers to handle increased volume/users, etc).

Legal growing pains.  I expect somebody doing something illegal and using bitcoins to help do it will get caught, put in jail, and that will be mis-reported as "bitcoins are illegal!"  I'd say there's a 1 in 5 chance of bitcoin being made outright illegal in the USA, but I also know that I'm terrible at accurately predicting stuff.

Security growing pains. My biggest worry is what to do about non-technologically-savvy people running bitcoin on a virus-infested personal computer or mobile phone and losing all their bitcoins the first time they enter their password (I'm assuming their wallet will be password-protected) to send a couple coins to their friend.

And just plain new-technology growing pains. Expect some (maybe most) bitcoin-related companies to fail, because most startups fail. Some people will lose money when they do.

Again, I'm optimistic because there are, and will be, lots of motivated people working to solve all of these problems, and because I believe the core technology is solid. But I don't expect smooth sailing.

If I worked at AMD, I'd suggest that.

I started my professional career at SGI, writing 3D graphics demos and benchmarks, some of which were used to "burn in" the new hardware.  Running a bitcoin miner along with a couple graphics demos (to exercise all the graphics hardware) might be a good way for ATI to make money on their burn-in process.

I'm optimistic about bitcoin because of two metrics:

1. Lots of people are interested in it, all over the world.

2. There are lots of interesting, innovative projects being built around bitcoin.

It is still VERY early days, and I'll say it again:  expect growing pains.

A huge block-chain re-org on the testnet confused the heck out of the testnet faucet (leaving it with lots of 0-confirmation, used-to-be-valid sends that made it think it had a negative balance).

Clearing its wallet of the 0-confirmation transaction fixed it, but left it with a very small balance.  It is up and running (at https://testnet.freebitcoins.appspot.com/ ), but if you generated a bunch of testnet coins, please send some to the testnet faucet at miGuMc6qtVEKS6Pf1jKddaa81DeHjMzkpB .

Also, for anybody who doesn't know about it already:  I've been using testnet-in-a-box (thanks Mike!) very successfully for testing.  It gives you a nice, well-defined, controlled environment for reproducing bugs.  Get it from:
  http://sourceforge.net/projects/bitcoin/files/Bitcoin/testnet-in-a-box/

Diversifying is a good strategy.

I wouldn't trust that an Internet cafe computer was safe; if I were you, I might buy some bitbills ( bitbills.com ) and have them mailed to your home address.  I ordered some bitbills shortly before I left for France and the mailman delivered them to me with the rest of my held mail when I got home.

What theymos said.  There's another thread about this, too, and I'll ask here what I asked there:  what is the use case for an 'estimate transaction fee' function? What if the estimate is wrong, what would your application do?

Depends on your definition of "micropayment".  Bitcoin is not suitable for transactions of less than a US penny, because of its fixed costs of processing transactions.

Yes, diversity is good. If you do decide to go for it, do lots of testing on either the test network or with a testnet-in-a-box setup before even THINKING about handling real bitcoins. If you screw up and lose other people's money it will take a long time to earn back their trust.

Oh, and speaking of trust... unless you have a recognized Brand Name, I don't think you'll have any success with a closed-source client.

I flagged it as scams/fraud.

It'll be interesting to see if scammers/fraudsters manage to pull off many "big scores" -- in the age of instant Internet feedback and crowdsourced self-policing, it might be tough.

I fixed ClearCoin (restarted the bitcoind daemon) as soon as I got home; I apologize again for the service interruption.  I can't yet promise it won't happen again-- I'm still a single point of failure for ClearCoin.  But I'm working on changing that.

I split this topic from the Public Relations thread.  Apologies for any mistakes I made selecting which posts to split.

For the record:  I think a main block chain reset is a terrible idea.

Bitcoin isn't suited for transactions worth less than about one US penny-- it wasn't designed or intended for lots of micro-transactions.

That said, building a micro-transaction system on top of bitcoin is certainly possibly (see witcoin or youtipit for some examples-- or see the way the Bitcoin Faucet is handling payments recently, bundling up lots of small transactions to send them without paying outrageous fees).

Sounds like this is good for pool operators that have high 'getwork' loads-- have any high-volume merchants sites or e-wallet sites tried it?

I've got a long list of things to do when I get back from vacation week after next, or I'd volunteer to run it on the Faucet to help stress test it.

Huh?  That's backwards, transaction fees are smaller (as a percentage) if you're sending more BTC.  Number of bitcoins being sent doesn't matter, number of inputs and outputs to the transaction matters.

RE: estimating fees beforehand:  what is the use case where that is actually useful?  What do you want the user experience to be?
And what happens if the estimate turns out to be wrong?

June 14th at CIA HQ, Langley Virginia.  It is not open to the public, conference is for the US intelligence community only.

If only the FAQ was a wiki that anybody could edit, then thedrs could add it him or herself...

(hey, wait a minute!  it IS a wiki!)

Released, transaction id fe5ee70feac0db3963d20fa746257ec18fec7379f90ca6a1ef4c1df564c6e413

I'm still not sure why they didn't release automatically; they should have.  Debugging the problem fully will have to wait until I am back home on my main development machine.  If anybody else has the same problem, send me an email and I'll fix it ASAP.

If the network was split 50/50, then each half would generate blocks half as fast.  So it would take 34 hours.

For an "Egypt splits off from the rest of the network" scenario, it would probably split something like "less than 5% generated in Egypt, 95% rest of the world" in which case it would take 17/.05 = over two weeks for the blocks generated in Egypt to mature.