Resources have a real (fiat currency) cost.  Just like fiat currencies or gold or diamonds have to be securely stored, insured, etc, bitcoin has a real cost in order to keep the bitcoin network running smoothly.

Most regular bitcoin users are familiar with the recent exponential increase in blockchain size.  When I first downloaded bitcoin about 3 weeks ago, it was just over 1.2GB.  It is already at 2.7GB and rising quickly.  Arguments have been made that suggest that hard drive space is cheap so it won't be a problem.  Offline hard drive space is cheap, but 'cloud' or dedicated internet accessible hard drive space is still a bit pricey, depending on the service provider, location, amount of space, etc.  My windows 2008 R2 64 bit VPS which is guaranteed 100% uptime in a major USA backbone is appx $40/mo and I only get 30GB (16GB used by windows install alone). I have appx 40-60 active connections at any given time, although unfortunately the client does not keep track of how many confirmations my node has done.  The original bitcoin client is actually lacking in a lot of advanced statistics to give the user an idea of what their node has accomplished or is currently processing.

Regardless, whether dedicated or a casual user, the full blockchain is taking up too much hard drive space, especially considering there is no compensation (that I can see in the original client) for hosting the node.  I should have a right to reject to confirm a transaction that does not have a certain percentage of the original transaction as a fee.  Making the transactions 'free', no matter how small will attract a certain type of undesirable user (freeloader).  In fact, i was imagining that a certain type of 'bloat blockchain attack' could be done where a huge number of microspends could be done on an automated basis to make the blockchain very bloated and therefore inaccessible to those nodes without the hard drive space or bandwidth.

Potential solutions: 
- allow blockchain to be divided up into xx MB/GB file sizes.  Consider using compression for older portions of the blockchain.
- Allow node to customize how much of the blockchain the node will confirm.  Either in days from present day (past xx days) or in number of transactions from the most current block.   So 'supernodes' can hold the entire blockchain, while 'small business nodes' may only keep 6 months worth, and a casual user only needs maybe 4-6 weeks.

Perhaps there would be increased transaction (research fee) to confirm older transactions.  The real cost of storage is directly proportional to the length of the blockchain.  Wouldn't older transactions be further back on the blockchain?

- find a way to shrink/summarize older transactions so that only a minimum amount of information is needed for the blockchain.
- consider expiration date for accounts with no activity or something similar.  Like a gift card or anything else of stored value, there needs to be minimum activity to keep up with changes.  The bitcoin client will need to evolve and cannot always be concerned with having to maintain older clients
- A minimum per transaction fee of 1000th (0.1%) of the total transaction size, (or the smallest BTC denomination, whichever is larger) charged to the sender at the time of sending.  That's 0.1% transaction fee; unheard of in credit card processing.  The transaction fee can be divided up evenly amongst the first 6 confirming nodes.
- allow node to reject transactions that do not have a certain % fee of transaction.
- allow return to sender option if wallet does not receive/confirm a transaction after xx minutes.  Default can be 3 days but perhaps adjustable to up to 7 days or so.  We don't want too many unconfirmed/stale transactions floating around.
- bonus: allow an optional checkmark to donate 0.1% of the total transaction size to bitcoin client developer address to assist with future development.  When this is in the client, people are more likely to actually participate in it.  Maybe even type a short thank you note or suggestion.

If a transaction is 'confirmed' x number of times, is there still a reason to keep the original record past a certain amount of future transactions count (or n many months)?  We would have to give the receiver some responsibility in checking their wallets/transaction history, similar to how the bank account statement would be checked by the customer to ensure no errors. 

If you think about it.  Even banks only keep so many transactions in their current database before storing them offline or historical database.  Then for these older transactions, a "research fee" must be paid to look up the transaction.  After so many days, months, or years, the the historical data may even be destroyed, as it is no longer relevant.  Once the transaction is fully confirmed in the receiver's account, there's no need to hold on to that past data for any extended period of time (otherwise, what's the true purpose of confirmation?).  Perhaps there should be a 'return to sender' and the receiver has x number of days to claim their funds (3 days?) or else it is returned to sender.  If there is no sender address, do the bitcoins get distroyed? Or evenly distributed to a random number of confirming nodes (for doing the work of having to confirm the transaction).
The fundamental idea here is that the receiver will be keeping track of their transactions on a regular basis, which would require that you be in communication with the sender. 

Bitcoin need to mature out of the "hobby" mindset in order to truly be accepted and integrated into the business world, which is what bitcoin is primarily intended for (settling agreements rapidly between 2 or more parties). Being scalable on paper is not good enough.  Some of these things need to be done from the original client.  People do have other things to do with their hard drive space, especially in the cloud.

I woke up today and had all these thoughts about bitcoin and felt the need to express them.  Not sure how much longer I can be a free node.