The Challenges of Building on Bitcoin Testnet

Stacks relies on the Bitcoin network in order to function (you can learn more about that relationship in the Stacks white paper), and that’s true for both Stacks mainnet and testnet. That is part of the value proposition of Stacks—Stacks inherits the security and decentralization of the Bitcoin network.

Despite Bitcoin’s popularity, it’s not very friendly to developers. While Bitcoin mainnet has proven to be a stable, secure network, the same has not been true for Bitcoin testnet, where Stacks has encountered problems for years.

Those problems have finally come to a head in the last few months, and Stacks core developers decided to reset Stacks testnet on a different Bitcoin network altogether.

This decision wasn’t made lightly—resetting testnet means Stacks testnet state is wiped clean, which could cause frustration or disruption for many dev teams building on Stacks—but ultimately, the ecosystem believes that it’s a worthwhile trade for the long-term stability and usability of the network.

In this post, I want to share my perspective and talk frankly about the challenges of building on Bitcoin testnet. For devs who are building on Bitcoin, hopefully this post can help inform your approach to building on Bitcoin and determining which testnet network best meets your needs.

A Quick Background on Stacks Testnet

The primary Stacks testnet first launched on April 2020, and it launched on Bitcoin Testnet3. This has been the primary Bitcoin testnet for 13 years, though Bitcoin Testnet4 recently launched to replace it and fix some of the issues present in Testnet3 (but we’ll get back to that in a bit).

Over the past several years, this primary Stacks testnet has run mostly uninterrupted. It has built up a lot of state over time, and there is usefulness in having that state: it helps with stress testing the blockchain.

In general, a network that accumulates state over time has value when testing scenarios that require a lot of state. For example, think about contracts that have been called into many times and thus have built up a large on-chain footprint, or a specific set of wallet <> contract interactions that trigger an edge-case in the API, or a network that has seen many rounds of PoX and has gone through different network upgrades. You need state in all of these examples to thoroughly test them.

While Stacks testnet has run uninterrupted the past few years, that doesn’t mean we haven’t encountered challenges. There have been many difficulties with the Bitcoin testnet that have impacted Stacks testnet.

Occasionally, there are flash blocks in Bitcoin testnet or block storms where several months worth of blocks get mined in a single day. Sometimes, a Stacks miner stalls based on a block storm or some other behavior on Bitcoin testnet (for example, Stacks developers found one bug caused by a chain reorg “flap” where the chain switches from tip A to tip B back to tip A). The list goes on, but suffice to say that there are edge cases that Stacks doesn’t handle well.

Some of these issues proved hard to debug, and others Stacks developers had a hard time reproducing elsewhere (perhaps because the bug only occurs on Bitcoin testnet and thus isn’t relevant for mainnet). To solve these edge cases, ecosystem engineers periodically had to manually restart Stacks testnet nodes, and that would take care of the issue. With some sweat, Stacks developers would be able to restore progress on testnet, enabling the network to continue to mine new blocks. This helped harden the Stacks network, which is a good thing.

For a while things were ok. But then Lopp happened.

The State of Bitcoin Testnet Today

To fully understand what’s been going on with Bitcoin Testnet, I recommend reading Lopp’s Griefing Bitcoin Testnet. In short, Lopp launched a block storm on the Bitcoin Testnet to point out the flaws in the testnet network and to show proof that the Bitcoin community needs to reset and restore testnet. 

The outcome of Lopp’s griefing is that Bitcoin Testnet3 became unusable: because of the block storm, Stacks testnet nodes ran into a number of issues, and effectively the Bitcoin testnet had halted Stacks testnet from mid-April-last week. And with no new blocks, Stacks developers had been unable to deploy contracts and test their code on testnet.

Engineers across the ecosystem spent 2 months trying to stabilize Stacks testnet and playing around with different configuration parameters, node resourcing, etc. But that began to eat into the Nakamoto timelines for an upcoming Stacks network upgrade.

Rather than continuing to work through those Bitcoin testnet issues, the ecosystem collectively decided to reset Stacks testnet on a different Bitcoin network altogether, and the good news for Stacks and for other Bitcoin builders is that there are options.

Bitcoin Testnet Options

Bitcoin builder have 3 testnet options to choose from:

• Bitcoin Testnet: This is the primary Bitcoin testnet. It is a public, permissionless network (like Bitcoin mainnet) that anyone can join.
• Bitcoin Regtest: This is a regulated Bitcoin testnet. These are permissioned environments, and anyone can spin up their own Regtest if they want to. Think of this as a private sandbox environment that is much more predictable in its behavior.
• Bitcoin Signet: This is a hybrid testnet environment. It is a public network (unlike regtest), but it does have some regulated properties (unlike Testnet, which is permissionless). Signet doesn’t use Proof-of-Work and instead relies on a semi-centralized signer system to produce new blocks and ensure a stable network.

While the Bitcoin development community quickly released Bitcoin Testnet4 in response to Lopp's Griefing, the Stacks ecosystem decided to move off Bitcoin testnet entirely. Instead, the ecosystem spun up a new Bitcoin Regtest network that will be run by the Stacks community, and the Stacks testnet was reset with this new Regtest network.

This decision was made to prioritize the limited bandwidth of core contributors (making progress on Nakamoto was deemed more important than debugging issues related to Bitcoin testnet), and I agree with that consensus.

This reset of Stacks testnet came with a few consequences, namely the Stacks testnet network was wiped clean, and there was a new genesis block with that reset (though the previous testnet will still exist in an archived form until the end of June for those that want to access its state). Hiro will work closely with Stacks developers as they implement these changes across their work.

Why Regtest?

Regtest is stable, predictable, and controlled, and the Stacks ecosystem could execute this network reset quickly.

In fact, Stacks already have some experience with Regtest networks. The Stacks ecosystem launched a Nakamoto testnet (a secondary Stacks testnet network) with Bitcoin Regtest in order to simulate the fast blocks and Bitcoin finality that will come with the upgrade, before the primary Stacks testnet activates with these changes.

At Hiro, we also built a Regtest network into Clarinet for its local blockchain testing environment. In short, the ecosystem has built some expertise around using Bitcoin Regtest, and it was the easiest transition.

But I don’t think Regtest is a perfect solution. Ideally, you want a testnet environment that is fully public and mimics mainnet, but the reality is that Bitcoin testnet is currently challenging to work with for projects looking for a stable and predictable testnet.

For projects that need stability and predictability in their test network, Bitcoin Signet likely offers the best of both worlds: an open network that also offers better stability guarantees.

Indeed, the Stacks ecosystem explored migrating to Bitcoin Signet, but it required more work on the Stacks blockchain side, which would have affected the timeline to the Nakamoto release.

Given that, the community decided to opt for Bitcoin Regtest to focus on the Nakamoto upgrade, and will revisit a Signet migration in the fall post-Nakamoto.

Devs Need Better Signet Tooling

Based on my experience with Bitcoin testnet and what the Stacks ecosystem has gone through, I think more projects should be leveraging Signet, but devs need better tooling to make that a reality. It needs to be easier for devs to spin up their own signet environments. Maybe that’s something we explore at Hiro in the future.

Hopefully this post can shed some light on the challenges of Bitcoin testnet and help guide other Bitcoin builders to the right testnet network for their project. Good luck, and happy testing.