Stacking: a New Consensus Algorithm for Blockchains

The PoX protocol, by design, does not know which miners exist a priori, and therefore cannot assign miners an address to send to. It only assigns addresses to blocks, which any miner(s) must send to whether they like it or not.

Such a scheme could only work in conjunction with a “miner registration” system whereby miners announce their intentions to mine on a particular block. Such a scheme would also be extremely risky, since it would enable free-mining if miners had any freedom to choose which addresses they could send to – they’d only ever send to themselves, or at least try and bias it so that their addresses have a better-than-random chance of being selected. The fact that miners must send to a particular set of address that they cannot choose is a feature, not a bug.


With this proposal the protocol wouldn’t need to know which miners exist a priori. Each miner would take the seed for the round and combine it with their own address and the list of recipient addresses to deterministically figure out the recipient they need to send to.

This is proposed to be in combination with a pre-commitment process with collateral, which seems to be required anyway to prevent gaming. If this pre-commitment with collateral is implemented, then opportunistic free-mining would not be possible.


I think it’s a clear upgrade to SIP-001 as well!

I’m going to boil down the above discussion into a few topics and then comment.

Discounted Mining:

We plan to update SIP-007 with a discussion on discounted mining. I think “free mining” is a potentially misleading term for this because the discount is in the 10-20% range given no. of slots and the probability of the discount being 90% or whatever is negligible.

A miner’s main motivation to mine should be the STX coinbase, transaction fees (in STX), and Clarity contract fees (in STX). This decision to mine or not mine needs to be made by the miner for the vast majority of the blocks (where the miner does not have an address) and the miner will decide to mine if it’s profitable to do so.

No miner will mine at a loss, it’s about how much profit can a miner make. It’s a local decision that every miner makes, a miner will not even know if someone else is engaging in discounted mining or not.

Sporadic Mining:
If a miner decides that it only makes sense to mine in blocks where she has a payout addresses then that will likely result in sporadic mining where say that miner is participating only in a small subset of blocks.

First, I think the miner does not have the right incentives to participate in sporadic mining. The STX coinbase is not a guarantee but a probability. If you mine sporadically then you are potentially hurting your chances to get the STX coinbase vs mining regularly.

Secondly, you can make it harder for miners to participate in sporadic mining. You can introduce a minimum participation window. For example, if you don’t participate in at least 10 consecutive blocks as a miner then you don’t qualify for the STX coinbase at all. This takes the 10-20% discount to a 1-2% discount and can make it even smaller by increasing the size of the minimum participation window.

Interestingly, an earlier version of STX mining had a window and we got rid of it due to some potential unintended consequences. It might be worth exploring if a modification of a sliding window in the form of a “minimum participation threshold” makes sense.

Thanks for the discussion around discounted mining! It definitely opens interesting discussions and design tradeoffs.


For any readers following along I think it’s important to put some of these in a more practical/realistic scenario.

Practical Scenario: Let’s say a miner is willing to put up significant capital, say $1M, to take advantage of discounted mining. At the current ~$0.10 price that is roughly 10M STX or 2.0% of the liquid supply (current circulating supply is ~508M STX). 2% of liquid STX means that this miner now gets 100 out of ~5000 slots for a payout and would need to make a decision about mining (or not mining) in the vast majority of the blocks where the miner does not have an address.

Also, it’s unclear to me if this behavior is net negative to the ecosystem, especially in the initial year(s). There are crypto-assets like BNB (Binance) where holders of BNB get a discount on trading. Miners who want to use discounted mining are providing value to the network by becoming longer-term holders. There is very clearly a cost to the miner for locking $1M USD in Stacking to get discounts vs using that money somewhere else.

The sliding window mentioned above (which was part of an earlier design for a different reason) addresses this issue anyway but it’s interesting to explore what positive/negative impacts this miner behavior can have.


