<p>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. </p>

CC BY-SA 3.0
2012-11-23T05:19:37.447Z
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.
Meni Rosenfeld
CC BY-SA 3.0
2012-11-20T23:11:49.100Z
2012-11-20T23:11:49.100Z
Matthewh3
<p>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.</p>

CC BY-SA 3.0
2012-11-22T19:53:01.883Z
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).
Meni Rosenfeld
CC BY-SA 3.0
2012-11-22T17:40:29.000Z
2012-11-22T17:40:29.000Z
wyager
<p>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.</p>

<p>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).</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

CC BY-SA 3.0
2012-11-22T20:10:43.583Z
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
CC BY-SA 3.0
2012-11-23T05:05:33.567Z
@ripper234: I'm sure I've brought it up before (probably here on B.SE). It occurred to me during the discussions at https://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.
Meni Rosenfeld
CC BY-SA 3.0
2012-11-22T19:50:30.493Z
2012-11-22T19:50:30.493Z
Meni Rosenfeld
<p>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 </p>

<ol>
<li><p>I broadcast a transaction, sending X coins to some address.</p></li>
<li><p>It doesn't get included in blocks for a while because I don't include a fee. (or a low fee)</p></li>
<li><p>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.</p></li>
</ol>

<p>This feature <a href="https://bitcointalk.org/index.php?topic=2181.msg28729#msg28729" rel="nofollow">is discussed here</a> by <strong>Satoshi</strong></p>

<blockquote>
  <p>Not locktime.</p>
  
  <p>There's a possible design for far in the future:</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>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.</p>
</blockquote>

CC BY-SA 3.0
2013-03-11T05:05:36.510Z
2013-03-11T05:05:36.510Z
makerofthings7
<p>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?</p>

<p>I'm interested in </p>

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

<p>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.</p>

<p>*Mining can become less profitable for a number of reasons: <a href="http://www.bitcoindifficulty.com" rel="nofollow noreferrer">increased difficulty</a>, poor <a href="https://mtgox.com" rel="nofollow noreferrer">conversion rates</a>, <a href="https://bitcoin.stackexchange.com/q/3111/1878">decreased reward</a>, higher <a href="https://bitcoin.stackexchange.com/q/485/1878">costs</a> (hardware, electricity), or <a href="https://bitcoin.stackexchange.com/q/4389/1878">government regulation</a> &amp; <a href="https://bitcoin.stackexchange.com/q/2783/1878">taxation</a> on mining income.</p>

CC BY-SA 3.0
2012-11-19T21:05:06.283Z
"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 :)
David Perry
CC BY-SA 3.0
2012-11-19T21:10:19.727Z
@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.
makerofthings7
<mining-pools><transaction-fees><mining-profitability>
How to get the general population to pay more in transaction fees?
makerofthings7
# How to get the general population to pay more in transaction fees?

(Asked by: username_0 on 2012-11-19)

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](http://www.bitcoindifficulty.com), poor [conversion rates](https://mtgox.com), [decreased reward](https://bitcoin.stackexchange.com/q/3111/1878), higher [costs](https://bitcoin.stackexchange.com/q/485/1878) (hardware, electricity), or [government regulation](https://bitcoin.stackexchange.com/q/4389/1878) & [taxation](https://bitcoin.stackexchange.com/q/2783/1878) on mining income.

**Tags:** mining-pools, transaction-fees, mining-profitability

> **Comments:**
> **username_1**: "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 :)  
> **username_0**: @username_1 - ;) 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.  

---

## 4 answers

### Answer by username_2 on 2012-11-20. Score: 2

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.

> **Comments:**
> **username_3**: 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.  

---

### Answer by username_4 on 2012-11-22. Score: 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.

> **Comments:**
> **username_3**: 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).  

---

### Answer by username_3 on 2012-11-22. Score: 2

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.

> **Comments:**
> **username_5**: 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)  
> **username_3**: @username_5: I'm sure I've brought it up before (probably here on B.SE). It occurred to me during the discussions at https://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.  

---

### Answer by username_0 on 2013-03-11. Score: 0

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](https://bitcointalk.org/index.php?topic=2181.msg28729#msg28729) 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.


---

