The Bitcoin testnet does not often breaks down suddenly. For some reason, that is exactly what happened two days ago. After someone mined many testnet blocks, it seemingly triggered some protocol, which would reject blocks if they are below a certain size. It took some time to rectify this situation, but things are seemingly back to normal.

Bitcoin Testnet BTC1 Breaks Down Briefly

It appears a splitting of the Bitcoin blockchain is not the only thing to worry about right now. For the first time in a while, the BTC1 testnet experienced such a major issue which left all nodes stuck on block 27070. Although this hiccup does not affect the Bitcoin mainnet by any means, it demonstrates the fragility of the network and reminds us to be careful these following weeks.

Someone was mining testnet blocks a few days ago. It appears this behavior triggered the BIP102 rule, which rejects blocks too small in size. This is often solved by mining a larger block on the testnet, which would “reset” the trigger, that did not happen immediately. Thankfully, the matter got resolved eventually, but it highlights a larger underlying problem.

It appears this unintentional fork was caused by the SegWit2x scaling solution. Any node running the Segwit2x code was stuck on block 27070, whereas any other software could just carry on without problems. Granted, there is no real money on the line where the testnet is concerned, but events like these should not even take place to begin with -testnet or otherwise-. It also highlights why SegWit2x needs a lot more testing before it is scheduled to activate on the main Bitcoin network in just under three weeks from now.

Everyone in the Bitcoin community knows SegWit2x was cobbled together hastily, and has not been thoroughly tested. Other developers have criticized the team for not taking their advice. Even the flaws pointed out have been ignored so far. If this had happened to the mainnet, rather than the testnet, things would look incredibly bleak for Bitcoin right now.

While this is a very disturbing development, there are those who feel this debacle needs to be shrugged off without giving it a second thought. Jeff Garzik, for example, believes a testnet miner triggered an event without the working group participants being prepared for it. While that may indeed be the case, it still goes to show the code will need some thorough vetting. A testnet is more susceptible to these types of “attacks” since there is much less hashpower pointed to it.

This testnet fork is both a blessing and a curse at the same time. On the one hand, it shows there are some issues which may warrant further investigation moving forward. Then again, it “only” occurred on the testnet, and no real harm has been done in the process. A very interesting development that will be talked about for quite some time to come. We can only hope issues like these will not arise once SegWit2x gets activated on July 31st.