Some subnets, have almost 90% of their miners with 0 emission. It seems that this logic will always pick the last UID from the UID indexes unless they are immune or have emission. What I am observing is that we are constantly pruning UIDs from the last UIDs, and since we don't have a lot of registrations in the Subnet, this creates a safe haven for UID 0 (or all low UID miners) with 0 emission that will never get pruned and can always try its chance to mine the subnet. We are constantly replacing UIDs between 250 and 255 right now and when they come off immunity then we go beck to 255 again.
UID pruning and deregistration in the subnets, when there are a lot of UIDs with zero emissions, should be based on the registration date of the UID or selected randomly among all those that are candidates for pruning.
Describe the bug
Some subnets, have almost 90% of their miners with 0 emission. It seems that this logic will always pick the last UID from the UID indexes unless they are immune or have emission. What I am observing is that we are constantly pruning UIDs from the last UIDs, and since we don't have a lot of registrations in the Subnet, this creates a safe haven for UID 0 (or all low UID miners) with 0 emission that will never get pruned and can always try its chance to mine the subnet. We are constantly replacing UIDs between 250 and 255 right now and when they come off immunity then we go beck to 255 again.
To Reproduce
The logic that needs to be fixed is here : https://github.com/opentensor/subtensor/blob/1332d077ea73bc7bf40f551c7f1adea3370df2bd/pallets/subtensor/src/registration.rs#L441
Expected behavior
UID pruning and deregistration in the subnets, when there are a lot of UIDs with zero emissions, should be based on the registration date of the UID or selected randomly among all those that are candidates for pruning.
Screenshots
No response
Environment
Subtensor
Additional context
No response