This simplifies the code significantly while simultaneously making mixpool acceptance checks stricter in ruruns after blame due to the session validation and PR inclusion rules that were only being performed during run 0.
This avoids an issue where peers who have been excluded in a later rerun continue to submit messages in the rerun. These messages were not being correctly rejected by mixpool, and could be improperly received by clients. Rejecting these messages would have required wallets to provide additional hints to the mixpool about which peers are still in the rerun, and this information would be unavailable to dcrd mixpools entirely.
Instead, a new run-0 session is formed with a subset of the original peers, and all of the existing run-0 validation would continue to be executed for the rerun. mixpools no longer understand the difference between reformed sessions and reruns, and will refuse to accept any non-run-0 message.
In the future, this may also be useful to observe new rerun sessions that other peers have tried to create that differ from our own, which will be useful first step in debugging why these sets differ.
This is technically a breaking change that will stop rerun mixes for older wallets who do not also create the same new sessions, but this only affects reruns after blame assignment and original run-0 sessions will continue to operate properly if all peers are honest and behaving.
This simplifies the code significantly while simultaneously making mixpool acceptance checks stricter in ruruns after blame due to the session validation and PR inclusion rules that were only being performed during run 0.
This avoids an issue where peers who have been excluded in a later rerun continue to submit messages in the rerun. These messages were not being correctly rejected by mixpool, and could be improperly received by clients. Rejecting these messages would have required wallets to provide additional hints to the mixpool about which peers are still in the rerun, and this information would be unavailable to dcrd mixpools entirely.
Instead, a new run-0 session is formed with a subset of the original peers, and all of the existing run-0 validation would continue to be executed for the rerun. mixpools no longer understand the difference between reformed sessions and reruns, and will refuse to accept any non-run-0 message.
In the future, this may also be useful to observe new rerun sessions that other peers have tried to create that differ from our own, which will be useful first step in debugging why these sets differ.
This is technically a breaking change that will stop rerun mixes for older wallets who do not also create the same new sessions, but this only affects reruns after blame assignment and original run-0 sessions will continue to operate properly if all peers are honest and behaving.