2

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

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.

3 Answers 3

3

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.
5
  • 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
    Feb 10, 2015 at 23:30
  • 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.
    – Jimmy Song
    Feb 10, 2015 at 23:36
  • "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
    Feb 10, 2015 at 23:56
  • 2
    @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. Feb 11, 2015 at 3:23
  • 2
    @NateEldredge I always wondered whether this occurred as a means of writing off "lost" BTC for accounting purposes Feb 11, 2015 at 9:36
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 for software that's not ready.

3
  • 3
    Actually, nodes won't relay your transaction if you have more than 10000 times the required fee.
    – Nick ODell
    Feb 10, 2015 at 23:07
  • 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
    Feb 15, 2015 at 2:47
  • @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. Mar 23, 2020 at 21:03
2

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.

1
  • 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
    Jun 22, 2016 at 7:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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