No, there's no way.

No, they're always mixed.

If you're worried about a "fund account with tiny bitcoins" attack, you should charge users that fund accounts with gazillions of tiny transactions an "excess account activity fee."  I've been thinking about writing code for ClearCoin that does that, but at least so far it doesn't make sense for me to spend time doing that.

And see:  https://github.com/bitcoin/bitcoin/pull/285   for the current thinking on how to handle fees at sending time.

40 cents per visitor is definitely too much; I've set the Faucet to "down for maintenance" again, and will keep it that way until two things happen:

1. I change the amount awarded.
  and
2. bitcoin version 0.3.23 is released with lowered fees, so people can actually SPEND the bitcoins they get from the faucet.

Really?  I've been encouraging alternative implementations, who is the power-hungry core developer?
Ok.  Start here:  https://github.com/bitcoin/netspec
Or here: https://en.bitcoin.it/wiki/Category:Technical

If it is any consolation, I made the same mistake a few days ago (and am still waiting for the 25 BTC to appear in my account...)

I wrote a blog post about this:
  http://gavinthink.blogspot.com/2011/06/but-you-can-use-it-to-buy-drugs.html

Exactly right. I will to do what I can to help the police catch scammers and crooks who want to steal from people.  The police might use those same tools and techniques to help catch people who use bitcoin to pay for drugs; I can't stop them from doing that.

I personally don't think drugs or gambling should be illegal, because I believe you should be free to do whatever you like with your own body and your own money. But I also believe those are separate issues from bitcoin, and if I felt really strongly about it (it isn't one of my own personal hot-button issues) I would be donating money to, or volunteering to work for LEAP and NORML, not mixing "bitcoin is a great new technology" with "drugs should be legal."

Really?  The testnet faucet didn't get them.

By the way: what's going on with the testnet?  Is/was somebody playing around with "I've got more than 50% of the hashing power" attacks?

Ian:

Great letter! I agree that the "stop campaigning for bitcoin's destruction" message might backfire, and the message should be "we're an innocent bystander here." You might even offer to help law enforcement better understand bitcoin so they can develop tools and techniques to catch criminals who use it.


I've been thinking of how to react to this story, and am tempted to appeal to people's greed/fear with a message of "your country may miss out on a huge new opportunity and be left behind if you try to stamp out innovative new technologies like bitcoin."

My mistake; I didn't test some new code thoroughly enough.  Fixed now.

First, don't sudo; there is no reason for bitcoin to run as root.

Second:  it isn't done downloading the block chain.  I just checked a bitcoind I've got running on an Amazon micro instance, and it is using less than 1% of the CPU.  After you've got all 128,909 blocks the CPU usage should drop.

Well... they COULD get punished for failing to relay.  Just drop/ban them if they're not sending you "enough" valid transactions.

RE: Fee sheet:  won't work, miners will lie to get higher fees.

RE: analyzing previous blocks to determine fees:  I think it could work. Keeping track of how long transactions take to get into a block and looking at what transactions are in past blocks would, I think, work pretty well.  Until/unless the criteria for including transactions gets really complicated.  And new clients that haven't seen many transactions (and so can't tell how long prior transactions had to wait before being included in a block) might be an issue.

When we have multiple client implementations one of the ways I imagine they'll compete is to have smarter calculate-the-optimal-fee algorithms ("Use SpiffyBits(tm) and pay 2% lower transaction fees than the original bitcoin client!").

RE: hashcash for transactions:  that is exactly equivalent to fees (because you could be hashing to earn block rewards instead of hashing to get your transactions accepted).

RE: limiting number of small/free transactions that can go through a node in a given timespan:  we're already doing that.

RE: canceling transactions:  are there really people who would rather have their transaction tied up for half a day because they don't want to pay a half-a-penny fee?

RE: randomly dropping low-priority txns: interesting idea. I've been thinking that dropping the connection to a peer that is sending you "too many" low-priority transactions might be a good idea (where "too many" is maybe N standard deviations away from the number your average peer is sending you... or something....)

No, because you're probably not directly connected to those pools, and the nodes you are connected to will drop transactions if they don't include the 'right' fee.

Bitcoin already supports showing and sending less-than-0.01 BTC amounts.  It is just smart and only shows 2 decimal places instead of always showing lots of extra zeroes.

It costs the bitcoin network something like 0.001 US cents to process a typical transaction, so transactions less than about a cent don't make sense.

RE: using market forces for transaction fees:  I agree 100%.   But that code has to be written and thoroughly tested.  The hard part is figuring out how miners communicate their "fee schedules" to clients (you can't just ask miners "what's your fee schedule" because they have an incentive to lie to try to get higher fees...).

So in the very short term fees are being dropped from 0.01 BTC per kilobyte to 0.0005 BTC per kilobyte.

I'll say it again:  expect more growing pains like this.  There will be more of them.

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.