We debated the two designs and their pros/cons. Ultimately the question is that do we want a system that behaves more like a lottery or a system that behaves more like “I hold STX and do work that is useful to the network and get a predictable payout from the network each month”.

We can certainly discuss modifications to the two approaches where they start looking a bit more like each other but the lottery vs predictable monthly payouts for work is a central design question. SIP-007 is in the camp of predictable monthly payouts for work. Interesting to explore randomness and how that impacts potential Stackers and their incentives.

I like the data reduction aspect of this. The 5000 miners number looks very high to me and might not be realistic, especially in the initial year(s).

Large crypto projects struggle to get full-nodes in that range and having independent miners in 5K range is even harder. We’re currently debating a minimum threshold for no. of miners that can trigger a switch from Stacks 1.0 to Stacks 2.0 and are debating 10-20 miners as a range.


Glad you like that! Would be awesome to cut the data usage in half.

The part I think is an even bigger improvement with the proposal is the enormous increase in payout frequency.

(I used the 5000 figure for number of miners but we can do thought experiments with other orders of magnitude)

Let’s assume 5000 addresses at 0.02% holdings each.

  • w/ 50 miners, each address would get paid out every 100 blocks vs every 1000 blocks (10x)
  • w/ 500 miners, each address would get paid out every 10 blocks vs every 1000 blocks (100x)
  • w/ 5000 miners, each address would get paid out once per block vs every 1000 blocks (1000x)

And all that with 1/2 the amount of data transmitted on the blockchain.


Here are some charts to help visualize the payout schedule:





With these visualizations, I chose to go simple and assume the randomization always places one in the middle of the set. A better visualization would show proper randomization, leading to a more unexpected placement of the spikes. But the basic differences in variance would be the same, so this should properly illustrate the point.


I don’t understand this. Can you explain? What are “user support” burns?

1 Like

Per SIP 001, anyone can burn (not transfer) BTC in support of another block-commit in the same block. The idea is that if there are users (i.e. non-miners) who want a particular block to have a high chance of winning, they can “help out” the miner by burning some BTC in favor of that block. By making a separate transaction type for doing this, users don’t need to coordinate with one another or with the miner to do so – they can do it spur-of-the-moment just by looking at the (Bitcoin) mempool and looking at the unconfirmed block-commit transactions.

The reason users would want to do this at all are two-fold:

  • Users get a fraction of the coinbase proportional to their contribution if the block they support wins.
  • If there’s a miner-based attack ongoing like a selfish mining cartel, users can tip the balance of power towards the coalition of honest miners in order to harm the cartel.

User support burns not only get us decentralized mining pools, but also in doing so, give users a greater say in the evolution of the chain state.


@shea256 Hi,

Good coding idea, just to add sort of a script pool that would relay on a node and support every stackers while running in parallel with the miner client.

Could big monied “whale” miners/users also use this to tip the balance of power towards their own or other miners? This would be easier/faster to do than spinning up mining hardware, so does this make one type of attack easier?

1 Like

There’s no mining hardware in the first place beyond your laptop, so it doesn’t make it any easier than simply running a miner themselves. You’re right in that someone with a lot of BTC could out-mine everyone else, but that’s true with or without user burn supports.

Also, a subtlety – a whale miner would have to out-burn everyone else for at least N Bitcoin blocks in order to execute an N-deep reorg. It’s not enough that a whale can just out-burn everyone else; they have to do so consistently. This is a departure from traditional PoW systems, which rely on the most work done (even if the resulting fork has fewer blocks). It’s possible to do this safely in Stacks because unlike PoW blockchains, all Stacks peers have a global understanding of time (i.e. Bitcoin block height), which allows them to measure a fork’s quality as the number of sortitions it contains.


Does it make sense to limit any one whale miner or pool to be able to commit to PoB/PoX at most 49% of the total committed for a given block? Or it’s irrelevant because they can have more than one miner anyway? While the number of Stacks nodes and miners are low in these early days does the Stacks chain have any more or less risk, relative to other alt’s, of being sort-of DDOS’ed/forked via malicious miners with either financial or political motivations? I imagine you guys did much work on this type of subject, just curious about the general topic of chain resistance to attack compared to other designs - especially the Stacks 2.0 implementation.


