slot index and reward index mismatch

[friedger]

Describe the bug When querying burnchain_rewards and reward_slot_holders the reward_index and slot_index do not match. Example

859045 slot 0 => 31yuSoYmpkV5TDxuMh2GUfchJFef4kHyus

859045 slot 1 => bc1qs0kkdpsrzh3ngqgth7mkavlwlzr7lms2zv3wxe

859045 reward index 0 => bc1qs0kkdpsrzh3ngqgth7mkavlwlzr7lms2zv3wxe

859045 reward index 1 => 31yuSoYmpkV5TDxuMh2GUfchJFef4kHyus

To Reproduce Steps to reproduce the behavior:

1. run sql query select * from reward_slot_holders rsh where canonical and burn_block_height = 859045
2. run sql query select * from burnchain_rewards br where canonical and burn_block_height = 859045
3. Compare addresses and see that they do not match

Expected behavior Address in reward_slot_holders and reward recipient in burnchain_rewards should be the same for the same slot index.

[janniks]

@obycode do we know if these should be matching from a blockchain core perspective? I'm not sure if the concepts reward index and slot are equivalent everywhere.

[janniks]

Looked up where they come from on the API end: https://github.com/hirosystems/stacks-blockchain-api/blob/3e2d524ca369b88a53fc4dfc2287aa3f0fb92e64/src/event-stream/core-node-message.ts#L352-L365 Both are indexes added by the API and show the position in the array given in the event payload.

It seems the mismatch occurs on the node in the functions: calculate_paid_rewards and pick_recipients. I don't think the ordering is important -- just double checking

[janniks]

Closing as not a bug, if we really would want these to match, it would require a node change. But it's not really expected that they match, so I don't know if that change is wanted.