<p>Speaking as a programmer, it's VERY easy to screw up the transaction fee. If you're not using a known bitcoin client and are making your own, it's quite easy to accidentally leave out an output or calculate things wrong. The blockchain won't accept your transaction if you're spending more than the inputs, but will happily accept transactions if you're spending much less than the inputs.</p>

<p>All the errors basically end up going the same way (that is, in favor of the miners), so I'd imagine it's people like me who are testing something or trying to be too clever. This, by the way, is why you should be using <a href="https://en.bitcoin.it/wiki/Testnet" rel="nofollow">testnet</a> for software that's not ready.</p>

CC BY-SA 3.0
2015-02-10T23:07:29.133Z
Actually, nodes won't relay your transaction if you have more than 10000 times the required fee.
Nick ODell
CC BY-SA 3.0
2015-02-15T02:47:03.957Z
Good point about using the testnet.  I believe most of these spikes are due to programming error.  There have to be other reasons and possibilities though, right?
Scott
CC BY-SA 4.0
2020-03-23T21:03:45.993Z
@NickODell - do you have a reference for the "nodes won't relay your transaction if you have more than 10000 times the required fee"? I can't find anything like that.
Keir Finlow-Bates
CC BY-SA 3.0
2015-02-10T22:36:40.760Z
2015-02-10T22:36:40.760Z
Jimmy Song
<p>It would seem <a href="https://bitslog.wordpress.com/2014/10/05/the-bitcoin-freeze-on-transaction-attack-front/" rel="nofollow">using a large Tx fee is an attack vector</a> in that miners will all realign to try and solve the block at height <em>n</em>, which is quite different to the normal situation where it's usually two chains competing for length. The outcome requires 100% "rational actors" trying to mine the block height <em>n</em> and the ability of the nodes to detect the errantly/anomalously high fee. </p>

<p>A description from the blog of the <strong>Freeze Attack</strong>, postulating a ฿50 Tx fee:</p>

<blockquote>
  <p>The freeze problem occurs if someone publishes a transaction with fees
  much higher than the block subsidy. I don’t remember who described the
  attack first. Suppose that, by mistake, a transaction is published
  with 50 BTC in fees. The transaction is included in a block at height
  n. If everyone acts rationally in his own interest, then the best
  choice for the remaining miners is to try to mine a competing block at
  the same height n including the high-fee transaction, to collect the
  fee for themselves. All the miners having solved the block at height
  n, now move on mining at height (n+1). But they won’t choose each
  other branches until one branch is sufficiently longer so that it is
  better to switch to it and abandon their own branch rather than try to
  keep the block with the high fee. This case is different from the real
  block competition case we see periodically on the blockchain, where
  the miners are generally split between two branches. Here there are
  multiple branches competing. If there are 10 “top” miners each having
  10% of the network hashing power, then 10 different branches will
  compete. The analysis for this case is similar to the Gambler’s Ruin
  problem analysis present in the Satoshi paper, but with a fixed
  constant monetary incentive not to switch. Since the incentive to
  switch grows exponentially with the branch length difference, any
  initial constant is diluted. In the special and rare case that all the
  miners have exactly the same hashing power, then the network diverges,
  and this is equivalent as having two miners having exactly 50% of the
  hashing power each. So in principle the freeze on transaction problem
  is just a temporary disruption in the network, but not a fatal halt.
  Nevertheless, since during the freeze period each miner is mining on
  his own branch, it also means that moving forward with blocks is a lot
  slower. Assuming 10 miners having 10% of the total hashing power each
  (+/- 3%), the network becomes 10 times slower. I simulated it with a
  50 BTC tx freeze fee, and 10 miners, and it takes approximately 6
  blocks to converge, so the freeze time is approximately 60 times the
  block interval, or 10 hours. If the distribution is approximately 25%
  of the hashing power for each top miner, the freeze time is 4 hours.</p>
</blockquote>

CC BY-SA 3.0
2016-06-22T07:28:04.250Z
Very interesting attack, have a +1. I'd dispute the "100% rational actors" line though, since a rational actor would likely also consider other factors than the block reward in a past block, such as the lessened security of the blockchain, which has a subjective value which may or may not be priced at larger than this block reward.
user36303
CC BY-SA 3.0
2015-03-05T08:59:12.197Z
2015-03-05T08:59:12.197Z
Wizard Of Ozzie
<p>As mentioned, raw transactions are incredibly easy to screw up since you must explicitly <em>pay yourself</em> if you want change.</p>

<p>Here's a few scenarios besides unbalanced outputs which will produce huge transaction (Tx) fees:</p>

<ul>
<li>forgetting to pay change</li>
<li>forgetting to convert to Satoshis in your code</li>
<li>misplacing the decimal (perhaps due to rounding errors)</li>
<li>swapping the fields using BCI or Bitcoin Core (this used to happen easily)</li>
<li>setting the Txfee variable in the core software on top of the built in Tx fee</li>
<li>a miner could spend time mining the current blockchain plus an additional non-broadcasted transaction with a high fee. If the miner succeeded, it would then broadcast and cause a spike in the graph. The miner wouldn't make any extra money, and it would be wasting time not contributing to a pool.</li>
</ul>

