Low priority: A DATUM pool can infer reward splits based on share hash/username

[wizkid057]

datum_gateway/src/datum_stratum.c

Line 1232 in 052cae9

const uint16_t share_rnd = upk_u16le(share_hash, 0);

This is deterministic, and a pool could potentially infer a client side reward split when that may not be desirable.

Suggest creating a random key of sorts to base the above variable on to XOR with. Can either be set and occasionally rotated, or a pseudorandom feedback mechanism based on an initial random key, provided it's random enough to not affect the actual reward splits.