Use max config difficulty internally

[SergiySW]

Instead of only RPC "work_generate"
Also max_difficulty converted to max_work_generate_multiplier for better readability

[cryptocode]

I'm not sure we should have floating point literals in config files, different parsers may treat them differently and it is likely to be locale dependent (also relevant with toml transition). Could we serialize as string (like we do with bignums) to a specific format that the node knows how to parse across all platforms/independent of locale/parser?

[SergiySW]

@cryptocode can we probably use int then?

[guilhermelawless]

I think for this multiplier it would be fine to use int but all our multipliers are floats. How would it work with toml ?

[cryptocode]

@guilhermelawless it may or may not work in toml and it it'll depend on parser and locale. My locale has "," as decimal separator and of course it fails to parse that. Also, reading 1.35 and writing it out gets me 1.3500000000000001 as it cannot be represented accurately (a potential problem for future migrations where we wanna compare against defaults?) We don't use floats in other parts of the config and I personally think we should avoid it. Safest would be int or a string representation - the config comment will make it clear what the data type is.

We can try to make it work with doubles, but I'm skeptical 😅

[guilhermelawless]

I'm ok with string and using the same for future floats.

[guilhermelawless]

Does it make sense to use nano::to_string here? https://github.com/nanocurrency/nano-node/blob/master/nano/lib/numbers.cpp#L810

[SergiySW]

@guilhermelawless is to_string locale specific? I cannot confirm or deny it in tests. More important is if decoder is locale specific

[guilhermelawless]

@SergiySW C++ defaults to the C classic locale unless explicitly set otherwise: http://www.cplusplus.com/reference/locale/locale/

And from http://www.cplusplus.com/reference/clocale/

It is a rather neutral locale which has the same settings across all systems and compilers, and therefore the exact results of a program using this locale are predictable.

@cryptocode what makes the parser you tested locale specific?

[cryptocode]

what makes the parser you tested locale specific?

@guilhermelawless I think that's the issue - this particular parser doesn't honor my locale (and it's not set up to pick up LC_NUMERIC on launch). Some people are naturally going to put decimal numbers in the config file using their locale's format, not C classic locale. So ideally the system locale should be used, but probably need ICU to get that right.

Some systems allows both decimal point characters regardless of locale, which might be a good idea.

Or... we can accept only C classic locale and ignore OS locale and have people deal with the parse error if they use the "wrong" format. In that case, we can likely use decimals directly instead of stringifying the setting. Ugh.

[cryptocode]

edit: This now needs to (de)serialize toml instead (no json or upgrade)

[guilhermelawless]

LGTM