Disable stacking in the prepare phase?

[jcnelson]

The PR #4094 from @friedger removes stacking from the prepare phase. I don't know that this is the right thing to do, so let me lay out what I believe are the pros/cons:

Pros:

• Users aren't surprised when they don't receive PoX payouts immediately after stacking

Cons:

• Breaks backwards compatibility
• Users may still send a transaction that fails inexplicably, leading them to believe that they are stacking when they are in fact not

Personally, I'm against #4094 because I think it's the wallet's job to inform the user as to when they can expect to receive PoX payouts. Also, #4094 cannot prevent users from trying to stack, meaning that they can be lead to believe, erroneously, that they are stacking when in fact they are not. However, I could be convinced otherwise. Either way, this is a SIP-level design consideration that deserves some more discussion.

[friedger]

In pox-3, the difference between a successful stacking transactions (and its pox-3 events) that earns rewards and that does not earn rewards in the next cycle is the block height of the tx.
That is counter intuitive.

The hard fork breaks backwards compatibility in a few senses (e.g. signing responsibility).

Furthermore, the current wallets, pools and apps try to prevent this already on the UI level, enforcing it on the protocol level would not break the user experience, but improve the experience for developer.

[friedger]

Wallets can't prevent pending txs in mempool to be confirmed in the prepare phase.

[jcnelson]

Yes, correct. The consequence of this with this change is that instead of your STX getting locked for the reward cycle starting in two weeks (instead of the one starting tomorrow), nothing happens except you lose your transaction fee. I'm arguing that this is actually a worse UX, because this failure mode results in a state that does not reflect the user's intentions, and there is no way to inform users when this happens unless the user deliberately waits for the transaction to confirm.

[friedger]

I see. So the user does not care whether the user becomes a stacker for the next cycle or the one after?
Does the ecosystem care about these stackers? How do they help the network, sign blocks if they don't check the status of their ("registration") txs

[friedger]

Furthermore, for stackers that care about their next cycle, they not only have to check the tx status but also the block height and compare with the current prepare phase block height in order to know whether they are part of the next cycle. Why make it harder for these stackers?

[jcnelson]

The fact that the stacking transaction can sit in the mempool for up to 256 Bitcoin blocks means that there's always going to be a chance that the user misses their targeted stacking cycle. This is true with or without #4094, and would be true regardless of whether or not we removed the block height comparison.

The question I think that needs answering is thus: if the user's stacking transaction is mined but misses its target reward cycle, then what is the least surprising thing the system should do? Given that the user is already willing to lock up their STX for a non-trivial amount of time (which is a strong signal given that locking STX incurs lots of price risk), I'm of the opinion that the least surprising behavior is the current behavior -- the user's STX will still get locked, but for an extra 2 weeks since they effectively stacked at the beginning of the current reward cycle. This is still surprising, but it is also straightforward to warn the user in advance of this risk: if the user tries to stack within 256 Bitcoin blocks of the PoX anchor block, then there is a chance that this outcome will happen and the user should check to see that their transaction confirms.

[setzeus]

Note reviewing this discussion: #4157 is down-stream from here so let's discuss any logic encapsulated in that issue as well.

[friedger]

#4157 is not related, should be a different discussion

[friedger]

Looking at Stacking DAO, there users can even "stack" after the last "commit" of the pool. There is no cut off at all for a cycle.

This makes things easier for users, but worse for accountants. I still think that we shouldn't allow any stacking activity during prepare phase.