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.

  • "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." << Think you just answered your own question there :) Nov 19, 2012 at 21:05
  • @DavidPerry - ;) Yes, thanks... I'm trying to dig up alternative ideas. I have a few more that may get some +/- votes but want to see what others have come up with. Nov 19, 2012 at 21:10

4 Answers 4


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.

  • False dichotomy. Tx fees can be higher than they are now and still low enough for microtransactions. Also, I think tx fees should have a strong value-dependent component, so you could have both microtransactions and high-value transactions with enough fees to sponsor hashing. Nov 23, 2012 at 5:19

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.

  • 1
    The mistake here is that there is a degree of freedom. Mining is artificially difficult. Low profitability will not be corrected by increasing fees, but by leaving miners (which will bring profitability up to acceptable levels, but network security down). To keeps the network hashrate high, there must be some mechanism to keep transaction fees high (relatively). Nov 22, 2012 at 19:53

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.

  • Interesting. Has the idea of limiting total block tx value been discussed before? (I'm guessing yes, but I don't recall a thread about this)
    – ripper234
    Nov 22, 2012 at 20:10
  • 1
    @ripper234: I'm sure I've brought it up before (probably here on B.SE). It occurred to me during the discussions at bitcointalk.org/index.php?topic=6284.0 and I may have mentioned it then. To me it's pretty obvious, but I'll write a coherent post about it sometime. Nov 23, 2012 at 5:05

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.