Quote from: thepianoguy on September 23, 2014, 07:24:06 AM

What if we assume micropayments are flying around for one coffee per 100ms? How big becomes the blockchain then? The average transaction size is ~80 KB, for 6000 transactions/10min that makes it 4.8 MB per block equals 262 GB per year. IMO, that's still feasible. But I assume the devs could beat the size of the transaction down to 10 KB or even less, if that were the case.

The problem is not really about the storage of the blockchain (hard disk are "cheap", blockchain could be pruned, ...) but is more about the growth of the UTXOs set and the memory pool (which require RAM). Bandwidth and transactions/blocks processing (CPU) are additional factors.

Quote from: thepianoguy on September 23, 2014, 07:24:06 AM

Is there a problem with the network congestion? IMO, no. After all, the bitcoin protocol is distributed, so the busy nodes are processing some transactions and the free nodes then take care of the others. After a while when the morning coffee spike ends, the network synchronizes in a, say the diameter of the network, steps.
Am I missing something?

The bitcoin protocol requires a consensus among participating nodes. Full nodes need to process transactions and blocks to reach this consensus. Delaying this processing would increase the number of forks in the blockchain (network split). I guess we can say that micropayments channels are another way to implement this idea of a delayed processing (after clearing and aggregation of transactions).

It should be interesting to see how IBM works out this subject with its concept of a blockchain for IoT since IoT seems a good candidate to produce a bunch of micro-transactions.