How to get the general population to pay more in transaction fees?

Question

When mining becomes less profitable* what options are there for miners and mining pools to persuade or insist that end users pay more in transaction fees?

I'm interested in

• Specific code changes that need to be done in miners (to exclude low fee Tx)
• Business plans (or description thereof)
• Incentives of various types (..free Namecoins if pool X processes your Tx)

Sure there will probably always be miners who accept zero fee Tx but I am thinking that this might become the minority over time. As a result these zero fee miners will finish fewer blocks and will cause zero fee Tx to be delayed before being added to a block.

*Mining can become less profitable for a number of reasons: increased difficulty, poor conversion rates, decreased reward, higher costs (hardware, electricity), or government regulation & taxation on mining income.

Answer 1

I don't think that it is definitely a good idea to increase the transaction fee. One of bitcoins biggest selling points is the ability for micro-payments and very low transaction fees. While I do agree with others that micro-transactions will eventually move off the blockchain. For now even with the block-reward halving, transactions fees still won't benefit miners financially much for a very long time. As again as I said the ability to make bitcoin transactions much cheaper than traditional means is one of bitcoins main selling points and will be for a long time. Until such a date that the majority of bitcoin transactions are made off the blockchain. Instead in house by larger bitcoin payment and services provider outlets.

Answer 2

Bitcoin is designed to be entirely free-market. You can't "get" anyone to do anything. If mining becomes more expensive, miners will charge more and people will pay more. If someone can do it for cheaper, that will bring down the market price of a transaction.

Answer 3

Transaction fees pay for two completely different things which should not be confused. One is the marginal cost of verifying, propagating and storing the transaction; the other is the amortized cost of hashing to secure the network.

Addressing the first need is relatively easy (though not yet solved because the receiver of the reward is not identical to those who have to pay the cost); a miner will not include a transaction if its fee is below the marginal cost. Hence senders who want their transaction included will pay at least the marginal cost (as will be determined by historic equilibrium).

The second need is more subtle. For the sake of discussion we can assume the marginal cost to be 0. Then a miner will always want to include any positive-fee transaction, however low, since it costs him nothing and he gets the fee. But if everyone does this, tx fees will race to the bottom, the total profit to be made from mining will shrink, the network hashrate will decrease and it will be vulnerable to attack.

This is a bargaining game between miners and senders, where "miners" are not a monolithic entity and suffers from a tragedy of the commons; the self-interest of each miner harms the totality of miners, and hence, the network security.

The current protocol enforces a data size limit of 1 MB per block. This makes space in a block a scarce resource over which transactions will compete, increasing the equilibrium fee. However, this is hardly efficient or optimal. The size limit likely will need to be relaxed at some point.

When this happens, I believe the optimal way to give miners the bargaining power they need is to enforce on the protocol level a hard limit on the total value of transactions per block. This will make miners choose transactions based on their fee-to-value ration; thus making sure that those sending high-value transactions, who gain the most from the protection of the hashing network, pay for the privilege accordingly.

Answer 4

Here is one way to encourage higher transaction fees, and a better UX. Suppose that miners will only include 10 zero fee transactions in a block. The rest are FIFO. Then

1. I broadcast a transaction, sending X coins to some address.

2. It doesn't get included in blocks for a while because I don't include a fee. (or a low fee)

3. The user gets tired of waiting and they use a future feature to resubmit the tx, replace the pending one, and get their block mined quickly.

This feature is discussed here by Satoshi

Not locktime.

There's a possible design for far in the future:

You intentionally write a double-spend. You write it with the same inputs and outputs, but this time with a fee. When your double-spend gets into a block, the first spend becomes invalid. The payee does not really notice, because at the moment the new transaction becomes valid, the old one becomes invalid, and the new transaction simply takes its place.

It's easier said than implemented. There would be a fair amount of work to make a client that correctly writes the double-spend, manages the two versions in the wallet until one is chosen, handles all the corner cases. Every assumption in the existing code is that you're not trying to write double-spends.

There would need to be some changes on the Bitcoin Miner side also, to make the possibility to accept a double-spend into the transaction pool, but only strictly if the inputs and outputs match and the transaction fee is higher. Currently, double-spends are never accepted into the transaction pool, so every node bears witness to which transaction it saw first by working to put it into a block.