[Stacks 2.1] Anyone opposed?

Hey folks,

As part of getting ready for Stacks 2.1 activation, we were wondering if there is anything about Stacks 2.1’s feature set that you’re opposed to? Just wanted to check in on this now, while we have a chance to make changes.

Please note that this is not an ask for additional feature requests (we’re aiming for system activation before the year’s end). We’re mainly interested if there are any blockers to activation once the vote begins, so we can get them addressed first.

I haven’t heard any pushback myself, but I don’t want to discount the possibility that it exists.



For those new to Stacks 2.1, here are two posts about what’s happening with the latest upgrade:

Stacks 2.1 overview: Stacks 2.1: Strengthening The Connection to Bitcoin

More Stacking improvements: A Closer Look at 2.1: Stacking Improvements


One question I have on 2.1 is with the PoX sunset being removed. Was there a consideration of postponing the PoX sunset as opposed to removing the PoX sunset. Postponing rather than removing the sunset would allow for another opportunity for all network participants to actively consider one more time if PoX sunset must be removed.

One concern I have is whether PoX allows a Stacks miner that has a large bitcoin mining operation to gain an unfair advantage over a Stacks miner that does not have a large bitcoin mining operation.

While in theory this could be argued to be a nothing burger as any advantage that is gained is extremely short lived and therefore unsustainable, given the block rewards for Stacks are rather small at this point in time, I am assuming Bitcoin miners with large operation are not yet incentivized to consider mining Stacks. This dynamic could change drastically as the Stacks network grows larger and any game theoretic advantage pertaining to this may simply not have had enough time to come to light in practice.

Given this I wonder if having another opportunity to automatically sunset PoX might be better for the network long term.

Hey @muthu.btc, thank you for your feedback!

Right now, if 25% of all liquid STX decide to disable PoX for the next reward cycle, it gets disabled for a reward cycle. This behavior is carried over to Stacks 2.1. The Stacks 2.1 upgrade would simply remove the automated sunset in favor of relying on this mechanism as the sole means for policing bad PoX behavior on the part of Bitcoin miners or Stacker-miners. If the community believes that switching PoX off for the long-term is the best thing to do, they already have the power to do so. I truly believe this is for the best – I don’t think it’s my place (nor is it the place of SIP officers) to decide when or if to switch off PoX, since the blockchain belongs to its users.

If Bitcoin miners decide to get involved with Stacks, such as by censoring all Stacks operations besides their own, then in a subsequent network upgrade we’d probably re-format the block-commit Bitcoin wire format so it’s indistinguishable from a Bitcoin transaction (i.e. by embedding all the relevant data in ostensibly-spendable UTXOs, instead of an OP_RETURN), and come up with a verifiable way for miners to rotate their addresses on each block-commit while doing UTXO chain-tracking. The reason we don’t do this right now is because it isn’t healthy for the Bitcoin network. Bitcoin nodes everywhere would have to track all of these ostensibly-spendable UTXOs, which bloats their mempools and bloats the state that Bitcoin explorers must track. But, it’s a way to keep the system running – if Bitcoin miners can’t tell the difference between normal Bitcoin transactions and Stacks miner transactions, then they can’t feasibly censor them.

SIP text for Stacks 2.1 is now online: sips/sip-012-cost-limits-network-upgrade.md at main · stacksgov/sips · GitHub

I have some objections about incomplete changes to how delegators can delegate stacks.

The correct link to the SIP text is sips/sip-015-network-upgrade.md at dea3102ac50fb7776a73b2c0b48151ee0fc12c61 · stacksgov/sips · GitHub

The SIP15 dea3102 commit is already outdated. Instead, review the SIP15 draft and join the PR conversation.