[Stacks-2.1] remove PoX sunset and cap unburnt PoX output to be a function of the last prepare phase

[jcnelson]

Create an extension contract that will allow network stakeholders to vote to extend the PoX sunset window by a fixed amount of blocks. This allows PoX to keep going under "good behavior" from the system, beyond what the 2.0 implementation mandates. I propose requiring 75% yes-votes from all liquid STX, to complement the 25% vote required to disable PoX for a reward cycle. If 75% of the liquid STX vote to extend PoX within a year, the sunset gets bumped by a protocol-defined constant (e.g. 5 years). Protocol constants subject to negotiation.

[jcnelson]

Been thinking about this more -- in particular, the high coordination cost of getting 75% of the STX to do anything at all, and the fact that PoX will start to decay in less than 2 years. I worry that 2 years isn't enough time for the system to really hit its stride, especially since the Stacks Accelerator applicants probably won't start to hit product-market fit right away.

What do we think about this instead for 2.1?

• Lower the threshold to disable PoX for a reward cycle to 15% of all STX
• Make it so you can vote to disable PoX even if your STX are locked
• Make it so a PoX delegate can vote to disable PoX using its delegated STX
• Make it so the "disable-PoX" voting can happen on the Bitcoin chain, as well as the Stacks chain
• Extend PoX indefinitely. The only way to stop it is through always voting to disable for a reward cycle.

The thinking here is that we really only need a vigilant minority of STX holders to watch out for bad miner behavior. I'm not too worried about griefing here, because these STX holders will always have the choice between Stacking their STX and getting a payout, or disabling PoX. Even if all STX are locked in PoX, 15% of all liquid STX still represents 600 reward slots, so this is potentially a lot of BTC that the 15% minority is turning down unless it was for a good reason (note that this is about the size of a "big" Stacking pool, or two "medium" Stacking pools). So, the only way we'd even get to 15% of all STX voting to disable PoX is if something well and truly terrible is going on with PoX -- e.g. Stackers aren't getting paid, miners are rampantly discount-mining, and so on.

What do you think about this approach instead of a sunset?

[314159265359879]

... * Make it so the "disable-PoX" voting can happen on the Bitcoin chain, as well as the Stacks chain

@jcnelson Would you explain a bit more why this is valuable and how it would work?

* Extend PoX indefinitely.  The only way to stop it is through always voting to disable for a reward cycle.

The thinking here is that we really only need a vigilant minority of STX holders to watch out for bad miner behavior. I'm not too worried about griefing here, because these STX holders will always have the choice between Stacking their STX and getting a payout, or disabling PoX. Even if all STX are locked in PoX, 15% of all liquid STX still represents 600 reward slots, so this is potentially a lot of BTC that the 15% minority is turning down unless it was for a good reason (note that this is about the size of a "big" Stacking pool, or two "medium" Stacking pools). So, the only way we'd even get to 15% of all STX voting to disable PoX is if something well and truly terrible is going on with PoX -- e.g. Stackers aren't getting paid, miners are rampantly discount-mining, and so on.

What do you think about this approach instead of a sunset?

I like this approach, I think I am missing some of your assumptions because 15% of the total (unlocked) supply (~1100 M stx) is about 160 M stx now and about 200 M stx at the end of the year while the biggest pools on stacking.club show 36 M stx.

[jcnelson]

@jcnelson Would you explain a bit more why this is valuable and how it would work?

You can vote to disable PoX for the next reward cycle using your STX. But right now, this happens through a Stacks transaction. Because the only reason to vote to disable PoX when you could be Stacking is to prevent miners from discount-mining, the miners won't mine your disable-PoX transactions. By instead recording them to the Bitcoin chain (as we currently do for stx-transfer? and stack-stx, for similar reasons), we can side-step this problem and compel miners to accept that they won't get a PoX discount in the next reward cycle.

I like this approach, I think I am missing some of your assumptions because 15% of the total (unlocked) supply (~1100 M stx) is about 160 M stx now and about 200 M stx at the end of the year while the biggest pools on stacking.club show 36 M stx.

It's 25% right now. I welcome pushback on this -- the number needs to be high enough that someone can't just grief the system, but low enough that the system has a chance of overcoming rampant discount-mining.

[jcnelson]

Prioritization on this:

Easiest and fastest, all-else-fails, we-run-out-of-time-before-2.1:

• Push back the sunset-begin deadline by at least 2 years
• Implement #2612 to allow users to force an upgrade that extends it again

Less easy, but covers the essentials

• Push back the sunset-begin deadline by at least 2 years
• Implement #2612 to allow users to force an upgrade that extends it again
• Add on-BTC voting to disable PoX

Nice-to-haves:

• Extend PoX forever
• Add on-BTC voting to disable PoX
• Make it so stacked STX can vote to disable PoX
• Implement #2612 to allow users to renegotiate this

[jcnelson]

I think the decision we landed on was "extend PoX forever" and "make it so stacked STX can vote to disable it."

[jcnelson]

Another update on this: "extend PoX forever" is definitely on the table, but trying to use (reject-pox) to control discount-mining isn't very rigorous, or even much of a deterrent. We should both remove the sunset, and cap the upside for discount-mining at the consensus level (#3095). No need to modify (reject-pox).

[jcnelson]

Okay, we've landed on a solution:

• keep reject-pox as-is
• remove the sunset

The sortition weight windowing already does a good-enough job at making discount-mining very difficult and expensive -- so much so that we feel confident that we don't need to address it in 2.1 (but might in a future network upgrade). We'll revisit this then, so I'm going to re-tag this as stacks-future.