Decide on (not) unifying effectively-same salts of salt-only formats

[solardiz]

As mentioned in comments in #5720 and #5730, the commit 6c82f3aa76cdd78cf79d23f3c182c53ad791653b for the BitShares format results in correct de-duplication of effectively-same non-hashes at loading and cracking, but then --show and a second cracking run do not recognize the pot entry as matching also the other non-hash. So this may not be the way to go (one other way would be to unify in split rather than in get_salt), or maybe we need more changes.

Once we agree on how we'd like this to work, we could implement the same in the Bitcoin[-opencl] formats. (Are there any others needing it?)

Right now, for Bitcoin the behavior is similar to what it was for BitShares prior to the mentioned commits - the effectively-duplicate non-hashes are loaded as two distinct ones, cracked correctly (but with double the effort), and then indeed reported correctly. Ideally(?), we'd de-duplicate at load time, but without the subsequent drawbacks.

The simplest "fix" is to decide not to bother, and either to revert the referenced commit or just accept that if someone has both forms of such non-hashes, they may end up wasting effort on double the computation.

[solardiz]

The simplest "fix" is to decide not to bother, and either to revert the referenced commit

That's not so simple because a subsequent commit relies on the actually relevant 2 AES blocks being at the very start of the binary ciphertext buffer inside the salt struct. Of course, it can easily be revised, but it's not a simple git revert.

[solardiz]

one other way would be to unify in split rather than in get_salt

This is now done in BitShares. We may want to do similar in Bitcoin[-opencl].