Couple of thoughts: RE: the marvelous coincidence that the average fee these days is very close to the modeled minimum orphan cost: Engineers tend to underestimate the power of markets, even inefficient markets, to arrive at the 'correct' price. It would not surprise me at all if the messy, chaotic inefficient market with tens of thousands of individual decisions ("which mining pool should I join" and "how high should my dice site set fees" and "how large should the minimum payout be" and "should I make my blocks bigger or smaller") might arrive at the 'correct' price, even if NOBODY involved has any clue how or why it happened. Or it might just be a coincidence. RE: orphan rate: The network-wide orphan rate has been very steady apart from the March blockchain fork. Kudos to Ben Reeves for keeping track of the data and giving us a nice chart: http://blockchain.info/charts/n-orphaned-blocks RE: new block latency: We should be able to reduce the size of new block announcements by about a factor of ten with very little additional effort (transmit/relay as "merkleblock" with full bloom filters-- the factor of 10 is because a transaction id hash is 32 bytes, average transaction size is a few hundred bytes). Mining revenue is a fixed-size pie, so if EVERYBODY agreed to accept (somewhat) higher orphan rates for more transaction volume then, in the long run, there is no difference. Well, except that more transaction volume means more utility for Bitcoin as a whole, so everybody should benefit from a higher bitcoin price. That's a classic free-rider problem, though-- a miner could defect to try to get a lower orphan rate. This is one of the reasons why I think relaying all blocks in a race is probably the right thing to do; if a miner is mildly punished (by losing the occasional block race) for creating blocks that don't include "enough" already-relayed transactions, that is a strong incentive to go along with whatever consensus has been established. The same argument applies for a miner producing too-large blocks, or blocks with lots of transactions that were never relayed across the network. -- -- Gavin Andresen