Separate of the blocksize issue - fundamentally I don't think the network should run on the back of transaction fees. The benefit of a high hashrate (a secure network) isn't limited only to those actively transferring money. Anyone who holds Bitcoin has a stake in the network.
Everyone also benefits from high scalability of transaction processing, so ideally transaction fees should stay low or zero. I don't accept the idea of meta-currency (alt-currencies and sidechains) to rectify this situation - too much risk when you have a known quantity that works pretty OK. It also decreases security by splitting processing power. If the problem is that it doesn't scale well, fix it, don't replace it. Joel on Programming's #1 Thing You Should Never Do: start over from scratch.
It's impossible to maintain the massive amount of processing power spent on this solely through transaction fees. Block rewards effectively socialize this collective interest in network security though a very low level of inflation, which hits the right population (Bitcoin holders as a whole). To me transaction fees should be nothing more than spam prevention, to prevent a DOS attack from clogging up the transaction blocks.
Really there's no reason you couldn't have an arbitrarily-large transaction block as long as the bandwidth is reasonable. You still have the problem of the chain becoming too great in size, but that's a problem with some pretty obvious answers.
$1.63 per transaction rules out the possibility of microtransactions. I personally don't think that anyone has the moral authority to deem a use-case "wrong" for a currency. You need to support transactions involving pocket change just as well as you support transactions in benjamins to see wide acceptance.
Such high transaction fees effectively make the currency indivisible to a substantial degree. Sure you can send someone a penny, but if it costs $1.63 most people won't. So that sets a very high minimum floor before people will consider using it in a transaction. Note that this is different from transaction service fees - yes, some places have minimums for CCs, but it doesn't cost me anything to hand you a penny, or even to send you a check for a penny.
The answer to blockchain size is - sidechains, actually. What I have a problem with is meta-currency - the idea that you must necessarily transfer to a separate currency or trust a third party to perform day-to-day transactions. That creates independent currencies with their own security risks, and divides the hashrate into individual pools which are more easily attacked.
Instead what I want are sidechains that compress a series of transactions. You never actually trade on a sidechain, but at some trigger event or time interval a series of transactions is brought onto a sidechain and reduced to a net-sum of inputs and outputs, then instantly reattached to the main blockchain as a single net transaction. You can call this checkpointing or whatever you like, but it doesn't need to be (and shouldn't be) all of the transactions on the blockchain, or even the most recent transactions that are sidechained. In fact I think it makes the most sense for it to be the oldest, say the oldest week of transactions (targeted) within a rolling 28 day window. Long enough to make attacks difficult, short enough it's not too large on disk.
You essentially rebase the blockchain onto a new squashed changeset. This transaction also includes the original hash of the transaction that used to be there, so the chain still validates properly, and the hash of the last confirmed regular block, so it can be strictly sequenced. Everyone validates the squashblock to be sure that it tallies properly and hashes correctly, and if it doesn't reach consensus it's not accepted. If accepted, the next regular/squashblock must include the hash of the squashblock to indicate acceptance.
Still doesn't solve the problem of dust taking up space, but it solves most of the problem. Or maybe sweeping dust is part of the reward for the squashblock somehow. I do like the idea that if you don't sweep your ha'pennies they fall into the couch cushion. Maybe you'd implement that like "any dust that hasn't moved in a block before the squashblock is confirmed may be arbitrarily moved", so dust older than a month (average) is swept.
Why does the penny transaction have to confirm in 10 mins? Currently, and for at least a couple of years, you will likely still be able to send 0 fee transactions. The time for them to appear in a block will increase however.
Everyone also benefits from high scalability of transaction processing, so ideally transaction fees should stay low or zero. I don't accept the idea of meta-currency (alt-currencies and sidechains) to rectify this situation - too much risk when you have a known quantity that works pretty OK. It also decreases security by splitting processing power. If the problem is that it doesn't scale well, fix it, don't replace it. Joel on Programming's #1 Thing You Should Never Do: start over from scratch.
It's impossible to maintain the massive amount of processing power spent on this solely through transaction fees. Block rewards effectively socialize this collective interest in network security though a very low level of inflation, which hits the right population (Bitcoin holders as a whole). To me transaction fees should be nothing more than spam prevention, to prevent a DOS attack from clogging up the transaction blocks.
Really there's no reason you couldn't have an arbitrarily-large transaction block as long as the bandwidth is reasonable. You still have the problem of the chain becoming too great in size, but that's a problem with some pretty obvious answers.