-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add SigningParts getters #433
base: main
Are you sure you want to change the base?
Conversation
4ffcf2c
to
5b611bf
Compare
5b611bf
to
f0c88b7
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not including this PR in orchard 0.11.0
@@ -334,6 +334,15 @@ impl From<FullViewingKey> for SpendValidatingKey { | |||
} | |||
|
|||
impl FullViewingKey { | |||
/// Create FVK from the given sk and ak. | |||
pub fn from_sk_ak(sk: &SpendingKey, ak: SpendValidatingKey) -> Self { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The documentation here is very insufficient:
- It makes no mention of how
sk
andak
are checked or combined (in particular, that you get a different FVK than if you just go fromsk
). - It makes no mention of FROST (or why you would want to use this API).
- It is not behind a feature flag so is exposing a normative public API which I do not want to be present without a corresponding specification (which will eventually be ZIP 312 once [ZIP 312] Key generation zips#883 is finished).
Also, not documented as an addition in the changelog.
&self.ak | ||
} | ||
/// Return the randomization for this action. | ||
pub fn alpha(&self) -> pallas::Scalar { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These getters are only necessary for the older compile-time state machine builder API. Since this PR was opened, we've deployed PCZTs which already include these getters implicitly, and PCZTs (and runtime state machine builder APIs in general) are the general direction we will be heading, so these aren't technically necessary. That being said, as these are behind an unstable feature flag I wouldn't mind them going in for testing purposes, on the understanding that they likely will eventually be removed (along with the corresponding builder logic).
Depends on #428
See #430 for rationale