You could think of P2P client systems, to the bitcoin network that would take care of small transactions and even make them faster, also using some sort of blockchains, though sort of compressing them in the actual chain, for a fee.
Hell, if you think about it, you can even involve mining there, as long as it gets cheaper than the bitcoin chain fees.
Just leave the 1MB block limit and you will see it bloomig (good for everyone), while the actual bitcoin network will be able to breath out.

Besides, IMO it's also too dangerous to change anything in this protocol.

For reference, when talking about "off-chain transactions" are we talking about Rapidly-adjust (micro)payments?  I would guess so, but just making sure.

Sure, off-chain transactions can replace a lot of the bulk of the blockchain, but there will still clearly be more than 7 tps between previously-unrelated parties if Bitcoin is going to scale to the levels it needs to.  Not to mention, that the RA(M)P referenced above does require two transactions per pair of parties, and needs to be renewed at some regular interval. 

Micro-payment channels and their distant cousin probabilistic coinbase txout payments are useful, but they are really just a particularly efficient form of on-chain transaction.

Off-chain really refers to systems where the transaction never has to see the blockchain at all, ranging from really simple stuff like Easywallet account-to-account transfers (and SilkRoad for that matter) to advanced solutions like fidelity-bonded payment systems and trusted computing hardware where the trust in any third party is minimal.

Speaking of scale, we know that at some level Bitcoin just can't be decentralized and still have every transaction on the blockchain - you just have to read the wiki page on Scalability to see how VISA-level volumes require a system that's hardly decentralized, let alone resistant to government control. We've already had to ban sub-cent microtransactions from P2P network in the 0.8.2 client due to scaling concerns - I'd rather see Bitcoin develop into a system where we don't have to make ugly decisions like that again.

Here's an interesting thing I just conjured up:  From a doc 'UnitedStatesComp.pdf'


To save one the math, I get about 5 tps.

Seems to me truly a no-brainer to consider various forms of off-chain transactions vs. trying to shove everything onto the blockchain.  Even with 'ultra-prune'.  The only real question is when.  A median of $25k and average of $3.5M is pretty alarming...though we are talking about $380T here...  It cannot be said that I am not a 'USD user' by virtue of the fact that I've never performed a Fedwire transaction.  The same would stand for Bitcoin.

If the 'source of truth' for values is stored on 1,000,000 power-users computers distributed around the world (and processed by the same) vs. in some computer system owned by the federal reserve (or BIS or whatever) that is a pretty revolutionary thing.  If the same basic solution consists of Google and Facebook, or even a few thousand DWolla-sized entities, that is a much less compelling to me.

Ultimately, I think the appropriate factor to weigh most heavily in a decision about data rate is what, exactly, is required to protect against which particular threats.  Various economic factors will certainly play important roles in this equation, but I truly believe that they should be secondary.  This because resistance to attack will ultimately define the value of the solution in my opinion.

It just feels stupid that you send some one a coin and he send you a coin back and you need two transactions broadcasted just for nothing happened in reality

The book keeping method is a common practice in accounting, it reduce the real transaction in financial system. If you have lots of bitcoin nodes that transfer bitcoins between each other, the real amount of transaction on the blockchain will be very small and the nodes just need to broadcast the net incoming or outgoing transactions

BTW, I think today most of the transactions are just pools paying miners, that can be dramatically reduced by reduce the pay out frequency  

Reason being... oh wait there is none.

its not just about 56k modems. its also about people being able to mine through tor. you could not mine 30mb blocks throug tor.

Virtually every bitcoin user already uses third parties, and trusts them to some extent.  Doing so is a trade, cost for risk.  In the future, I expect it to be even more complicated.  Imagine a credit card denominated in bitcoin.  With that, you'd be paying for them to assume transaction risk for you, while right now the model is mostly the opposite with you getting a discount for assuming the risk that the third party may bail with your bitcoins.

Every bitcoin transaction has a cost associated with it, and we don't have a very good idea at all what that cost really is.  The mad scientist in me thinks that we should wait until the 1 MB limit is met and sustained for a while before we raise it.  That way we'd get some real world experience with how the system (including the people!) react.  Hopefully, that would lead to a better understanding of the forces that will eventually drive the equilibrium.

Bitcoin by design is meant to be decentralized, p2p e-cash solution for as much people as technologically possible^{satoshi paper}. As DeathAndTaxes noted, keeping 1MB is not good for decentralization, let alone accessibility.  IMHO peter's video claiming that increasing size from 1 to 10MB will lead to centralization and allow microtx's, is misleading.

Bitcoin is not meant to be for early adopters (like me) who are now shitting in their pants, worrying about any change. Change that can make it potentially more difficult to e.g. hide the traffic. Though there is a potential market for something like torcoin (paracoin), it's not what >90% bitcoin users (miners) would want to have; at least under present circumstances.

All in all, I believe that blocksize should be adjusted such that if it is < 100MB, tx fee should be <=$1.

thats not true. 10mb can likely be sustained virtually forever. both bandwidth and storage space grow fast enough to handle this.