The protocol states
A key tuple (ask, skenc, addrpk) is generated by users who wish to receive payments under this scheme. The viewing key skenc and the payment address addrpk = (apk , pkenc ) are derived from the spending key ask .\
I cannot find a clear explanation of how the viewing key is generated from the spending key and how the transmission key is then generated from the viewing key. Any pointers?
See section 4.2 Key Components. I’ll include a link to that from 3.1 Payment Addresses and Keys to save time for others.
(In general, section 3 defines concepts but not any of the crypto implementing them.)
Thanks Daria,
If I understand this correctly, from a lay-person’s point of view;
ask is a large random number generated in a way similar to how one would generate a private key in bitcoin
apk is ask pushed though a hash function - ie not a public key in the bitcoin elliptic curve sense
skenc is apk transformed into a private key format - ie a large number deterministically liked to the hash of ask
pkenc is the public key of skenc - ie the elliptic curve point related to skenc by point multiplication of the generator
Am I on the right track? Can I ask what the (0) and (1) qualifiers are on PRFask for the apk and skenc respectively.
Thanks Daria,
Daira, and you’re welcome.
If I understand this correctly, from a lay-person’s point of view;
ask is a large random number generated in a way similar to how one would generate a private key in bitcoin
Yes.
apk is ask pushed though a hash function - ie not a public key in the bitcoin elliptic curve sense
Yes.
skenc is apk transformed into a private key format - ie a large number deterministically liked to the hash of ask
No, apk is a public part of the address, so skenc cannot be derived from it. It is derived as a (different) hash of ask.
(ask is the spending key, which allows you to spend from an address. skenc is the viewing key, which allows you to see payments sent to an address. You should be able to derive the viewing key from the spending key but not vice versa.)
pkenc is the public key of skenc - ie the elliptic curve point related to skenc by point multiplication of the generator
Yes.
Am I on the right track? Can I ask what the (0) and (1) qualifiers are on PRFask for the apk and skenc respectively.
Since we use the same function PRFaddr to derive both from ask, we need distinct inputs to make sure that apk is unrelated to skenc.
What is the purpose of the a_pk part in the shielded addresses? Why not use just the pk_enc as the payment address?
