user6375: I am trying to understand why there are numerous days in Bitcoin's history that show huge transaction spikes.  See this blockchain.info chart. 

The Jan 10th, 2012 spike is due to a mistake by this guy.  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 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.

user23123: 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 for software that's not ready.

user9382: It would seem using a large Tx fee is an attack vector 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.


user9382: 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.


6375: <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.stack.imgur.com/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>
 23123: <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>
 9382: <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>
 9382: <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>
