Rename sk_r and pk_r to note_..

[moCello]

Resolves #156

[xevisalle]

Just the comment about the address.

Plus, as a reflexion, I'd prefer the variables to be called nsk and npk, but I understand that calling em note_sk and note_pk is much more readable, so it's fine to me!

[xevisalle]

as this is returning the note_pk, I'd call this function like this. In our context the address is the static public key. Otherwise if we refer to the stealth address, we must consider the tuple (note_pk, R)

[moCello]

I'm also not entirely happy with the address function.

We already have a method called note_pk (formerly pk_r) of the StealthAddress that returns a NotePublicKey (which is just a wrapped JubJubExtended) so I cannot use the same function name here again.

If we want to get the internal point in NotePublicKey we currently have two options:

// without `address` method
let jubjub_point = stealth_address.note_pk().as_ref();

// with `address` method
let jubjub_point = stealth_address.address();

I think the second one is nicer but of course only if the concept of an 'address' somewhat makes sense.

Any thoughts?

[ureeves]

Adding my two cents here. I think having a StealthAddress::address function is a bit... redundant to say the least, and confusing in the worst case. That said, I also understand the stealth_address.note_pk().as_ref() is unsatisfactory.

Maybe we should improve the access to the underlying JubJubScalar in NotePublicKey in a future PR?

[moCello]

I agree and removed the address method. I also agree that we need to address the as_ref() API, this needs to be done in jubjub-schnorr though.

[moCello]

dusk-network/jubjub-schnorr#13

[HDauven]

LGTM

Added two places where the docs might be updated. Will approve and leave it up to you whether to change it or not.

[moCello]

Plus, as a reflexion, I'd prefer the variables to be called nsk and npk, but I understand that calling em note_sk and note_pk is much more readable, so it's fine to me!

Yes, that's also an option. I'll do it like this in the changes and the stack bump because if I follow the convention npk for NotePublicKey, then I'll need to name the StakeSecretKey in the stake contract ssk which will be very confusing with the formerly known SecretSpendKey. To avoid such confusion I'll stick to the longer names for now.
In the long run I think we'll see both options in our crates.

[ureeves]

Very nice. Approved. Added my two cents to the address debate

[ureeves]

Adding my two cents here. I think having a StealthAddress::address function is a bit... redundant to say the least, and confusing in the worst case. That said, I also understand the stealth_address.note_pk().as_ref() is unsatisfactory.

Maybe we should improve the access to the underlying JubJubScalar in NotePublicKey in a future PR?

[xevisalle]

LGTM