john
john copied to clipboard
Formats written as salt-only even though they could be normal.
The list below can likely grow a lot if we review all Dhiru's formats. I'm not sure we need to fix them at all? A drawback with doing so is it increases OpenCL result transfer size.
- [ ] CloudKeychain has a 32-byte binary
- [ ] Telegram has a 16-byte binary
FWIW, I wrote the Armory format as normal, but in hindsight I think it'd have been slightly simpler as salt-only (in fact, I had that early on in a version I never committed). The only advantage of having it as normal is it'd detect matching salts - in this case, if somehow multiple entries exist for the same cryptocurrency address, which I don't see why would ever be the case.
So maybe a reasonable criterion would be whether the exposed possibility of matching salts would be realistic in actual usage or not. If not, it could actually be an untested special case, which we could rather avoid having.