The market doesn't work like that.  The free market involves parties reaching an equilibrium.  "too expensive, therefore collapse" is not a realistic scenario depicting an open market adjusting to costs.

Most 0.00000001 outputs pay a fee, which exempts them from the priority system.  Priority is used for calculating how to fill the ~27k free transaction area, in the absence of a fee bidding for the non-free block space.

Yes.

Had to power-cycle the miner at uptime 1 day, 21 hours.  cgminer was responding, but no mining work was going upstream to the pool.  The 'hardware errors' count was increasing rapidly.

A more relevant measure than space in the block chain is the size of the list of unspent transaction outputs ("UTXO", list of spendable bitcoins).  It keeps growing and growing, with near-zero-value outputs.

RE "who cares what the values are"  One follows from the other.

If your purchases are typically 4-5 decimal places at most, and the remainder has sub-$0.001 value, the remainder is simply less likely to be swept up and spent... thereby taking up space in the block chain without being prunable.

This is why losing SatoshiDICE bets are so harmful to the system.  You get back 0.00000001 or so on a losing bet.  With such high transaction volumes, SatoshiDICE is handing out lots of difficult-to-spend dust spam.

I read your post sufficiently to note that you do not understand the concept of a hard fork, if you think we've already had one.

Even the combined output overflow bug fix, which lead to the longest chain fork in bitcoin history, cannot be considered a hard fork.  Vulnerable clients were able to remain on the network, after the bug was "healed."  This would not be the case in a hard fork.

And the answer is... today!

Wrong.  Mining a side chain for a small amount of time is not a hard fork.

A hard fork is where it is impossible for older clients to continue with the new bitcoin, without a software upgrade, because they would find some post-fork detail invalid (when it should be considered valid).

We still have many older clients on the network, verifying the chain.

Just a coincidence.  ASIC miners are rapidly coming online, which increases block production until difficulty changes to compensate.

It is crucial to understand the concept and, yes, economic impact of a hard fork before even approaching the economic analysis of changing the max block size.

A hard fork is a significant event that knocks legitimate users off the network, makes coins unspendable, or potentially makes the same coins spendable in two different locations, depending on whether or not you're talking to an updated node.

It is, to pick a dramatic term, an Extinction Level Event.  If done poorly, a hard fork could make it impossible for reasonable merchants to trust the bitcoins they receive, the very foundation of their economic value.

Furthermore, a hard fork is akin to a Constitutional Convention:  a hard fork implies the ability to rewrite the ground rules of bitcoin, be it block size, 21M limit, SHA256 hash, or other hard-baked behavior.  Thus, there is always the risk of unpredictable miners, users and devs changing more than just the block size precisely because it makes the most engineering sense to change other hard-to-change features at the time of hard-fork.

It is a nuclear option with widespread economic consequences for all bitcoin users.

* "the devs" do not even agree amongst themselves

* There is no immediate need to change the block size (as you point out), only a perceived, debatable future need.

* Until that point happens, it is impossible to know what is a happy medium.  And how will we know that happy medium?  The free market and user choice will decide, not some cabal of miners or devs.

It is entirely within the realm of possibility that the userbase would refuse to change the block size.  It is inevitable that some users will indeed refuse to upgrade, thereby rejecting all (in their opinion) oversized blocks, thereby creating that most undesirable of outcomes, the long-lived chain fork.

Will a majority endorse the block size change, or refuse?  An unanswerable engineering question, for the moment.  And given the present lack of need for a hard forking change, there is not much point in speculation.

Updated firmware seems pretty happy.  No long-run data yet, as I've had to turn it off for reasons unrelated to mining (moving gear around etc.)

Well, besides the bbs.<some.China.site> pictures posted, a random Chinese guy emailed me, requesting the firmware image Yifu sent me.

So, it sounds like some units are arriving at their Chinese destinations, at least.

I'm glad you asked

Being the person who actually posted a faux-patch increasing the block size limit, it is important to understand why I disagree with that now...  it was erroneously assuming that the block size was the whole-picture, and not a simple, lower layer solution in a bigger picture.

The block size is an intentionally limited economic resource, just like the 21,000,000-bitcoin limit.

Changing that vastly degrades the economics surrounding bitcoin, creating many negative incentives.

Sigh, they need to do more research.

Transaction rates can easily scale far beyond 7 tps, even with 1MB limit in place.

The current network is just the base settlement layer.

Many organizations will layer instant payment networks, settlement networks, credit layers and other things on top of the current layer.

Anybody who looks at the current technology and assumes "that's all there is" or "the whole world is limited to the current network" makes fatally flawed assumptions.

Satoshi openly acknowledged this by noting insuitability of microtransactions for the current network, and it is clear that digitally signed messages may be sent, exchanged, combined by a myriad different payment processors, aggregators etc.

"already controversy is brewing"  Wonderful zero-evidence hypothetical BS handwaving there.  Yes, controversy is brewing... among those teenagers clueless about bitcoin and economics.

Bitcoin value and press reports indicate new bitcoin users and businesses every day.  The exact opposite of "back away"

No.  You need to wait 100-120 blocks before you may spend a coinbase output.

Several larger pools are running 0.8 or almost-0.8.  Largely stock software (with maybe a patch to filter out SatoshiDICE transactions here and there).

This script is used to generate bootstrap.dat:
https://github.com/jgarzik/pynode/blob/master/mkbootstrap.py

It requires an up-to-date pynode chain database.

In theory, someone could write a script that processes bitcoind's $DATADIR/blocks directory into bootstrap.dat, but no one has written that yet.

Ideal for those who want a UI is simply to write an add-on utility or plugin that uses the RPC API.