PoX Event Generation Issue

[BowTiedDevOps]

When a stacking transaction is made in the prepare phase of a cycle, the event that is being displayed is incrementing the start-cycle-id variable by 1, but not the end-cycle-id, hence making the 2 variables show the same cycle.

Reference transactions:

• stack-stx call where this happens: https://explorer.hiro.so/txid/0xf92194a3ceaaa6e338150584dfe73c1a73dfcced0d9f04314fa855e94edeba89.
• Normal stack-stx call: https://explorer.hiro.so/txid/0xee4667bcac49fcb169c8902e96565f56ec201864d1d1c0f11668e73f53977549
• Normal stack-stx call: https://explorer.hiro.so/txid/0xd472f61263fdad0234fd011ad0f319bc1ffb348688319885364e041410890430

This might not be an issue at all, and actually be the expected behavior. A suggested fix by @janniks in order to increase clarity in the events would be to add an stacking_cycles entry to the event that would show how many cycles is the user stacking (end-cycle-id - start-cycle-id). In this case, that would be 0, because the user will not be stacking.

[wileyj]

@hstove thanks - usually i report and block spammers from the org as well (already done)

[hstove]

There are a few things here:

• unlock-burn-height doesn't use the pox-set-offset var, which accounts for stacking in a prepare phase
• end-cycle-id uses unlock-burn-height, which is the cause of end-cycle-id being incorrect in this instance

I think the fix is relatively easy, but I'm not sure how much impact this has downstream.

Another thought for a workaround is that, for stack-stx, you can basically always just use start-cycle-id and lock-period to determine the unlock cycle. Both of those are correct in the examples listed above.

[janniks]

Careful. This was the intended behavior. It is confusing, yes.

The “end” cycle is non-inclusive (range style). This way a event that didn‘t make it into the intended reward cycle has it‘s start-cycle-id shifted. If the start and end fall on the same cycle-id, this is how the event let‘s us know the stacker didn‘t make it into any reward set. If stacking for multiple cycles, (and in prepare phase) the start is shifted still, but there will be a valid range where the stacker should make it into the next reward set.

Hope that helps — we could make the UX better by calculating the cycles for the stacker or otherwise displaying that the event was in a prepare phase and needs to be treated differently. So far these fields were mainly intended for downstream machines to query by valid ranges. Less for human eyes.