I think you should count only marginal CPU usage. If someone runs the bitcoin program, the computer is running regardless there are transactions or not. I have no idea what additional power usage is drawn by such a short calculation but much lower than 300W. I would guess 50W or less since the CPU will likely be in a low clock powersaving mode. It makes it less than $0.0002

3 ms sounds like a long time, on what hardware is that?

I agree.  However, at this point "we" have to decide what the default rules are, and what is decided now will influence what people think is "fair" two years from now (when, hopefully, bitcoin is in the process of becoming wildly successful).

Also, I've read a couple of popular behavioral economics books (e.g. Predictably Irrational), and I think there might be some irrationality that could make bitcoin more successful.  For example, "free" is a magical number.  If we can make most bitcoin transactions "free" to the typical user, then that's a huge selling point.

There ARE hidden costs; the reason I want to do the back-of-the-envelope is to figure out how big those hidden costs are now and how big they're likely to get in the future.  It isn't rational, but most people would rather have "free transactions", even if they end up paying 10 cents more in electricity costs every month whether or not they actually make any transactions.

(I may move this to the Economics topic depending on where the discussion goes)

Thanks Hal!

If I had a cluster of bitcoin transaction processing nodes (or a big mining farm), I'd connect them with memcache and store transaction hashes/verified flag pairs, so signatures were verified once.  Or maybe just have one machine filter transaction/block traffic and only pass along valid transactions/blocks, and not have the rest of the machines even bother checking signatures.

It will be tougher for individual nodes.  If they're not mining, they could just check signatures ONLY on somebody-sent-to-them transactions.  

If they are mining... well, it seems to me  single-node miners will become increasingly rare as bitcoin scales up.  Hardware farms or miners using a mining pool seem like the way of the future.

Totally agree that we want fees to be zero for as long as possible (or forever).

What I had in mind is that when network load is not reaching capacity, transactions would be free. If nodes start struggling to keep up, they'd begin charging fees to make things expensive for spammers/attackers. Once load lowered again, fees would drop back to zero. If nodes were upgraded and got extra capacity, the fees for that node would drop to zero again.

This assumes a world in the only purpose of fees is as an anti-DoS measure. If/when fees become the primary economic incentive to mine, well, hopefully at that point mining will be cheap and competitive enough that fees would still be extremely low on a per-tx basis (tiny fees for lots of transactions can add up to a thin margin on top of expenses).

I think there are really two problems here:

1) what should the fees be (continuing to be zero would be best)

and

2) if they do need to be raised at some point, eg to handle a transient DoS attack, how do you communicate that to real users so they know how much of a fee to include?

Also, how do you do that in a fast way such that an attacker can't take out the network quickly. Block based consensus feels intuitively too slow. Imagine how disruptive a 20 minute outage of VISA or MasterCard would be. I actually never heard of such a thing, probably these companies put a lot of effort into reliability and I know they are way overprovisioned to withstand temporary load spikes .... and they don't have the issue of accepting transactions from just anyone.

I'm not sure what the answers are though. Will ponder some more this weekend.

I just read back some of the old threads. It seems Gavin has already got the DoS problem figured out and I just hadn't encountered the solutions in the source code (or they aren't implemented yet).

One thing I'm not sure about is the interaction of all Gavins ideas. Having nodes not check signatures on coins that aren't sent to them frees up a lot of CPU time across the network and means you could relay thousands of transactions per second on good hardware instead of just 100-200. Ordering transactions by priority and refusing to relay low priority transactions when a node starts running out of capacity means "real" transactions would probably not suffer.

But if you aren't verifying signatures then that means I can send transactions into the network that aren't valid (the signature is random garbage) but reference old coins I don't own, thus artificially boosting my priority. Other nodes will happily relay my high priority but invalid transactions through the network leading to huge amounts of spam travelling around. It just replaces CPU exhaustion with RAM and network exhaustion.

Anyway, I think I'm still confused about the different types of fees so maybe not really helping this thread. They are used both as an anti-spam system and to encourage miners in later years when fewer coins are minted per block. I'm not sure what we're trying to calculate the cost of a transaction for ... I guess it's actually the latter case.

But you don't have to backup the blocks. Just your wallet. And for wallet.dat size it does not matter how many transactions got attached to the blocks.