It’s not possible in general to do this, since a whale can just run many miners.

In general, chains with lower mining power will be easier to attack. However, the Stacks chain has a couple of countermeasures (described in SIP 001):

  • The canonical fork is the longest fork for which you have data, so it’s not enough to just spend BTC. The attacker has to out-spend everyone else for at least as many sortitions as required to carry out a reorg at the desired depth.
  • All fork histories are written to the underlying burn chain (Bitcoin), so you can always see the attack spinning up before it hits.

Both of these properties make it possible for users and exchanges alike to predict how deep a transaction needs to be confirmed before being considered stable. As a general rule of thumb, a transaction that is worth $X would need to be confirmed such that the expected cost to reverse it by spending BTC exceeds $X. Note that in PoX if there’s contention as to which fork is the canonical fork, all BTC is burned, which means that there’s no way for the attacker to avoid out-spending everyone for a long time.


will BTC committing by PoX miners be just using on-chain BTC or also an option to use Bitcoin Lightning channel “promises” (transfers)? I’m wondering about the implications, if it’s possible/desireable, regarding Lightning’s improved speed, Tx fees, and reducing the PoX miner related Tx load on the bitcoin chain.
I suppose to do this a Stacks Node would have to be able to receive Lighting payments from the miners? It would be too problematic/difficult to implement?


We looked at lighting channels (between BTC and STX chains) as a potential solution. The summary was that it’ll require some modifications to current lighting protocol/implementation. We decided to side-step that problem by having a minimum threshold of Stacks holding (to reduce transactions on the Bitcoin chain). Pooling or delegating helps people below the threshold participate on the stacking side while the transaction bandwidth requirements on the Bitcoin chain remain realistic.

With that said, exploring such cross-chain lighting channels is certainly an important area of future work!


Maybe we’re talking about more than one thing. A min STX threshold reduces impact on the bitcoin chain, ok. But another thought…
A bitcoin miner can increase or decrease hash-power instantly since mining rigs can be turned on/off and electricity is always instantly available. A PoX miner has a potential delay of 10-60 minutes or more if they don’t already have sufficient BTC in their mining-wallet. A thought was wondering if a PoX miner had a Lightning wallet they could receive BTC instantly and could turn mining on/off instantly by committing the lightning delivered BTC.
And if a Stacking node (holder) also had a Lightning wallet they could receive the BTC rewards from the PoX miner instantly off-chain.
This would not only reduce impact on the bitcoin chain but perhaps remove extra costs for the PoX miner due to near zero BTC Tx fees.
How might PoX mining be impacted when BTC Tx fees shoot up?

Btw, perhaps you/team already knows but Blocksteam’s LN implementation has plugins which might allow needed extra functionality? >> See “Extensibility and Customizability through Plugins” at


Thank you Jude for your detailed answer! Great article by Muneeb on the website too!

Anyway, please excuse my ignorance in advance, but let’s say that in the future a new block-chain would become even more secured and prevalent than the Bitcoin: I wanted to ask you what would it take to switch from Bitcoin to that new block-chain? Who needs to validate this change? How does governance operate? Thank you in advance for your time!

I admire the flexibility and pragmatism approach of Blockstack. Blockstack has an extraordinary commitment to doing the right thing:


1 Like

I’d recommend you search the online docs and/or online and here in the forum about the “blockstack virtualchain” designed to make it easier to switch the base chain if needed. Governance outside of Blockstack PBC is a topic of open discussion yet to be defined. See the governance channel on Discord and the topic here on the forum. Short video What is a Virtual Chain?


Thank you @fluidvoice for the generosity and extensiveness of your answer. Very valuable indeed! I wish you well, Rapha

1 Like