Use Blake for stealth addresses

[xevisalle]

Resolves: #150

[moCello]

I was also looking into this last week. Now that we change how the hash is created, there are some things to keep in mind:

• first of all: yes, unfortunately we need to go over the conversion to JubJubAffine, since only a JubJubAffine stores the real coordinates of a point on the jubjub curve. You can check here how a JubJubExtended relates to a JubJubAffine (note that a ExtendedPoint is our JubJubExtended)
• I think the module should not be called permutation since it is not a permutation. Preferably I would remove the module all together and add the hash function in 'lib.rs' or 'keys.rs' (since the hash is only used for generating the keys), or alternatively rename the module to 'hash' (this is less nice though since then we have a 'hash::hash' path for the hash function).
• this point is an important one for research to think about: we should check if we want to use the to_bytes function of JubJubAffine to get our hash-input. It will serialize only the BlsScalar x-coordinate of the point and use the first bit of that serialization to indicate whether the positive or negative y-coordinated is used with the point (this means that the serialization of point P has only a one bit difference to the serialization of point -P). If we want to have the actual coordinates as hash-inputs then we need to use the to_hash_inputs functionality of jubjub-points and serialize the two resulting BlsScalar one by one. Theoretically it shouldn't matter so much which input we take for the hash-function (as long as we always pick the same one ;)) since even only a one bit difference in the input should result in a completely different hash, but that's something I'll leave research to think about
• concretely regarding your commit: you don't need to use the entire path dusk_jubjub::Fr::hash_to_scalar, since you are importing JubJubScalar above already, you can simply go: JubJubScalar::hash_to_scalar.

[moCello]

LGTM,
just the comment on the export!