...
The user can choose what fee they pay in Bitcoin, it depends how fast one wants to have their money sent. And some amounts are too small to be sent, even with the smallest fee (as in the 1,520% fee example above). All decentralised cryptocurrencies have this problem, real blockchains (Ethereum is not a decentralised blockchain) have limited on-chain resources.
The known solutions are:
1. Abstract the transactions away into a different protocol layer (i.e. off-chain payment channel networks)
2. Improve the scalability of transaction verification to increase the capacity of the on-chain protocol layer
The user can choose what fee they pay in Bitcoin, it depends how fast one wants to have their money sent. And some amounts are too small to be sent, even with the smallest fee (as in the 1,520% fee example above). All decentralised cryptocurrencies have this problem, real blockchains (Ethereum is not a decentralised blockchain) have limited on-chain resources.
The known solutions are:
1. Abstract the transactions away into a different protocol layer (i.e. off-chain payment channel networks)
2. Improve the scalability of transaction verification to increase the capacity of the on-chain protocol layer
What if there are more solutions aside from the two solutions that you mentioned?
E.g. probabilistic payments could be a method of circumventing the problem that some amounts are either
too small to be sent or the transaction fee would make the transaction uneconomical.
I´ll quote BitcoinWiki, because I really like the way that they explain the concept
of probabilistic payments:
Quote
Nanopayments are tiny payments for a trivial service. For example, 0.0001 BTC
for each of three Tor nodes to relay one megabyte of traffic with premium priority.
It should be easy to see that a series of payments like this would be "spam" to Bitcoin,
and infeasible due to transaction fees, and unwelcome to everyone who must download and store the whole block chain.
The idea, in a nutshell, is for Alice to make a 0.0001 BTC nanopayment to Bob by signing a message not worth 0.0001 BTC,
but by signing a message that has 1 in 10000 probability of being worth 1 BTC, and sending it to Bob directly. This message
would function much like a share in a mining pool. Out of 10000 nanopayments, on average, 9999 will be worthless and 1 will not.
For it to work fairly, Alice must not have any way to know which share is actually redeemable to the recipient.
Of course, due to variance, Alice will sometimes get her services for free, and sometimes she will vastly overpay.
However, if she consumes such services regularly, the amount she pays will tend toward the amount she consumes.
for each of three Tor nodes to relay one megabyte of traffic with premium priority.
It should be easy to see that a series of payments like this would be "spam" to Bitcoin,
and infeasible due to transaction fees, and unwelcome to everyone who must download and store the whole block chain.
The idea, in a nutshell, is for Alice to make a 0.0001 BTC nanopayment to Bob by signing a message not worth 0.0001 BTC,
but by signing a message that has 1 in 10000 probability of being worth 1 BTC, and sending it to Bob directly. This message
would function much like a share in a mining pool. Out of 10000 nanopayments, on average, 9999 will be worthless and 1 will not.
For it to work fairly, Alice must not have any way to know which share is actually redeemable to the recipient.
Of course, due to variance, Alice will sometimes get her services for free, and sometimes she will vastly overpay.
However, if she consumes such services regularly, the amount she pays will tend toward the amount she consumes.
I concede that this concept is probably unfeasible for many purposes, but in some areas
this could really be a viable solution for enabling micropayments.