CC BY-SA 3.0
2015-02-10T23:30:28.937Z
Thanks, it's nice to see the scenarios which could lead to large transactions.

Would it be possible to "game" the chart by paying yourself and collecting the large transaction fee via mining?  Of course it's a risky bet since you aren't guaranteed the transaction fee.
Scott
CC BY-SA 3.0
2015-02-10T23:36:19.037Z
Interesting question. But yes, a miner can do this without risking very much. The key would be to keep the transaction and NOT propagate it or let any other node know about it. When it finds a block, voila, it looks like someone made a mistake, but the miner got it right back anyway.
Jimmy Song
CC BY-SA 3.0
2015-02-10T23:56:28.517Z
"without risking very much".  That is intriguing.  It sounds like you are inferring that the miner could intentionally orphan a high transaction fee transaction.  I don't think orphans would affect this graph though, they are forgotten.
Scott
CC BY-SA 3.0
2015-02-11T03:23:06.890Z
@Scott: The proposal is simpler than that. The miner does not post his transaction on the peer to  peer network at all, so no other miner can include it in a block. However, he includes it in the blocks he works on himself. When he eventually finds a winning nonce for the block, his huge-fee transaction is included. Until then, nobody else knows it exists.
Nate Eldredge
CC BY-SA 3.0
2015-02-11T09:36:55.297Z
@NateEldredge I always wondered whether this occurred as a means of writing off "lost" BTC for accounting purposes
Wizard Of Ozzie
CC BY-SA 3.0
2015-02-10T23:26:34.000Z
2015-02-26T02:46:57.367Z
2015-02-26T02:46:57.367Z
Wizard Of Ozzie
<p>I am trying to understand why there are numerous days in Bitcoin's history that show huge transaction spikes.  See <a href="https://blockchain.info/charts/transaction-fees?timespan=all&amp;showDataPoints=false&amp;daysAverageString=1&amp;show_header=true&amp;scale=0&amp;address=" rel="nofollow noreferrer">this blockchain.info chart</a>. 
<img src="https://i.sstatic.net/53thA.png" alt="enter image description here"></p>

<p>The Jan 10th, 2012 spike is due to a mistake by <a href="https://bitcointalk.org/index.php?topic=135665.0" rel="nofollow noreferrer">this guy</a>.  I can't explain the other spikes.</p>

<p>Are these spikes mostly or all due to human error? Or are they some other indicator, possibly market value, global usage or popularity?  Maybe some think that paying a high fee is supporting the network.</p>

<p>The <a href="https://blockchain.info/charts/n-transactions-total" rel="nofollow noreferrer">number of transactions</a> can obfuscate the actual worldwide usage due to things like mixing services, automated transactions, spam.  Maybe the fees spent can rule those out and show the global adoption rate assuming those types of transactions would avoid fees as much as possible.</p>

<p>Bonus points if you happen to know <em>what</em> specifically caused any one of these individual spikes.  Having a list would benefit Bitcoin history story telling.</p>

<transaction-fees><charts><market>
Are the huge transaction fees mostly mistakes or some other market indicator?
Scott
# Are the huge transaction fees mostly mistakes or some other market indicator?

(Asked by: username_0 on 2015-02-10)

