Blockchain BTC
Between Nov 20th and 27th, Bitcoin faced its busiest week ever with 2 million transactions, a near-constant backlog of tens of thousands of transactions to confirm, and a record 333, 466 transactions processed in a day. This resulted in average confirmation times reaching an unusually slow speed of more than 2 hours.
The number of Bitcoin transactions and unique addresses have been on the rise and Bitcoin’s market price as well as the number of Blockchain wallets have increased by 35% over the past 6 months. However, this recent episode was more intense than the usual peaks.
One thing to remark first is that this episode of intense activity is different from the previous one that occurred between Oct 24th and 28th. While that was easily attributable to an entity that consolidated a great number of inputs, this episode is the contrary: the number of outputs increased at a greater rate than usual during the congestion. As the number of unspent outputs grow, the validation of blocks takes longer and puts a strain on the network.
Looking deeper at the number of outputs per transaction, we notice that the proportion of transactions creating 17 outputs was three times bigger than usual (0.96% versus 0.32%) during the congestion period (@LaurentMt was the first to notice this: ). This difference is the direct cause for at least an extra 5 to 6MB of transaction data processed during the congestion period. Furthermore, plotting the rate at which these transactions were broadcasted along with the mempool size reveals a very interesting pattern:
The 17-outputs transactions were broadcast at a rate that constantly increased until the mempool reached its peak value, then the broadcast stopped abruptly. It seems that when the rate reached above 120 transactions per hour, the mempool started to increase in size uncontrollably until the broadcast stopped, after which the mempool started to slowly decrease as the backed up transactions were confirmed by the miners.
While it is hard to know exactly how much of the backlog is attributable to this influx of 17-outputs transactions, the link between the broadcast stop and the peak of the mempool size is clear. The real cause of the broadcast of these transactions is unknown, but the regular increase of the broadcast rate, the duration of it and its cost in fees (in the order of 5 BTC) make it a very unlikely accident.
During this episode, the network behaved more strangely. The website statoshi.info tracks peers misbehaviours, such as broadcasting duplicate, invalid or non standard transactions.
During the period of high congestion of the network, the number of misbehaviours related to non standard transactions skyrocketed and seemed to have followed the highs and lows of the mempool. A transaction can be rejected with this flag if it creates too long of a chain of unconfirmed transactions. This indicates that such chains were created, either involuntarily due to longer than usual confirmation delays or voluntarily in an effort to stress test the network as it already happened in the past.
All the data in this post (apart from the statoshi.info image) come from the free Blockchain data APIs. If you’re interested in creating an open, accessible and fair financial future, one piece of software at a time, have a look at our open positions
