In a recent report titled “Stacks: The Difficulties of Scaling Bitcoin,” published by Blockworks, concerns were raised regarding some recent bugs and mining issues on the Stacks network.
The report covers many of the issues we’ve already been discussing here and on GitHub and is largely based on those discussions. Most importantly though it (1) does not introduce any new information or exploits and (2), contains some technical inaccuracies and at times exaggerates the potential impact of these issues because of these technical misunderstandings.
There are three issues highlighted in the report:
-
The recent stacks-increase bug, which is already fixed on the live network. This was extensively discussed here and GitHub etc and the upgrade in response to the bug went live within 24 hours. No user funds were at risk due to this bug.
-
The Bitcoin MEV vector, which has concrete proposals listed here and analyzed in a report here. This has been a known MEV vector since day 1 of mainnet and not new information. The upgrade is relatively straightforward and is at final stages.
-
The Stacks L2 reorg resistance. Reorgs are a natural part of blockchains like Bitcoin and Stacks L2 and the key thing is to keep the security budget very high to make reorgs hard to make. The upcoming Nakamoto release explicitly updates Stacks forking rules and increases the security budget to make it roughly equal to the security budget of Bitcoin L1.
All three issues are important and the various devs and community members have been working towards solutions. Shedding more light on these issues is generally a healthy thing. However, the Blockworks report contains several technical inaccuracies and as a result exaggerates the potential risk of some of these issues. Let’s get into the details:
Inaccuracies pertaining to the stacks-increase bug
Bug Irrelevance to sBTC safety: the report mentions that
“Had this bug occurred with sBTC live, all of the capital in the ‘bridge’ would have been at risk.”
However, this particular bug would have no direct impact on the safety of sBTC for the cycle. The misunderstanding of the report stems from the authors confusing lack of slashing conditions with lack of economic incentives.
Stacking works by locking STX capital in consensus over cycles; one cycle is approx 2 weeks. This locked STX is by far the primary incentive for sBTC signers to act honestly. The BTC rewards are a secondary, much smaller financial incentive. The report confuses lack of slashing with lack of economic incentives. In Nakamoto release, the STX capital of signers remains locked until they honestly fulfil all outstanding peg-out requests. Even though there is no slashing in the protocol, the full-amount of capital remains locked and cannot be withdrawn until peg-outs are honestly processed by the decentralized group of signers. This locked capital is by far the primary incentive for signers, along with a secondary, much smaller incentive of BTC rewards.
The stacks-increase bug resulted in reduced BTC rewards for one cycle, but all STX remained locked for that cycle. If sBTC was live that’d mean that the primary/main incentive for sBTC signers would’ve remained intact during the cyle and sBTC peg-outs would continue to function as normal. The report authors confused lack of slashing conditions with lack of incentives to conclude that the bug would’ve impacted sBTC incentives.
The stacks-increase bug was fixed with an upgrade within 24 hours, which is a great turn around time from open-source devs and community. There were two potential paths for fixing the bug: in path (a) the locked STX capital unlocks for everyone after one cycle, and in path (b) the STX capital could remain locked in the next cycle. Devs and community converged on path (a) as it was simpler. If sBTC was already live then path (b) would’ve been explored more as keeping STX locked in the coming cycle would’ve been more important.
Exaggerated language for funds at risk
During the stacks-increase bug, which is now fixed on the live network, no user funds were ever at risk. Stackers received reduced BTC rewards during the cycle. There is a huge difference between user capital at risk vs. users experiencing reduced rewards while their locked capital is secure.
Finally, the PoX contract has been live for 2 years. It has seen more than a billion dollar worth of STX locked in it and more than $100M in BTC rewards have flown through PoX. This is the first time in 2 years that any bug was discovered in the contract, the impact of the bug was relatively contained: basically reduced BTC rewards for one cycle, and user capital and STX were not at risk due to this bug. The response time to fixing the bug was quite fast and I thought the open-source developers and community came together in a very professional and fair manner to address the issue. For me, the bug response increased my confidence in the ability of the decentralized ecosystem to upgrade the network and respond to any issues.
Confusing MEV with censorship
The tweet thread for the report highlights that there is:
“Mass censoring at the mining layer”
The above statement implies to a casual reader that Stacks L2 transactions are experiencing censorship. There is no censorship at all for the Stacks L2 transactions and L2 blocks. The issue described as “censorship” is a MEV extraction by a single Bitcoin L1 miner. A potential outcome that core developers have been aware of since day 1 of mainnet launch. Even the competing bids by other STX miners are not technically censored; these Bitcoin transactions get confirmed by other Bitcoin miners. What F2Pool is able to do is to not confirm competing bids in their own Bitcoin block and effectively receive STX coinbase rewards at a reduced cost to other miners. F2pool is able to do this because the current rules of the Stacks protocol allow such bids to be valid. The solution/upgrade to this potential MEV is fairly straight forward. The protocol rules can be slightly tweaked where such MEV bids by miners are no longer considered valid by the protocol. In fact, these proposals are already under peer review with open community discussions for several months in the project, along with work on next network upgrade.
As the next network upgrade goes through the Bitcoin MEV issue can be addressed. Any Bitcoin L1 miners attempting MEV mining will be forced to pay bids similar to other miners or they will win no STX rewards and essentially give up on the transaction fee revenue of the bids from other miners. The expected economic value of MEV will go from being positive and profitable to negative and unprofitable (they’d start losing money). MEV only works if there is any money to be made.
The Bitcoin MEV attempts highlight that the Stacks L2 is becoming significant enough for Bitcoin L1 miners like F2pool to attempt MEV. The next upgrde with the MEV removal will only make the Stacks L1 more hardned to MEV attacks. Open protocols that experience real-world attacks, and upgrade and counter such attacks, end up becoming safer and stronger over time. This is how we move towards more mature Bitcoin L2s.
Inaccurate statement regarding reorg upgrades
The report says that:
“The reorg issue doesn’t look to have a solution in sight”
The above statement is inaccurate as the Nakamoto release has concrete proposals for changing the forking behavior of Stacks L2. In fact, the Nakamoto design and SIP-21 (the concrete proposal) was released in Dec even before recent reorgs events.
Reorgs are a fundamental property of Bitcoin (and Stacks in it’s current design). You will never eliminate reorgs but can just make them harder with high security budget. The ability to reorg Stacks L2 is planned to be upgraded with the Nakamoto forking rules, and an attacker will need to fork the Bitcoin L1 to attempt to fork Stacks L2. This can be considered a massive security upgrade to Stacks L2. The reorg resistance security budget of Stacks L2 increases massively after Nakamoto and effectively becomes the same as reorg resistance of Bitcoin L1.
These upgrades to forking rules can also be pushed live through SIPs even before the full Nakamoto release goes live.
Summary:
My read of the report is that it is largely based on open discussions on Stacks project GitHub, forums, and Discord. These things have been known in the community for months, with work being actively done; stacks-increase bug is already addressed, Bitcoin MEV solutions in late stage of being finalized/reviewed, and upgrades to forking rules already proposed in SIP-021 for the Nakamoto release. It’s great to see that the authors took the time to dig in and write about these topics. While the report does a good job bringing more attention to these important topics, it contains technical inaccuracies and needlessly exaggerates certain aspects of potential damage (this is likely based on incorrect technical understanding of the issues).
More attention to open-source code, bug fixes, and public discussions are generally healthy for any decentralized ecosystem and open-source project. These are important topics that should be discussed more in the community. The technical inaccuracies in the report and associated exaggerated language for risks can fuel Twitter drama. We’ve seen this story before with other projects like Ethereum and some growing pains.
Stacks is a very decentralized ecosystem with various independent entities and devs. In the long-term, the only thing that matters is improving collaboration through working groups, maturing the open-source code base, strengthening the decentralized community, and continue the focus on shipping and safety. The opportunity to mature and advance Bitcoin L2s is larger than ever and I’m excited to be part of such a strong, decentralized and open community of devs and believers!
References:
-
[Stacks-increase bug] A bug in stacks-increase call is impacting Stacking rewards this cycle
-
[SIP-21 with Nakamoto rules] SIP 021: Trustless Two-way Peg to Bitcoin by jcnelson · Pull Request #113 · stacksgov/sips · GitHub
-
[Bitcoin MEV] Recent Stacks network behavior and next steps (Bitcoin MEV, orphan blocks)