I am trying to understand why there are numerous days in Bitcoin's history that show huge transaction spikes. See [this blockchain.info chart](https://blockchain.info/charts/transaction-fees?timespan=all&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&address=).
![enter image description here](https://i.sstatic.net/53thA.png)

The Jan 10th, 2012 spike is due to a mistake by [this guy](https://bitcointalk.org/index.php?topic=135665.0). I can't explain the other spikes.

Are these spikes mostly or all due to human error? Or are they some other indicator, possibly market value, global usage or popularity? Maybe some think that paying a high fee is supporting the network.

The [number of transactions](https://blockchain.info/charts/n-transactions-total) can obfuscate the actual worldwide usage due to things like mixing services, automated transactions, spam. Maybe the fees spent can rule those out and show the global adoption rate assuming those types of transactions would avoid fees as much as possible.

Bonus points if you happen to know *what* specifically caused any one of these individual spikes. Having a list would benefit Bitcoin history story telling.

**Tags:** transaction-fees, charts, market


---

## 3 answers

### Answer by username_4 on 2015-02-10. Score: 3 | Accepted answer

As mentioned, raw transactions are incredibly easy to screw up since you must explicitly *pay yourself* if you want change.

Here's a few scenarios besides unbalanced outputs which will produce huge transaction (Tx) fees:

* forgetting to pay change
* forgetting to convert to Satoshis in your code
* misplacing the decimal (perhaps due to rounding errors)
* swapping the fields using BCI or Bitcoin Core (this used to happen easily)
* setting the Txfee variable in the core software on top of the built in Tx fee
* a miner could spend time mining the current blockchain plus an additional non-broadcasted transaction with a high fee. If the miner succeeded, it would then broadcast and cause a spike in the graph. The miner wouldn't make any extra money, and it would be wasting time not contributing to a pool.

> **Comments:**
> **username_0**: Thanks, it's nice to see the scenarios which could lead to large transactions.  Would it be possible to "game" the chart by paying yourself and collecting the large transaction fee via mining?  Of course it's a risky bet since you aren't guaranteed the transaction fee.  
> **username_1**: Interesting question. But yes, a miner can do this without risking very much. The key would be to keep the transaction and NOT propagate it or let any other node know about it. When it finds a block, voila, it looks like someone made a mistake, but the miner got it right back anyway.  
> **username_0**: "without risking very much".  That is intriguing.  It sounds like you are inferring that the miner could intentionally orphan a high transaction fee transaction.  I don't think orphans would affect this graph though, they are forgotten.  
> **username_6**: @username_0: The proposal is simpler than that. The miner does not post his transaction on the peer to  peer network at all, so no other miner can include it in a block. However, he includes it in the blocks he works on himself. When he eventually finds a winning nonce for the block, his huge-fee transaction is included. Until then, nobody else knows it exists.  
> **username_4**: @username_6 I always wondered whether this occurred as a means of writing off "lost" BTC for accounting purposes  

---

### Answer by username_1 on 2015-02-10. Score: 2

Speaking as a programmer, it's VERY easy to screw up the transaction fee. If you're not using a known bitcoin client and are making your own, it's quite easy to accidentally leave out an output or calculate things wrong. The blockchain won't accept your transaction if you're spending more than the inputs, but will happily accept transactions if you're spending much less than the inputs.

All the errors basically end up going the same way (that is, in favor of the miners), so I'd imagine it's people like me who are testing something or trying to be too clever. This, by the way, is why you should be using [testnet](https://en.bitcoin.it/wiki/Testnet) for software that's not ready.

> **Comments:**
> **username_2**: Actually, nodes won't relay your transaction if you have more than 10000 times the required fee.  
> **username_0**: Good point about using the testnet.  I believe most of these spikes are due to programming error.  There have to be other reasons and possibilities though, right?  
> **username_3**: @username_2 - do you have a reference for the "nodes won't relay your transaction if you have more than 10000 times the required fee"? I can't find anything like that.  

---

### Answer by username_4 on 2015-03-05. Score: 2

It would seem [using a large Tx fee is an attack vector](https://bitslog.wordpress.com/2014/10/05/the-bitcoin-freeze-on-transaction-attack-front/) in that miners will all realign to try and solve the block at height *n*, which is quite different to the normal situation where it's usually two chains competing for length. The outcome requires 100% "rational actors" trying to mine the block height *n* and the ability of the nodes to detect the errantly/anomalously high fee.

A description from the blog of the **Freeze Attack**, postulating a ฿50 Tx fee:

> The freeze problem occurs if someone publishes a transaction with fees
> much higher than the block subsidy. I don’t remember who described the
> attack first. Suppose that, by mistake, a transaction is published
> with 50 BTC in fees. The transaction is included in a block at height
> n. If everyone acts rationally in his own interest, then the best
> choice for the remaining miners is to try to mine a competing block at
> the same height n including the high-fee transaction, to collect the
> fee for themselves. All the miners having solved the block at height
> n, now move on mining at height (n+1). But they won’t choose each
> other branches until one branch is sufficiently longer so that it is
> better to switch to it and abandon their own branch rather than try to
> keep the block with the high fee. This case is different from the real
> block competition case we see periodically on the blockchain, where
> the miners are generally split between two branches. Here there are
> multiple branches competing. If there are 10 “top” miners each having
> 10% of the network hashing power, then 10 different branches will
> compete. The analysis for this case is similar to the Gambler’s Ruin
> problem analysis present in the Satoshi paper, but with a fixed
> constant monetary incentive not to switch. Since the incentive to
> switch grows exponentially with the branch length difference, any
> initial constant is diluted. In the special and rare case that all the
> miners have exactly the same hashing power, then the network diverges,
> and this is equivalent as having two miners having exactly 50% of the
> hashing power each. So in principle the freeze on transaction problem
> is just a temporary disruption in the network, but not a fatal halt.
> Nevertheless, since during the freeze period each miner is mining on
> his own branch, it also means that moving forward with blocks is a lot
> slower. Assuming 10 miners having 10% of the total hashing power each
> (+/- 3%), the network becomes 10 times slower. I simulated it with a
> 50 BTC tx freeze fee, and 10 miners, and it takes approximately 6
> blocks to converge, so the freeze time is approximately 60 times the
> block interval, or 10 hours. If the distribution is approximately 25%
> of the hashing power for each top miner, the freeze time is 4 hours.

> **Comments:**
> **username_5**: Very interesting attack, have a +1. I'd dispute the "100% rational actors" line though, since a rational actor would likely also consider other factors than the block reward in a past block, such as the lessened security of the blockchain, which has a subjective value which may or may not be priced at larger than this block reward.  

---

