Prevent stacking transactions if they will start after a given cycle starts, but ends during the same cycle

[aulneau]

Pascal has shared with me a couple of reward addresses on stacking.club that seemed a bit off:

https://stacking.club/reward-address/34HkER8BTnD5cyAumsU9p7Ls6RjDUbuavb/5 https://stacking.club/reward-address/1K4nSvHEae3G9DRdwJsEf4UWpZQgA2RjuE/5

The first address intended to lock from cycle 1 until cycle 4, and the second address meant to lock for only cycle 5. However, both of these addresses actually ended up locking just shortly after the start of each of the cycles they intended for. The until-burn-height value didn't change, and the lock-period is also unchanged.

I was trying to understand how this could happen -- I assumed the wallet would prevent this kind of thing from happening (if they did indeed come from the wallet).

I think we should try our very best to prevent this kind of behavior from happening. Some options:

• if the current burn block height is of the start of a cycle, cancel the transaction
• if the current burn block height is in the prepare phase, prevent folks from locking for that cycle

[kyranjamie]

Indeed, the wallet doesn't currently validate for these scenarios.

It'd be really helpful to incorporate these edge cases/error flows into the latest designs, so we can handle them as gracefully as possible in the coming changes cc @jasperjansz

[markmhendrickson]

The problem here is essentially that users think they can lock at the start of given cycle for that cycle onwards, but they end up locking for the next cycle onwards, correct?

If so, perhaps the UX here could be simply a warning e.g. It appears you're trying to lock at the start of a cycle / in its prepare phase. This means you won't actually become eligible for rewards until _next_ cycle (in about 14 days). Are you sure you want to proceed?.

More broadly, it'd be worth thinking about how we can improve the UX around locking ahead of any given cycle as it approaches. Currently users have to set themselves a reminder outside of the app so they don't miss the cut-off time. Perhaps we can provide an optional reminder mechanism or something – or simply splash a large message on the wallet homepage with a countdown when it approaches each time.

https://stacking.club/reward-address/1K4nSvHEae3G9DRdwJsEf4UWpZQgA2RjuE/5

With this case in particular, did the user try to initiate at the start of the 4th cycle and end up getting committed to the 5th? The page suggests they did successfully participate in the 5th cycle:

[aulneau]

The page suggests they did successfully participate in the 5th cycle:

There is a bug that I will be fixing this week in how the cycles are calculated on stacking.club. The screenshot you posted will ideally say Cycle #4 to #4.

With this case in particular, did the user try to initiate at the start of the 4th cycle and end up getting committed to the 5th?

For this one, the user locked 13 blocks into the prepare phase of cycle 4, you can see the transaction has a start-burn-ht of 674373, but the 4th cycle started at height 674350. The transaction also has a value of 1 for the lock-period (meaning how many cycles to lock).

Ideally the wallet would have said "hey, this is the prepare phase, it's too late for you to lock and get a slot for cycle 4, but we can adjust it so you'll lock for cycle 5, too."

[jasperjansz]

the "next cycle starts in" should always reference the start of the next prepare phase, not when the reward phase starts.