Summary: the test result was calculated with values that are not compliant with RFC 7914 (nor the original paper) that defines scrypt (N < 2^(128 * r / 8)) must be true). The likely explanation is that the test result was calculated with the help of Go's scrypt implementation, which itself is not compliant with the RFC (see the golang/go issue linked above).
This is already resulting in portability problems and some careful thought needs to be given as to how the situation can be remedied without causing a "breaking change" fiasco.
tniessen
commented
4 years ago
See: https://github.com/ethereum/wiki/wiki/Web3-Secret-Storage-Definition/_compare/fc9278af8e362db0132118a8e4b21c5fde5b26d2...0f6da3f1c9476621b6d6826a80ffbab3b9cc12d3
The revision comment is: "reverting previous change - test result was calculated with inverted values".
However
r=1,p=8is quite problematic. See:https://github.com/ethereum/go-ethereum/issues/19977 https://github.com/golang/go/issues/33703 https://github.com/nodejs/node/pull/28799#issuecomment-522318717
Summary: the test result was calculated with values that are not compliant with RFC 7914 (nor the original paper) that defines scrypt (
N < 2^(128 * r / 8))must be true). The likely explanation is that the test result was calculated with the help of Go's scrypt implementation, which itself is not compliant with the RFC (see the golang/go issue linked above).This is already resulting in portability problems and some careful thought needs to be given as to how the situation can be remedied without causing a "breaking change" fiasco.