Contents
Stacks is a Bitcoin layer that is about to undergo a major network upgrade called the Nakamoto upgrade. This upgrade comes with 3 headline-worthy changes:
- 100% Bitcoin finality: Stacks will offer 100% Bitcoin finality, increasing the security guarantees of the network.
- Faster blocks: Stacks confirmation times will go from ~10 minutes (the mining of a new Bitcoin block) to seconds.
- sBTC-enablement: Nakamoto paves the way for sBTC, an upcoming fully programmable BTC asset, that will fast follow in a second network upgrade.
In this post, we’re going to break down that first bullet point and talk about Bitcoin finality, what it means, and how it actually works on Stacks.
What Is Bitcoin Finality?
On Bitcoin, transaction confirmation is probabilistic, not absolute. By that we mean, transactions on Bitcoin aren’t immediately confirmed in the way we might think of an online confirmation when you buy something with a credit card.
Bitcoin finality refers to the point at which a Bitcoin transaction or a block of transactions is considered permanently confirmed and cannot be undone or changed.
Instead, Bitcoin transactions are mined in a Bitcoin block, and then that block is confirmed by subsequent blocks. With each subsequent block, it becomes increasingly difficult and economically impractical to reverse or alter that transaction, whether due to a blockchain reorg, a 51% malicious attack, selfish-mining, or some other behavior.
Bitcoin finality refers to the point at which a Bitcoin transaction or a block of transactions is considered permanently confirmed and cannot be undone or changed. It is said to be permanent because at a certain point (typically after 6 confirmations, or blocks, in the context of Bitcoin) the economic cost (in terms of computation and electricity) outweigh any potential benefits for a rational actor to attempt to re-org the chain. The economic cost of attacking a chain is also referred to as that chain’s security budget.
For proof of work blockchains like Bitcoin, the security budget is determined by two factors:
- Hash power distribution: the distribution of mining power. The more decentralized the network, the more difficult it is for any single entity to control the majority of the network’s computational power, which opens the door to attack vectors like censorship or a 51% attack.
- Network difficulty: the difficulty of mining. This difficulty adjusts every two weeks (or every 2,016 blocks) for Bitcoin. Higher difficulty requires more computational resources to mine new blocks, which in turn makes it harder and more expensive for malicious parties to attack the network.
To play out a scenario in which a bad actor attacks Bitcoin’s security budget, check out this study from independent researchers.
Why Do We Care About Bitcoin Finality?
Finality is important for causally dependent operations. For example, if Alice sends BTC to Bob, and Bob wants to send some of that BTC to Charlie, Bob wants to be really sure Alice’s transaction won’t be reverted.
Bitcoin has withstood the test of time and sustained attacks and bans from individuals and even nation-states, and the chain has survived. To say something has Bitcoin finality carries a lot of weight.
“Bitcoin finality” is the gold standard for the industry.
Because of that, we can think of “Bitcoin finality” as a gold standard for the industry. It is a strong assurance for users that their transactions won’t be reversed after a set period of time.
But Bitcoin is also slow, and blockspace is limited. So there are a lot of projects building on Bitcoin that are trying to make Bitcoin more usable (faster confirmations and better scalability) and programmable (enabling Bitcoin apps), all while keeping Bitcoin finality.
Bitcoin is successful because it is decentralized and secure; users want to know whether the same is true for any project building on Bitcoin—does a transaction on the L2 offer the same finality guarantees that a transaction on the Bitcoin L1 does?
In the case of Stacks, it does.
Understanding the Bitcoin <> Stacks Connection
With the upcoming Nakamoto release, Stacks will have 100% Bitcoin finality. At a high level, this means:
- Stacks inherits the security budget of the Bitcoin blockchain.
- Stacks transactions have Bitcoin finality in the same way that Bitcoin transactions do.
- The Stacks blockchain does not fork on its own.
Let’s get into the details to unpack what exactly that means and how it’s possible.
How Does Bitcoin Finality Work on Stacks Post-Nakamoto?
When we say Stacks has “Bitcoin finality”, we mean that it is as hard to reverse a Stacks transaction as it is to reverse a Bitcoin transaction. This does not mean that Bitcoin miners are processing or validating Stacks transactions.
There’s a few different components that make this statement true, so let’s break that down into 3 parts:
- How Stacks miners are elected
- What Stacks info is stored on Bitcoin
- Simplified fork rules
When we say Stacks has “Bitcoin finality”, we mean that it is as hard to reverse a Stacks transaction as it is to reverse a Bitcoin transaction.
How Stacks Miners Are Elected
While Stacks has Bitcoin finality, Stacks miners are not the same as Bitcoin miners. Stacks has its own consensus mechanism called Proof of Transfer that couples the election of Stacks miners with Bitcoin blocks. The Nakamoto release makes some changes to Proof of Transfer around how mining works that enable Bitcoin finality.
Previously, Stacks miners bid BTC for a chance to mine the next Stacks block, and the winning miner would be selected by a VRF sortition process. Miner selection occurred for each Stacks block, which meant that at best Stacks block production was as fast as Bitcoin block production (1 new block every ~10 minutes). See SIP-001 and SIP-007 for more details.
The election of Stacks miners can be independently verified using Bitcoin chainstate.
In Nakamoto, miners still bid BTC, and a VRF sortition selects the next miner, but instead of just mining the next block, the new miner is elected and acts as a miner for the duration of its “tenure” (the time until the next mined Bitcoin block). During that tenure, the miner can produce new Stacks blocks every few seconds.
To recap, in order to mine Stacks blocks, Stacks miners must submit Bitcoin transactions on the Bitcoin L1, which means that you can verify the election of Stacks miners with data on Bitcoin.
Wait, how does miner election relate to Bitcoin finality? Hold on, I’m getting to that.
Stacks Miners Store Data on Bitcoin
Why this election process is relevant is that it forces Stacks miners to transact on the Bitcoin L1, and in that transaction, the Stacks miner includes data about the Stacks network.
In particular, the aspiring Stacks miner sends a <code-rich-text>block-commit<code-rich-text> transaction on Bitcoin to bid on the chance to be the next Stacks miner, and in this <code-rich-text>block-commit<code-rich-text> transaction, they also include the index block hash <code-rich-text>StacksBlockID<code-rich-text> of the first block produced by the previous Stacks miner’s tenure.
In other words, the act of mining a new Stacks block ensures that a snapshot of the entire causal history of the Stacks chain up until the beginning of the previous miner’s tenure is included in the corresponding Bitcoin block.
This has two consequences. First, this means that if someone tampers with Stacks state, it can be easily caught by cross-checking against Bitcoin state. To not get caught, someone would need to tamper Bitcoin state too, which is prohibitively expensive.
Second, this enables the Stacks blockchain to no longer fork on its own (which we will get into in the next section), ensuring that there’s only ever one chaintip that Stacks miners can build from at any point in time.
This is how the Stacks chain establishes Bitcoin finality.
Note: only a hash of a Stacks block is included in every Bitcoin block—Stacks isn’t using Bitcoin as a full data availability layer. Anyone running a Stacks and Bitcoin node can use this hash to verify Stacks chainstate, but you can’t verify Stacks chainstate just by looking at Bitcoin alone.
Simplified Fork Rules
In Proof-of-Work chains like Bitcoin, you can have multiple competing chaintips at once. When a miner mines a new block (n+1), it must propagate that new block to the network, but there is latency in that propagation. During that time, it is possible for another miner to successfully mine n+1 as well, creating a fork in the chaintip—now there are two different n+1 blocks.
Nodes accept the longest chaintip, so eventually one of these forks will “win” and become the canonical fork, causing a reorg in the blockchain. Forks are normal in many blockchain ecosystems, and in the case of Bitcoin, they occur ~once a week.
One of the biggest changes coming with Nakamoto is a simplification of how Stacks and Bitcoin fork. In short, the Stacks blockchain will no longer fork on its own and will only fork if Bitcoin forks.
This is made possible by the introduction of a new actor to the Stacks ecosystem: signers. Like Stacks miners, signers are a permissionless, open network that anyone can join, and these signers decide whether or not a block proposed by a miner is included in the Stacks chain or not.
The Stacks blockchain can no longer fork on its own.
Importantly, signers will only accept blocks that are added to the canonical Bitcoin chain tip and created by the elected miner, preventing miners from forking the Stacks chain off the longest Bitcoin chaintip. If a miner proposes a new block on top of a stale Bitcoin chaintip, the signers will reject that block.
These signers are incentivized to behave rationally because they earn PoX rewards (paid out in BTC) when they do their job (and receive nothing if they do not), and miners are incentivized to behave rationally by earning STX rewards from mining blocks (and they’ve already put in their own capital in order to be elected as a miner in the first place).
In the event of a Bitcoin reorg, the Stacks chain will automatically reorg to match, preventing any divergence between Bitcoin and Stacks. If a Stacks transaction is affected by a reorg, it simply re-enters the mempool and gets mined again. This is exactly how Bitcoin reorgs affect Bitcoin transactions.
In other words, just like you shouldn’t consider a Bitcoin transaction final if it’s near the chain tip, you shouldn’t consider a Stacks transaction final if it’s near the tenure tip. And as more Bitcoin blocks confirm a given Stacks block, the finality of Stacks transactions becomes increasingly secure, just like Bitcoin transactions.
There’s future work the ecosystem can add in the future to improve these forking rules further, such as adding taint analysis and replay enforcement. But for launch, this simplified structure ensures that there’s only ever one optimal Stacks chaintip at any point in time.
What Does Bitcoin Finality on Stacks Mean for You?
For developers, these changes offer robust security guarantees and a simpler model for finality on Stacks. That comes with benefits.
- Improved security: With forking dis-allowed on Stacks and miners posting block hashes to Bitcoin, you can be more confident in the security of your app and the finality of transactions.
- Better UX: The new mining process will lead to faster and more predictable block confirmations, improving the user experience.
With this release, Stacks is making a bold move towards creating a more secure and dev friendly blockchain ecosystem. If you want to learn more about the connection between Stacks and Bitcoin, check out the Nakamoto SIP here.
