Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
jcnelson opened this issue Apr 26, 2021 · 7 comments

Comments

@jcnelson
Copy link
Member

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 jcnelson self-assigned this Apr 26, 2021
@project-bot project-bot bot added this to New Issues in Stacks Blockchain Board Apr 26, 2021
@jcnelson jcnelson removed their assignment Apr 26, 2021
@jcnelson
Copy link
Member Author

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
Copy link

...
* 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
Copy link
Member Author

jcnelson commented May 6, 2021

@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 jcnelson added this to To do in Stacks 2.1 May 17, 2021
@jcnelson
Copy link
Member Author

jcnelson commented May 28, 2021

Prioritization on this:

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

Less easy, but covers the essentials

Nice-to-haves:

@jcnelson
Copy link
Member Author

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

@jcnelson
Copy link
Member Author

jcnelson commented Apr 18, 2022

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 jcnelson moved this from To do to In progress in Stacks 2.1 May 5, 2022
@jcnelson jcnelson changed the title In-band upgrades: vote to extend the PoX sunset [Stacks-2.1] remove PoX sunset and cap unburnt PoX output to be a function of the last prepare phase May 5, 2022
@jcnelson jcnelson self-assigned this May 5, 2022
@jcnelson jcnelson moved this from In progress to Review in progress in Stacks 2.1 May 14, 2022
@jcnelson
Copy link
Member Author

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.

@jcnelson jcnelson removed this from Review in progress in Stacks 2.1 May 23, 2022
Stacks Blockchain Board automation moved this from New Issues to Done Oct 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

No branches or pull requests

2 participants