In the ZIP-32 Conventionsrepr_J(P) describes P as a point on an elliptic curve. If I extrapolate back to repr_P then, I’m guessing ak must be a point on an elliptic curve.

But then we get to section 5.6.4.4 of the Zcash protocol spec where we pass the same ak to the I2LEOSP_256 function which clearly takes a big integer.

So in my in-progress implementation of Zcash, I have a type mismatch. Is ak a big integer or a point on an elliptic curve?

It’s interesting to compare this use of ak with Sapling, which in 5.6.3.3 of the Zcash protocol is explicitly passed through repr_J before being passed to LEBS2OSP_256, making it consistently appear to be a point on a curve. So if ak have the same type between sapling and orchard, maybe the spec is missing a repr function?

Thanks. Yes that confirms what I believed. But that suggests ak is a point on a curve. Yet I can’t pass a point on a curve directly to I2LEOSP_256 because that takes an integer. So… is a function missing in that expression to first convert the point to an integer?

Well, I guess it’s just the X coordinate, given here ak is defined as Extract_P(ak_P).

aside: the worst part about reading this spec is so many layers of function definitions, across two large PDFs, and the browser’s Back button doesn’t usually work for jumping “back” to a prior position in the PDF. And given the function and variable names are often pictures due to their fancy characters, I can’t always search for them, or reuse the same name in my code to discover that I’ve already implemented a given function somewhere… It’s the hardest spec I’ve had to implement.