While reading the code today, I discovered a possible way that a shuffle output address could get re-used in the pathological circumstances described in #70 (Last player advantage).
Basically the other clients give up on the shuffle and go back to their queue and if things line up in an improbable but still possible way -- another shuffle can get set up to use the output address of the "failed" shuffle described in #70. That shuffle eventually broadcasts by the lagged player and thus 2 outputs (1 possibly being an unshuffled 'change', the other shuffled non-change) can end up on the same address, after all is said and done.
This is unlikely but there needs to be a workaround and/or fix for this. I have already thought of a strategy to address this -- imposing a "cooling down" period before re-using addresses of previously-failed shuffles just in case they eventually succeed and are broadcast by the lagged player.
This requires a little additional logic to be added but it's not too bad. I consider it a high priority as this corner case, while unlikely, may pop up occasionally and reduce confidence in the quality of this software if people get wind of it.
While reading the code today, I discovered a possible way that a shuffle output address could get re-used in the pathological circumstances described in #70 (Last player advantage).
Basically the other clients give up on the shuffle and go back to their queue and if things line up in an improbable but still possible way -- another shuffle can get set up to use the output address of the "failed" shuffle described in #70. That shuffle eventually broadcasts by the lagged player and thus 2 outputs (1 possibly being an unshuffled 'change', the other shuffled non-change) can end up on the same address, after all is said and done.
This is unlikely but there needs to be a workaround and/or fix for this. I have already thought of a strategy to address this -- imposing a "cooling down" period before re-using addresses of previously-failed shuffles just in case they eventually succeed and are broadcast by the lagged player.
This requires a little additional logic to be added but it's not too bad. I consider it a high priority as this corner case, while unlikely, may pop up occasionally and reduce confidence in the quality of this software if people get wind of it.