SIP-015: Upgrading Proof-of-Transfer Consensus

[kantai]

This SIP draft proposes a set of upgrades to Stacking and PoX -- most of the current draft contents cover a proposed pox-2 contract, and how it interacts with Stacking in the stacks-node and Clarity VM. However, this SIP also includes a proposal to address stacks-network/stacks-core#1805 -- some of the PR description text was copied into the draft as placeholder text; clearly that portion of the SIP needs to be more fleshed out. Because this SIP is incorporating that proposal, the draft also lists @jcnelson as an author (who opened the draft PR for addressing that issue).

[jcnelson]

Does this method exist yet? Also, I'm not sure this is a desirable feature (at least, not without a steep early-withdrawal penalty). Part of the appeal of PoX's current behavior is that it compels people to hodl. Also, the number of reward cycles the stacker locks for is a strong signal to miners and the ecosystem that this stacker has full confidence in PoX for the lock-up duration. If we take that away, then it means that everyone is potentially just locking for the next reward cycle (since they can just exit afterwards), and there's not really a point to having a lock-up duration.

[jcnelson]

I think this would be fine if you unlocked your tokens in-between when you locked them and when your first payout reward cycle begins, however (is that what this is for?).

[jcnelson]

Looking at the example below, if the purpose of this method is to facilitate changing the PoX reward address, then why not just have a method to do that with the already-locked tokens?

[kantai]

Does this method exist yet?

Some methods of this SIP have been implemented in next, most haven't yet. But, I think as far as getting feedback on the SIP goes, we should ignore what has or hasn't been implemented: I think feedback on the SIP should inform what and how things get implemented, rather than the inverse.

Part of the appeal of PoX's current behavior is that it compels people to hodl. Also, the number of reward cycles the stacker locks for is a strong signal to miners and the ecosystem that this stacker has full confidence in PoX for the lock-up duration. If we take that away, then it means that everyone is potentially just locking for the next reward cycle (since they can just exit afterwards), and there's not really a point to having a lock-up duration.

This is a very useful feature in and of itself -- obviously, it would break incentives to allow users to unlock during a reward cycle, but before one that hasn't occurred yet shouldn't alter incentives. Rather, without this feature, PoX would encourage users that wish to have the freedom to unlock to only stack for one cycle at a time, continuously invoking stack-extend to get the same support, but with much more overhead (and stress about timing transactions before prepare phases).

[jcnelson]

Rather, without this feature, PoX would encourage users that wish to have the freedom to unlock to only stack for one cycle at a time, continuously invoking stack-extend to get the same support, but with much more overhead (and stress about timing transactions before prepare phases).

I think that's desirable, actually. If you want the option to stack for a shorter amount of time, and want the freedom to decide whether or not to extend in each cycle, then the system should require you to send a transaction in each cycle to extend your lock. Put another way, the system should offer you a better deal for locking up for longer, since you locking up your tokens provides a service to the ecosystem (i.e. you signal confidence to miners that the network will be stable during your lockup). In general, we want people locking up their STX for as long as possible, since it makes liquid STX more valuable, which in turn makes it easier for miners to sell their newly-minted STX at a profit.

[jcnelson]

Under what circumstances would an operator use this method?

[kantai]

If they wanted to increase the amount that they committed, but the increase by itself wouldn't be enough to get another entry in the rewards table.

[jcnelson]

Can this section include the signatures and return values for each new method?

[314159265359879]

the SIP-013 name is also being used here: #42 how do we prevent these conflicts?

[jcnelson]

Yeah -- let's call this SIP 015.

[friedger]

@jcnelson I thought draft sips never have a number until the draft is accepted according to sip-000

[jcnelson]

@friedger You are correct; I'm working under the assumption that SIP 011, SIP 012, and SIP 013 will eventually be accepted, but none of them officially have SIP numbers yet. Also, SIP 000 does not say anything about the order in which numbers are assigned; it only requires that they are unique.

[FriendsFerdinand]

Is this the SIP for the Stacks 2.1 update? I noticed that one of the functions in the proposal (assemble-principal), is already in the stacks-blockchain repo as a PR (stacks-network/stacks-core#2756).

[kantai]

Is this the SIP for the Stacks 2.1 update? I noticed that one of the functions in the proposal (assemble-principal), is already in the stacks-blockchain repo as a PR (stacks-network/stacks-blockchain#2756).

Yep -- this SIP is for 2.1 updates. The PRs in the stacks-blockchain repo should all be open against the next branch, which is where any 2.1 changes will be staged.

[jcnelson]

Okay, so after several rounds of communication in the blockchain meeting and architecture calls, the plan for this SIP is as follows:

1. Get next into a runnable state. Finish all "high" and "very high" pain items on this checklist here: Time estimates for remaining 2.1 work items stacks-network/stacks-core#3096

2. Flesh out this SIP to describe all the consensus-breaking changes in next

3. Add a SIP-012-style Activation section, with the caveat that it's not meant to set a precedent (we'll want to use the "exit-at-block-height" contract once it's ready; it just won't be ready in time for this SIP).

4. Add a testing subsection to the Activation section. Specifically, there should be a public testnet for this version of Stacks that lets us build up enough confidence in the specification and implementation. The Activation section should describe how to measure this confidence, such as:

   • There exist contracts and transactions on the testnet that use or make use of all of the breaking changes, and they all work correctly

   • The testnet boots up and stays alive without any issues for at least X blocks, and with the same or better quality of service as the current testnet

5. Once all of the above are achieved, we'll ask the community to vote to activate this SIP.

[jcnelson]

Closing in favor of #95. Please continue discussion there.