A very unusual thread was posted on Bitcointalk Saturday, claiming that the ‘ultimate Bitcoin stress test’ was about to be conducted by an anonymous hacker. The goal of the test was to provide clear evidence that the 1 mb blocksize limit puts Bitcoin in imminent danger, since spamming the network would fill the blocks to their limit and lead to a massive pileup of unconfirmed transactions, essentially stopping people from sending and receiving Bitcoins for hours if not days. This was done to simulate what the hacker expects to happen when blocks reach the 1 mb limit naturally in the next 1-2 years. It is clear that the person conducting this test is not a scientist even though they claimed this was an experiment, since they showed extreme bias towards the result they wanted before the test even began.
The hacker used 10 Bitcoin servers to send 20 larger than usual transactions per second, generating 1 mb of transaction data every 5 minutes. Since the blocksize limit is 1 mb and there is on average 10 minutes between blocks, the hacker projected this would overwhelm the Bitcoin network and bring transactions to a standstill. Typically only 0.0001 Bitcoins (2.5 cents) per kb of data is required as a transaction fee to send your Bitcoins as fast as possible. The hacker set aside 20 Bitcoins ($5000) for this test, and calculated that 0.1 Bitcoins would be spent per 1 mb, and since 1 mb is the blocksize limit he expected 100 blocks to be filled with his spam. This projection assumes that transaction fees would only double to 0.0002 Bitcoins per kb. 100 blocks worth of spam transactions would cause all transactions to be extremely slow for 2-3 days according to the hacker, he envisioned a constantly growing pile up of unconfirmed transactions until he stopped spamming the network.
If the hacker’s calculations were right this would have been a disaster for Bitcoin’s economy. Bitcoin traders would lose profits since they’d barely be able to move their Bitcoins around, Bitcoin dealers would have no supply and lose customers (and those who did have supply would anger the customers since nothing would confirm for days), merchants who accept Bitcoin wouldn’t be able to receive payment, customers buying goods wouldn’t be able to send payment in a timely manner, and all Bitcoin ATMs and in-store technology that accepts Bitcoin wouldn’t work. It is appalling that this hacker wanted this scenario to happen all in the name of a ‘test’. If this did happen as he expected the Bitcoin community would have lost tens of millions of dollars at the least. Trust in Bitcoin’s integrity would be shattered and the value would destabilize.
It appears the test started at 4 am eastern time, with the size of block 362002 jumping to near the 1 mb blocksize limit. After this point most blocks were near or at the limit, but there were several blocks of normal size, probably since they were mined faster than the spam could fill them up. Starting with block 362030 at 8:21 am nearly every block was at its size limit, with unconfirmed transactions piling up and slowing down transaction speed worldwide. Transaction fees began to rapidly rise as seen in the below chart, exceeding 0.005 Bitcoins per transaction briefly which is 5000% higher than usual. This increase in transaction fees is a direct result of demand to send transactions exceeding the available transaction slots in a block, a beautiful example of the law of supply and demand at work.
The hacker only expected a 100% increase in transaction fees, so his projection that the blockchain would be overwhelmed for 24+ hours was completely invalid. It appears the hacker pulled the plug on the spam transactions once he realized how fast the 20 Bitcoins allotted for the test were evaporating, allowing the pile of unconfirmed transactions to be let through and a return to normal transaction fees in less than an hour. A 2nd round of spam transactions was then unleashed at 2:30 pm, culminating in transactions fees exceeding 0.005 Bitcoins briefly around 4:30 pm. After this point transaction fees once again rapidly dropped since spam transactions weren’t affordable and were turned off until things normalized. A few smaller spikes in transaction fees were then observed, with transaction fees leveling off at normal values after 10 pm, likely due to the 20 Bitcoins being completely spent. It is impressive that a mere $5000 could dominate transaction fee values over an 18 hour period, but the main goal of the test to cause massive transaction delays never materialized. The longest delays were 1-3 hours, and delays of such length are common for Bitcoin even without a hacker attacking the network.
By far the most interesting thing revealed by this test was Bitcoin’s natural ability to counteract transaction volume in excess of the blocksize limit. Once a significant pile up of unconfirmed transactions began due to lack of space, transaction fees increased making it prohibitively expensive to send spam and dust transactions. Fees will rise until the number of new transactions is small enough to allow the excess unconfirmed transactions into the newest blocks, which rapidly drops transaction fees back to normal levels.
This is direct proof that Bitcoin could keep the 1 mb blocksize limit indefinitely and be completely stable, which is the exact opposite of what the hacker was expecting. Running into the blocksize limit and causing a pile up of unconfirmed transactions simply increases the fees in order to lower new transaction volume and dissipate the pileup of older transactions. The majority of Bitcoin developers expected this result, which is why they are against changing the blocksize limit.
A major benefit is miners will be paid higher transaction fees as Bitcoin use becomes more widespead, as long as the limit remains capped at 1 MB. This will help balance out the decreasing block reward over time, giving miners an incentive to keep mining even when block rewards become infinitesimally small. If blocksize limit were allowed to increase and transaction fees therefore never increased almost everyone would abandon mining, which would result in a vulnerable and unusable Bitcoin network, i.e. the death of Bitcoin. Thus, having a blocksize limit is crucial in order for Bitcoin to survive long term.
This stress test is a direct result of an ongoing debate in the Bitcoin community on whether to increase the blocksize limit, which has led to one of the Bitcoin developers going rogue and creating Bitcoin XT, which will increase blocksize limit with a fork. A fork has never intentionally been introduced into the blockchain in history since it is a risky maneuver. It is inevitable that some users will lose Bitcoins during a fork if they aren’t using the dominant blockchain. In a worst case scenario the Bitcoin XT fork could create unforeseen complications, requiring more forks to fix it. Any fork will destabilize Bitcoin’s value even if it is successful, if it ends up being a disaster Bitcoins could completely lose their value.
Clearly it isn’t prudent to risk forking the blockchain to increase blocksize, since Bitcoin naturally adjusts to higher transaction volume even if blocks are capped at 1 mb for the rest of history, and the smaller blocksize will increase transaction fees. Higher transaction fees aren’t essential in the near future, but will be essential as the block reward drops to zero in the long term. Only about 100 out of 6000 total Bitcoin nodes are running XT despite mass publicity over the past month, since the majority of Bitcoiners recognize that blocksize limit does not threaten Bitcoin’s functionality. The stress test conducted yesterday will only increase this consensus, since now real-life data exists about what happens when transaction volume exceeds the blocksize limit. Although the hacker didn’t get the result he wanted, he did produce valuable data with this test, and since no one got hurt by it I applaud his efforts.